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

[julien.meuric]

Hi all,

Since there's no objection, we can confirm the result that showed a 
clear support for adoption during Yokohama the meeting. The I-D is 
adopted as a PCE work item.


@Authors: You know the drill, please submit the document as 
draft-ietf-pce-pceps-tls13-00.


Thanks,

Julien


On 27/03/2023 11:48, julien.meu...@orange.com wrote:

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.

Thanks,

Julien





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[julien.meuric]

Hi Tom,

About the IPR at large, there's no way we can know for sure. What we can 
do is reminding all IETF contributors about their duty with respect to 
IETF policies. [1]


This is an adoption poll, it will end when the chairs will consider we 
have enough feedback to gauge the WG's opinion. We'd be happy to read yours.


Cheers,

Julien

--
[1] https://www.ietf.org/about/note-well/


On 05/04/2023 11:47, tom petch wrote:



By when?

And is there any IPR on it?

Tom Petch




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[julien.meuric]

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.

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

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

[julien.meuric]

Hi all,

This WGLC has ended. Authors, please address the open comments and 
update accordingly.


Thanks,

Julien


On 13/02/2023 18:38, julien.meu...@orange.com wrote:

Dear PCE WG,

This message starts a 2-week WG last call on 
draft-ietf-pce-segment-routing-ipv6-15 [1]. Please, be express any 
comments you have about this document using the PCE mailing list.


This WGLC will end on Tuesday 28th February 2023.

Thanks,

Julien

--
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/


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



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Pce] Call for slot in the PCE WG at IETF 116

[julien.meuric]

Hi all,

Let's use "Sasha", that's how you're known within the Routing area. ;-)

Cheers,

Julien


On 28/02/2023 13:41, Alexander Vainshtein wrote:


Hi all,

My name in the list of onsite attendees of the IETF-116 meeting is 
Alexander Vainshtein (and not as in Marina’s email).


Regards,

Sasha

*From:* Marina Fizgeer 
*Sent:* Tuesday, February 28, 2023 1:12 PM
*To:* Dhruv Dhody ; Dhruv Dhody 
; pce@ietf.org; julien.meu...@orange.com; 
h...@netflix.com
*Cc:* Alexander Vainshtein ; Rotem 
Cohen ; Nitsan Dolev 

*Subject:* Call for slot in the PCE WG at IETF 116

Hello,

I am asking to add 
https://datatracker.ietf.org/doc/draft-fizgeer-pcep-bfd-parameters/ 
draft presentation to PCE WG meeting in IETF116


I want to draw attention to this new DRAFT and get feedbacks.

Draft: https://datatracker.ietf.org/doc/draft-fizgeer-pcep-bfd-parameters/

Expected presenter name: Alexander Wainstein (in-person) and Marina 
Fizgeer (remote)


Duration: 10 minutes

Reason: to draw attention to this new DRAFT and get feedbacks

Thank you in advance.

Best regards,

Marina


Notice: This e-mail together with any attachments may contain 
information of Ribbon Communications Inc. and its Affiliates that is 
confidential and/or proprietary for the sole use of the intended 
recipient. Any review, disclosure, reliance or distribution by others 
or forwarding without express permission is strictly prohibited. If 
you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.


_

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] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

[julien.meuric]

Dear PCE WG,

This message starts a 2-week WG last call on 
draft-ietf-pce-segment-routing-ipv6-15 [1]. Please, be express any 
comments you have about this document using the PCE mailing list.


This WGLC will end on Tuesday 28th February 2023.

Thanks,

Julien

--
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IETF WG state changed for draft-dhody-pce-pcep-extension-pce-controller-srv6

[julien.meuric]

Dear authors of draft-dhody-pce-pcep-extension-pce-controller-srv6,

You may now submit the same I-D under the name 
draft-ietf-pce-pcep-extension-pce-controller-srv6-00.


Thanks,

Julien


On 08/02/2023 14:05, IETF Secretariat wrote:

The IETF WG state of draft-dhody-pce-pcep-extension-pce-controller-srv6 has
been changed to "Adopted by a WG" from "Call For Adoption By WG Issued" by
Julien Meuric:

https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-srv6/





_

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

Re: [Pce] WG Adoption of draft-dhody-pce-pcep-extension-pce-controller-srv6

[julien.meuric]

Hi all,

We have a decent level of support and no voice against. Consequently, 
let's adopt this I-D as a new PCE work item.


Thanks,

Julien


On 16/01/2023 19:00, julien.meu...@orange.com wrote:

Hi all,

This e-mail starts an adoption poll for 
draft-dhody-pce-pcep-extension-pce-controller-srv6-10 [1]. Do you 
consider this I-D is ready to become a PCE WG item?


Please respond to the PCE list, including rationale if you believe the 
WG should not adopt it.


Thanks,

Julien


[1] 
https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-srv6/




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Scoping Items from draft-koldychev-pce-operational

[julien.meuric]

Hi Minxue,

For the record, we guess you intended to respond to the thread about the 
adoption of draft-dhody-pce-pcep-extension-pce-controller-srv6. :-)


Thanks,

Dhruv & Julien


On 24/01/2023 03:27, wangmin...@chinamobile.com wrote:

Hi Chair and WG,

 I support the adopting of this work. This document seems a reasonable 
solution for SRv6 computing and allocation with PCE based control.


-
王敏学/ Wang Minxue
中国移动通信研究院 基础网络技术研究所 / China Mobile Research Institute
地址: 北京市西城区宣武门西大街32号创新大厦,100053
电话: 010-15801696688-33202
传真：010-63601087
Email: wangmin...@chinamobile.com
-

*From:* julien.meu...@orange.com
*Date:* 2023-01-17 00:57
*To:* pce@ietf.org
*Subject:* Re: [Pce] Scoping Items from
draft-koldychev-pce-operational
Dear PCE WG,
This issue has been opened for while. Thank you to those who took
time
to share their views.
We acknowledge that having a single document may be likely to
reduce the
initial paperwork (at least until the I-D starts to be reviewed by
people outside the PCE WG). However, as stated by Adrian, the line
between updates and clarifications "must not be blurry", all the
more as
the standard track piece of work may update some RFCs. This must
be true
both for us, as a WG, and for future reader of the documents,
especially
if they are not familiar with IETF way of working when it comes to
multi-status document content.
As a result, let's follow John's guidelines, voiced during the London
meeting, and split the I-D into 2 documents with focused status.
Starting from there, we'll be able to move forward.
Thank you,
Dhruv & Julien
On 29/09/2022 10:37, julien.meu...@orange.com wrote:
> Dear PCE WG,
>
> Let's follow up on the discussion started during IETF 114 about
> draft-koldychev-pce-operational [1]. The I-D currently tackles
> different issues about PCEP, some of them being informational, some
> other updating existing PCEP specifications. Among the options we
> discussed to proceed with this work, 2 remain:
> 1. Keep a single draft, but clearly separate the two types of
content;
> 2. Break it up into 2 drafts.
>
> We'd like to hear the WG's opinion whether you prefer:
> a- a single standard track I-D, with both content types sharing
fate
> until publication?
> b- a clarification I-D on informational track + an I-D updating
PCEP
> on standard track (possibly progressing at different paces)?
>
> Please share your feedback using the PCE mailing list.
>
> Thanks,
>
> Dhruv & Julien
>
>
> [1]
https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/
>
>
>
> ___
> 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



_

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] WG Adoption of draft-dhody-pce-pcep-extension-pce-controller-srv6

[julien.meuric]

Hi all,

This e-mail starts an adoption poll for 
draft-dhody-pce-pcep-extension-pce-controller-srv6-10 [1]. Do you 
consider this I-D is ready to become a PCE WG item?


Please respond to the PCE list, including rationale if you believe the 
WG should not adopt it.


Thanks,

Julien


[1] 
https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-srv6/





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Scoping Items from draft-koldychev-pce-operational

[julien.meuric]

Dear PCE WG,

This issue has been opened for while. Thank you to those who took time 
to share their views.


We acknowledge that having a single document may be likely to reduce the 
initial paperwork (at least until the I-D starts to be reviewed by 
people outside the PCE WG). However, as stated by Adrian, the line 
between updates and clarifications "must not be blurry", all the more as 
the standard track piece of work may update some RFCs. This must be true 
both for us, as a WG, and for future reader of the documents, especially 
if they are not familiar with IETF way of working when it comes to 
multi-status document content.


As a result, let's follow John's guidelines, voiced during the London 
meeting, and split the I-D into 2 documents with focused status. 
Starting from there, we'll be able to move forward.


Thank you,

Dhruv & Julien


On 29/09/2022 10:37, julien.meu...@orange.com wrote:

Dear PCE WG,

Let's follow up on the discussion started during IETF 114 about 
draft-koldychev-pce-operational [1]. The I-D currently tackles 
different issues about PCEP, some of them being informational, some 
other updating existing PCEP specifications. Among the options we 
discussed to proceed with this work, 2 remain:

1. Keep a single draft, but clearly separate the two types of content;
2. Break it up into 2 drafts.

We'd like to hear the WG's opinion whether you prefer:
a- a single standard track I-D, with both content types sharing fate 
until publication?
b- a clarification I-D on informational track + an I-D updating PCEP 
on standard track (possibly progressing at different paces)?


Please share your feedback using the PCE mailing list.

Thanks,

Dhruv & Julien


[1] https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/



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





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

[julien.meuric]

Hi all,

As mentioned in the PCE session during IETF 115, this WGLC has ended. 
Thanks Tom for your review. Comment resolution is in progress.


Regards,

Julien


On 26/09/2022 15:01, julien.meu...@orange.com wrote:

Hi PCE WG,

This message starts a 2-week WG Last Call for 
draft-ietf-pce-pcep-yang-19. Please review and share any feedback 
using the PCE mailing list.

This WGLC will end on Tuesday October 11.

Thanks,

Julien





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] NomCom: Selecting IETF Leadership

[julien.meuric]

Hi all,

The NomCom is tasked with selecting the IETF leadership, like the IESG 
and the IAB. For the NomCom to be able to make an informed decision, 
they need feedback from the wider IETF community.
Please, allocate some time to provide feedback on people that you 
interacted with to help the NomCom with their important task.


The deadline for this feedback is Nov 28.

https://datatracker.ietf.org/nomcom/2022/feedback/

Regards,

Dhruv & 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

Re: [Pce] Scoping Items from draft-koldychev-pce-operational

[julien.meuric]

Hi Tom,

The question lies in today's context. If the context was to change much 
in the future, we could of course reconsider the situation based on the 
new elements we'd face.

As a result, you're clearly voicing for option a.

Thank  you,

Julien


On 30/09/2022 09:25, tom petch wrote:



Well, I think that you should be more concerned about fate sharing after 
publication, which, long as it may take to get there, can still be much shorter 
than the time after publication.   I think that there are plenty of documents 
where disparate information with different life cycles has been banged together 
creating future problems.  Here, I am not sure that this is the case.  The 
document is short and so a complete reissue should not be a lot of work which 
inclines me  towards a single I-D in two parts.

I wonder if during the course of preparation,  further issues arise so that the 
document may never be quite up-to-date, but that is hypothetical.

Tom Petch



_

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] Scoping Items from draft-koldychev-pce-operational

[julien.meuric]

Dear PCE WG,

Let's follow up on the discussion started during IETF 114 about 
draft-koldychev-pce-operational [1]. The I-D currently tackles different 
issues about PCEP, some of them being informational, some other updating 
existing PCEP specifications. Among the options we discussed to proceed 
with this work, 2 remain:

1. Keep a single draft, but clearly separate the two types of content;
2. Break it up into 2 drafts.

We'd like to hear the WG's opinion whether you prefer:
a- a single standard track I-D, with both content types sharing fate 
until publication?
b- a clarification I-D on informational track + an I-D updating PCEP on 
standard track (possibly progressing at different paces)?


Please share your feedback using the PCE mailing list.

Thanks,

Dhruv & Julien


[1] https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

[julien.meuric]

Hi PCE WG,

This message starts a 2-week WG Last Call for 
draft-ietf-pce-pcep-yang-19. Please review and share any feedback using 
the PCE mailing list.

This WGLC will end on Tuesday October 11.

Thanks,

Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Fwd: Re: WG Adoption of draft-li-pce-pcep-srv6-yang-07

[julien.meuric]

Hi Spring WG,

An adoption poll is currently running in the PCE WG for an I-D related 
to SRv6. Some concern has been raised about the status of two Spring 
documents included as references because they're expired.


Could you please share with the PCE WG your plans to progress both 
spring-sr-policy-yang and spring-srv6-yang?


Thank you,

Dhruv and Julien, PCE co-chairs


 Forwarded Message 
Date:   Thu, 8 Sep 2022 17:13:30 +0200
From:   julien.meu...@orange.com


Hi Tom,

Thank you for sharing your views. I agree with your generic point about 
dependency. This question is very legitimate when requesting 
publication, especially if there are concerns about the maturity of some 
references (note however there's no universal rule to address that kind 
of situation).


After a quick scan, here's the situation we're facing for the considered 
I-D:
- SRv6 YANG expired this summer (with a typo in its expiration date) and 
is referenced for 2 attributes;

- SR Policy YANG expired 1 year ago and is referenced for one attribute.

Please keep in mind that we aren't running a WG LC, just an adoption 
poll. In other word, I don't see your point on references as a blocking 
issue that would really prevent the WG from adopting this topic as a 
work item and using this I-D as a document base.


Cheers,

Julien


On 08/09/2022 10:14, tom petch wrote:

Thinking some more ...

From: Pce  on behalf of tom petch 


Sent: 07 September 2022 12:32

Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-srv6-yang-07.

https://datatracker.ietf.org/doc/draft-li-pce-pcep-srv6-yang/

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.



Oppose.
It is those expired references. We have I-D that have been sitting in 
the RFC Editor queue waiting for their references to catch up for 1108 
days - yes, three years - and in one case, the referenced I-D has 
changed so that the first document is no longer valid and will have to 
be taken back into the WG to be revised, if anyone is still around who 
is familiar with it and willing to work on it.


With hindsight, such I-D should have been held and not forwarded to 
the IESG, or not adopted in the first place.


Here, I am not familiar with the state of the spring WG and do not 
know if and when those expired I-D will progress. A last revision of 
April 2021 with an I-D that has plenty that needs fixing does not look 
promising.


Tom Petch


The challenge I see is the SR references, one is RFC9256, the others, 
spring-sr-policy-yang and spring-srv6-yang, are expired; not a good 
starting point..


The 'when' clauses use absolute form of the path which means that the 
when is satisfied if there is anything meeting this anywhere in the 
tree, not just in this path of the tree; if the latter is wanted, then 
the relative form is required


MSD type could do with a better reference - pce-segment-routing-ipv6 
points to RFC8491 but that only sets up an IANA registry which 
contains many more entries so I think the reference has to be to the 
IANA registry.


'Add NAI' looks like an unresolved issue

Tom Petch

Please respond by Monday 19th Sept 2022.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien

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





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-li-pce-pcep-srv6-yang-07

[julien.meuric]

Hi Tom,

Thank you for sharing your views. I agree with your generic point about 
dependency. This question is very legitimate when requesting 
publication, especially if there are concerns about the maturity of some 
references (note however there's no universal rule to address that kind 
of situation).


After a quick scan, here's the situation we're facing for the considered 
I-D:
- SRv6 YANG expired this summer (with a typo in its expiration date) and 
is referenced for 2 attributes;

- SR Policy YANG expired 1 year ago and is referenced for one attribute.

Please keep in mind that we aren't running a WG LC, just an adoption 
poll. In other word, I don't see your point on references as a blocking 
issue that would really prevent the WG from adopting this topic as a 
work item and using this I-D as a document base.


Cheers,

Julien


On 08/09/2022 10:14, tom petch wrote:

Thinking some more ...

From: Pce  on behalf of tom petch 
Sent: 07 September 2022 12:32

Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-srv6-yang-07.

https://datatracker.ietf.org/doc/draft-li-pce-pcep-srv6-yang/

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.


Oppose.
It is those expired references.   We have I-D that have been sitting in the RFC 
Editor queue waiting for their references to catch up for 1108 days - yes, 
three years - and in one case, the referenced I-D has changed so that the first 
document is no longer valid and will have to be taken back into the WG to be 
revised, if anyone is still around who is familiar with it and willing to work 
on it.

With hindsight, such I-D should have been held and not forwarded to the IESG, 
or not adopted in the first place.

Here, I am not familiar with the state of the spring WG and do not know if and 
when those expired I-D will progress.  A last revision of April 2021 with an 
I-D that has plenty that needs fixing does not look promising.

Tom Petch


The challenge I see is the SR references, one is RFC9256, the others, 
spring-sr-policy-yang and spring-srv6-yang, are expired; not a good starting 
point..

The 'when' clauses use absolute form of the path which means that the when is 
satisfied if there is anything meeting this anywhere in the tree, not just in 
this path of the tree; if the latter is wanted, then the relative form is 
required

MSD type could do with a better reference - pce-segment-routing-ipv6 points to 
RFC8491 but that only sets up an IANA registry which contains many more entries 
so I think the reference has to be to the IANA registry.

'Add NAI' looks like an unresolved issue

Tom Petch

Please respond by Monday 19th Sept 2022.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien

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

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




_

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

Re: [Pce] Shepherd's Review of draft-ietf-pce-local-protection-enforcement-06

[julien.meuric]

Hi Andrew,

After talking with Robert Sparks about Idnits analysis, the best way to 
address the error below while pleasing the IESG was to say in the 
abstract "This document updates RFC 5440", without square brackets to 
avoid creating a reference.


No need to trigger an update at this stage, but it would be nice to 
include that change in the next revision down the road.


Thanks,

Julien


On 04/08/2022 12:05, julien.meu...@orange.com wrote:

_From idnits:_

- The abstract should avoid using references, i.e. you may replace 
"[RFC5440]" by a phrase like "the base specification". 





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd's Review of draft-ietf-pce-local-protection-enforcement-06

[julien.meuric]

Hi Andrew,

Thanks for the detailed response. In other word, the case L=0/E=0 is 
purposely loose, whereas L=1/E=0 is where the document really updates 
RFC 5440 (E=1 being rather an extension). That's consistent with the 
problem statement.


Thank you for the update, I'll now prepare the proto write-up.

Julien


On 08/08/2022 21:13, Stone, Andrew (Nokia - CA/Ottawa) wrote:

Hi Julien, PCE WG

New version -07[1] has been posted to address the review feedback. Thanks once 
again for the review and Shepherding this.


"Any reason why the case above doesn't include the legacy situation, similarly to the case 
below (i.e. "but MAY consider protection eligibility as a PROTECTION MANDATORY 
constraint")?"

Good question. At the time of the original text the core intention was to clear up 
interop behavior differences when L=1, in addition to introducing the E flag as the 
strictness toggle, as that was key impacting interop problem.  In other words, the E=1 
specifically was to influence the behavior when L=1 or when L=0, and introduce strong 
enforcement when E=1. When L=0, E=0, the significance on interop and implementation isn't 
as impacting. If we allow backwards compatibility of L=1, E=0, by permitting 
"protection mandatory", that would continue to result in different interop 
implementations of (L=1) which is something the core of the document wanted to correct. 
The text on L=0, E=0 is trying to play nice with existing known implementations, since 
the impact in that scenario (the resulting path calculation) wasn't significant. 
Essentially it's a flag combination which is considered okay to provide backwards interop 
for in the text.

Thanks
Andrew

[1] 
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-local-protection-enforcement-07.txt



On 2022-08-04, 6:06 AM, "Pce on behalf of julien.meu...@orange.com" 
 wrote:

 Hi authors of draft-ietf-pce-local-protection-enforcement,

 I'm the shepherd of the aforementioned document. The problem statement
 is well described and the solution defined is clear. The I-D is almost
 ready to progress but has minor issues that need to be addressed before
 sending to the IESG.


 _From idnits:_

 - The abstract should avoid using references, i.e. you may replace
 "[RFC5440]" by a phrase like "the base specification".
 - RFC 4655 is used as a normative document, though not mandatory to
 implement the I-D: moving it into informative reference section would
 not only reflect this, but would also avoid the downref.


 _From my reading:_

 - The page header just mentions "I-D": a short title is expected there.

 - Even if "PCEP" has become a name for the protocol, which leads to
 dropping "a"/"the", the acronym "PCE" is usually used as a shortcut for
 the full phrase, thus one expects to see it prefixed by "a"/"the" (cf.
 "BGP" vs. "the IGP"). I've caught several of these below but probably
 missed some.

 - Abstract

 OLD:
 This document updates [RFC5440] to clarify usage of the local
 protection desired bit signalled in Path Computation Element
 Protocol
 (PCEP).
 NEW:
 This document extends the base specification to clarify the
 usage of the
 local protection desired bit signalled in the Path Computation
 Element
 Communication Protocol (PCEP).

 - Introduction

 s/Path Computation Element (PCE) Communication Protocol (PCEP)/The Path
 Computation Element (PCE) Communication Protocol (PCEP)/
 s/Path Control Element/Path Computation Element/  [or just the acronym,
 since already expanded in the 1st line]

 NEW:
 this flag signals to downstream routers that local protection
 is desired, which indicates to transit routers that they may use a
 local repair mechanism.
 OLD:
 this flag signals to downstream routers that they may use a
 local repair mechanism.

 s/it's calculation/its calculation/
 s/advertised into IGP/advertised into the IGP/
 s/and for a given adjacency between two routers there may be/and, for a
 given adjacency between two routers, there may be/
 s/calculated by PCE/calculated by a PCE/
 s/discovered by PCE/discovered by the PCE/

 - Section 3

 s/...: path/...: The Path/  [x4]

 - Section 4

 s/example,UNPROTECTED/example, UNPROTECTED/
 s/by PCE/by the PCE/
 s/for PCE/for the PCE/
 s/traffic engineered secondary path/traffic-engineered secondary path/
 s/to instruction PCE/to instruct the PCE/

 - Section 5

 s/When set/When set to 1/
 s/When not set/When set to 0/
 s/which PCE/which the PCE/
 s/When set/When set to 1/
 s/by PCE/by the PCE/
 s/When E flag is not set/When the E flag is set to 0/
 s/however PCE/however the PCE/
 s/ignore L flag/ignore the L flag/
 s/when E flag is unset/when the E flag is 

[Pce] Shepherd's Review of draft-ietf-pce-local-protection-enforcement-06

[julien.meuric]

Hi authors of draft-ietf-pce-local-protection-enforcement,

I'm the shepherd of the aforementioned document. The problem statement 
is well described and the solution defined is clear. The I-D is almost 
ready to progress but has minor issues that need to be addressed before 
sending to the IESG.



_From idnits:_

- The abstract should avoid using references, i.e. you may replace 
"[RFC5440]" by a phrase like "the base specification".
- RFC 4655 is used as a normative document, though not mandatory to 
implement the I-D: moving it into informative reference section would 
not only reflect this, but would also avoid the downref.



_From my reading:_

- The page header just mentions "I-D": a short title is expected there.

- Even if "PCEP" has become a name for the protocol, which leads to 
dropping "a"/"the", the acronym "PCE" is usually used as a shortcut for 
the full phrase, thus one expects to see it prefixed by "a"/"the" (cf. 
"BGP" vs. "the IGP"). I've caught several of these below but probably 
missed some.


- Abstract

OLD:
   This document updates [RFC5440] to clarify usage of the local
       protection desired bit signalled in Path Computation Element 
Protocol

       (PCEP).
NEW:
   This document extends the base specification to clarify the 
usage of the
       local protection desired bit signalled in the Path Computation 
Element

       Communication Protocol (PCEP).

- Introduction

s/Path Computation Element (PCE) Communication Protocol (PCEP)/The Path 
Computation Element (PCE) Communication Protocol (PCEP)/
s/Path Control Element/Path Computation Element/  [or just the acronym, 
since already expanded in the 1st line]


NEW:
   this flag signals to downstream routers that local protection
       is desired, which indicates to transit routers that they may use a
       local repair mechanism.
OLD:
   this flag signals to downstream routers that they may use a
       local repair mechanism.

s/it's calculation/its calculation/
s/advertised into IGP/advertised into the IGP/
s/and for a given adjacency between two routers there may be/and, for a 
given adjacency between two routers, there may be/

s/calculated by PCE/calculated by a PCE/
s/discovered by PCE/discovered by the PCE/

- Section 3

s/...: path/...: The Path/  [x4]

- Section 4

s/example,UNPROTECTED/example, UNPROTECTED/
s/by PCE/by the PCE/
s/for PCE/for the PCE/
s/traffic engineered secondary path/traffic-engineered secondary path/
s/to instruction PCE/to instruct the PCE/

- Section 5

s/When set/When set to 1/
s/When not set/When set to 0/
s/which PCE/which the PCE/
s/When set/When set to 1/
s/by PCE/by the PCE/
s/When E flag is not set/When the E flag is set to 0/
s/however PCE/however the PCE/
s/ignore L flag/ignore the L flag/
s/when E flag is unset/when the E flag is set to 0/
s/When L flag is set and E flag is set then PCE/When both the L flag and 
the E flag are set to 1, then the PCE/

s/as PROTECTION MANDATORY constraint/as a PROTECTION MANDATORY constraint/
s/When L flag is set and E flag is not set then PCE/When the L flag is 
set to 1 and the E flag is set to 0, then the PCE/

s/as PROTECTION PREFERRED constraint/as a PROTECTION PREFERRED constraint/

Any reason why the case above doesn't include the legacy situation, 
similarly to the case below (i.e. "but MAY consider protection 
eligibility as a PROTECTION MANDATORY constraint")?


s/When L flag is not set and E flag is not set then PCE/When both the L 
flag and the E flag are set to 0, then the PCE/
s/as UNPROTECTED MANDATORY constraint/as an UNPROTECTED MANDATORY 
constraint/
s/When L flag is not set and E flag is set then PCE/When the L flag is 
set to 0 and the E flag is set to 1, then the PCE/
s/as UNPROTECTED MANDATORY constraint/as an UNPROTECTED MANDATORY 
constraint/


- section 5.1

To make paragraphs consistent between the 1st and the 2nd half of the 
section, it seems to me that line breaks at current lines 315 and 320 
would be appropriate.


s/between PCC and PCE for the E flag bit which/between the PCC and the 
PCE for the E flag which/

s/requirements for PCE and PCC/requirements for the PCE and the PCC/
s/the E flag bit is/the E flag is/
s/per ([RFC8281])/per [RFC8281]/
s/It's important/It is important/
s/permit LSP Attribute Object/permit the LSP Attribute Object/
s/PCUpd E flag (and L flag) are an echo/the PCUpd E flag (and L flag) is 
an echo/

s/on PCE/on the PCE/
s/with the E flag unset/with the E flag set to 0/
s/even if set in/even if set to 1 in/
s/with the E flag unset/with the E flag set to 0/
s/even if set in/even if set to 1 in/
s/MAY set E flag bit/MAY set the E flag to 1/
s/ignore the E flag bit thus/ignore the E flag, thus/
s/PCC SHOULD/the PCC SHOULD/
s/from PCE/from the PCE/
s/PCC MAY/the PCC MAY/
s/from PCE/from the PCE/
s/PCE SHOULD/The PCE SHOULD/
s/from PCC/from the PCC/

---

Cheers,

Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce 

[Pce] Chair Review of draft-ietf-pce-pcep-stateful-pce-gmpls-19

[julien.meuric]

Dear authors of draft-ietf-pce-pcep-stateful-pce-gmpls,

Considering the level of change after the shepherd's review of the 
aforementioned I-D, I've performed a 2nd review. Only some minor 
issues/nits remain. Please find them below.


- Page 1: s/provides extensions required/provides the extensions required/

- P.4:
    * s/do not cover the GMPLS networks/do not cover GMPLS-controlled 
networks/


    * OLD:
   The various requirements for stateful GMPLS including PCE-initiation
   for GMPLS LSPs is provided in Section 4. An overview of the PCEP
   extensions are specified...
  NEW:
   The various requirements for stateful GMPLS, including PCE-initiation
   for GMPLS LSPs, are provided in Section 4. An overview of the PCEP
   extensions is specified...

- P.5:
    * s/the LSP delegated to the PCE/the LSPs delegated to the PCE/
    * s/the change of the LSP./the change of the LSPs./
    * s/sent by PCC to PCEs./sent by PCCs to PCEs./
    * s/An LSP Initiate Request (PCInitiate) messages are/An LSP 
Initiate Request (PCInitiate) message is/

    * s/The PCE-Initiated LSP would follow/PCE-initiated LSPs follow/

- P.6:
    * Knowing that the END-POINT line formatting used to be broken, 
considering a different character for the 2nd level of bullets may limit 
the ambiguity in further editions.

    * s/MUST be use to specify/MUST be used to specify/
    * s/and not in this document as well./nor in this document./

- P.10:
    * A title should be added after the figure.
    * s/X bit is defined in [RFC5521]./X bit: Same as the X bit defined 
in XRO sub-objects by [RFC5521] (i.e. mandatory vs. desired)./


- P.11:
    * OLD:
   If the PCC
   supports the extensions as per this document (understands the U flag
   that indicates the stateful LSP-UPDATE-CAPABILITY) but did not...
  NEW:
   If the PCC understands the U flag
   that indicates the stateful LSP-UPDATE-CAPABILITY but did not...

    * OLD:
   If the PCE supports the extensions as per this document (understands
   the R flag that indicates the stateful LSP-REPORT-CAPABILITY) but
   did not...
  NEW:
   If the PCE understands the R flag that indicates the stateful
   LSP-REPORT-CAPABILITY but did not...

- P.12:
    * OLD:
   If the PCC
   supports the extensions as per this document (understands the I flag
   that indicates LSP-INSTANTIATION-CAPABILITY) but did not...
  NEW:
   If the PCC understands the I flag
   that indicates LSP-INSTANTIATION-CAPABILITY but did not...

    * OLD:
   A stateful PCE performs the re-optimization when the R bit is set in
   RP object.
  NEW:
   A stateful PCE is expected to perform an LSP re-optimization when
   receiving a message with the R bit set in the RP object.

- P.13:
    * s/the receiving PCE or PCC would send/the receiving PCE or PCC 
MUST send/



Regards,

Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call of draft-ietf-pce-local-protection-enforcement-05

[julien.meuric]

Hi all,

This WGLC has ended. Thank you Aijun for the valuable feedback and 
thanks to the authors for resolving the comments in a timely manner.


We'll now proceed to the next step.

Cheers,

Dhruv & Julien


On 07/06/2022 11:18, julien.meu...@orange.com wrote:

Dear all,

This message starts a 2-week Working Group Last Call 
fordraft-ietf-pce-local-protection-enforcement-05 [1].


Please share your comments using the PCE mailing list. Any levels of 
reviews are very welcome and all feedback remain useful to check the 
readiness of the document.


This LC will end on Wednesday June 22, 2022.

Thanks,

Dhruv & Julien


[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-local-protection-enforcement



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





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] WG Last Call of draft-ietf-pce-local-protection-enforcement-05

[julien.meuric]

Dear all,

This message starts a 2-week Working Group Last Call 
fordraft-ietf-pce-local-protection-enforcement-05 [1].


Please share your comments using the PCE mailing list. Any levels of 
reviews are very welcome and all feedback remain useful to check the 
readiness of the document.


This LC will end on Wednesday June 22, 2022.

Thanks,

Dhruv & Julien


[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-local-protection-enforcement




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-vn-association-05

[julien.meuric]

  
  
Hi all,

This LC has ended. Thanks to all the reviewers for sharing their
feedback.

@Authors: please, address the received comments and update the I-D
accordingly.

Cheers,

Dhruv & Julien


On 22/02/2022 13:32, Dhruv Dhody wrote:


  
  

  Looks like
  the chairs had a "collision" in sending out the WGLC
  notice! Apologies! :) 
  

  The only parameter that was
  different was when the WGLC ends, and let's pick the
  larger of the two dates i.e.  WGLC will end on March 16,
  2022.
  

  Thanks! 
  Dhruv
  
  



  On Tue, Feb 22, 2022 at 5:48
PM Dhruv Dhody  wrote:
  
  

  Hi WG,

This email starts a 3-weeks working group last call for
draft-ietf-pce-vn-association-05 [1] to
accommodate the upcoming draft submission deadline.  

Please indicate your support or concern for this draft.
If you are opposed to the progression of the draft to
RFC, please articulate your concern. If you support it,
please indicate that you have read the latest version
and it is ready for publication in your opinion. As
always, review comments and nits are most welcome. 

The WG LC will end on Tuesday 15th March 2022.

A general reminder to the WG to be more vocal during the
last-call/adoption and help us unclog our queues :)  

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/
  

  

  


  _

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] WGLC for draft-ietf-pce-vn-association

[julien.meuric]

Hi all,

This message starts a 3-week WG Last Call for 
draft-ietf-pce-vn-association-05. The I-D is not long: please review and 
share your feedback using the PCE mailing list.


This LC will end on March 16, 2022.

Regards,

Dhruv & Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption Poll for draft-li-pce-pcep-l2-flowspec

[julien.meuric]

Hi PCE'rs,

Thank you for the feedback. This extension is readopted as a WG item in 
a dedicated document.


Authors, please post a draft-ietf-pce-pcep-l2-flowspec-00.

Cheers,

Julien


On 06/01/2022 13:57, julien.meu...@orange.com wrote:

Hi all and best wishes for 2022.

Gentle reminder: we started a poll some days before Christmas. If it 
was pure new work, I'd assume there isn't enough interest yet. Since 
it's pre-existing work that has been split to catch up with another 
WG's work in progress, I'd feel more comfortable to get some explicit 
feedback.


Thanks,

Julien


On 16/12/2021 17:49, julien.meu...@orange.com wrote:

Hi all,

This message is the following step to the situation previously 
summarized by Dhruv [1].


As a result, do you believe that draft-li-pce-pcep-l2-flowspec [2] is 
a right foundation to become (again) a PCE WG item?


Please respond to the PCE list, including any comment you may feel 
useful, especially in case of negative answer.


Thanks,

Julien

(As a reminder, Dhruv recused himself from the administrative process.)

--

[1] 
https://mailarchive.ietf.org/arch/msg/pce/4f8f_3Qs_uA3T16CTCAsoOJnt58/

[2] https://datatracker.ietf.org/doc/draft-li-pce-pcep-l2-flowspec/







smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption Poll for draft-li-pce-pcep-l2-flowspec

[julien.meuric]

Hi all and best wishes for 2022.

Gentle reminder: we started a poll some days before Christmas. If it was 
pure new work, I'd assume there isn't enough interest yet. Since it's 
pre-existing work that has been split to catch up with another WG's work 
in progress, I'd feel more comfortable to get some explicit feedback.


Thanks,

Julien


On 16/12/2021 17:49, julien.meu...@orange.com wrote:

Hi all,

This message is the following step to the situation previously 
summarized by Dhruv [1].


As a result, do you believe that draft-li-pce-pcep-l2-flowspec [2] is 
a right foundation to become (again) a PCE WG item?


Please respond to the PCE list, including any comment you may feel 
useful, especially in case of negative answer.


Thanks,

Julien

(As a reminder, Dhruv recused himself from the administrative process.)

--

[1] 
https://mailarchive.ietf.org/arch/msg/pce/4f8f_3Qs_uA3T16CTCAsoOJnt58/

[2] https://datatracker.ietf.org/doc/draft-li-pce-pcep-l2-flowspec/





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Adoption Poll for draft-li-pce-pcep-l2-flowspec

[julien.meuric]

Hi all,

This message is the following step to the situation previously 
summarized by Dhruv [1].


As a result, do you believe that draft-li-pce-pcep-l2-flowspec [2] is a 
right foundation to become (again) a PCE WG item?


Please respond to the PCE list, including any comment you may feel 
useful, especially in case of negative answer.


Thanks,

Julien

(As a reminder, Dhruv recused himself from the administrative process.)

--

[1] https://mailarchive.ietf.org/arch/msg/pce/4f8f_3Qs_uA3T16CTCAsoOJnt58/
[2] https://datatracker.ietf.org/doc/draft-li-pce-pcep-l2-flowspec/



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-dhody-pce-stateful-pce-optional

[julien.meuric]

Hi all,

We can close this poll. The I-D is adopted as a PCE WG item.

@Authors, please submit the existing I-D as 
draft-ietf-pce-stateful-pce-optional-00 and consider addressing the 
collected comments to prepare a -01.


Thank you,

Dhruv & Julien


On 21/09/2021 16:00, julien.meu...@orange.com wrote:

Hi all,

This e-mail starts an adoption poll for 
draft-dhody-pce-stateful-pce-optional-08 [1]. Do you consider this I-D 
is ready to become a PCE WG item?


Please respond to the PCE list, including rationale if you believe the 
WG should not adopt it.


Thanks,

Dhruv & Julien


[1] 
https://datatracker.ietf.org/doc/html/draft-dhody-pce-stateful-pce-optional-08






smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Adoption of draft-dhody-pce-stateful-pce-optional

[julien.meuric]

Hi all,

This e-mail starts an adoption poll for 
draft-dhody-pce-stateful-pce-optional-08 [1]. Do you consider this I-D 
is ready to become a PCE WG item?


Please respond to the PCE list, including rationale if you believe the 
WG should not adopt it.


Thanks,

Dhruv & Julien


[1] 
https://datatracker.ietf.org/doc/html/draft-dhody-pce-stateful-pce-optional-08





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid

[julien.meuric]

Hi Cheng,

Thank you for addressing my comments. We now can move on.

Cheers,

Julien


On 19/07/2021 11:12, Chengli (Cheng Li) wrote:
> Hi Julien,
>
> Sorry for my late reply, we have addressed the comments in revision 10.  
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-10
>
> Please check it.
>
> Many thanks,
> Cheng
>
>
> -Original Message-
> From: julien.meu...@orange.com [mailto:julien.meu...@orange.com] 
> Sent: Tuesday, June 29, 2021 12:32 AM
>
> Hi Cheng,
>
> Thanks for the update and sorry for the late feedback.
>
> I've spotted a couple of nits:
> - In the abstract, s/It further specify/It further specifies/
> - In the intro:
>     * I'd put the word "either" after the word "using" (cf. below);
>     * a space was mistakenly dropped on "aPath".
>
> About the issue left open below, the text currently says "The PCE SHOULD 
> allocated [...] and respond". Either you should mention what happens when 
> this SHOULD doesn't apply or you may consider upgrading to MUST.
>
> Regards,
>
> Julien
>
>
> On 03/06/2021 09:54, Chengli (Cheng Li) wrote:
>> Hi Julien,
>>
>> We have updated to document to address your comments, please check.
>>
>> URL:
>> https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-09.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/
>> Htmlized:   
>> https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid
>> Diff:   
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-09
>>
>> Only one comment left: 
>>
>> - The paragraph about by-PCE allocation should say what happens 
>> otherwise, i.e. error behavior.(Section 8)
>>
>> I don't know what kind of error  will happen, it seems not error will occur.
>>
>> Thanks for the deep review!
>> Cheng
>>
>>
>>
>>
>>
>> -Original Message-
>> From: Chengli (Cheng Li)
>> Sent: Saturday, May 29, 2021 9:18 AM
>> To: 'julien.meu...@orange.com' ; 
>> draft-ietf-pce-binding-label-...@ietf.org
>> Cc: pce@ietf.org
>> Subject: RE: [Pce] Shepherd's Review of 
>> draft-ietf-pce-binding-label-sid
>>
>> Hi Julien，
>>
>> Many thanks for your comments! Will address the comments and then post the 
>> new revision for discussion ASAP.
>>
>> Respect,
>> Cheng
>>
>>
>>
>>
>>
>> -Original Message-
>> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
>> julien.meu...@orange.com
>> Sent: Saturday, May 29, 2021 1:47 AM
>> To: draft-ietf-pce-binding-label-...@ietf.org
>> Cc: pce@ietf.org
>> Subject: [Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid
>>
>> Dear authors,
>>
>> Please find below the review of the aforementioned document.
>>
>> _Summary_
>> The document looks ready for publication, but the fixes below should be 
>> considered.
>>
>> _Issues_
>> None.
>>
>> _Nits_
>> --
>> Abstract
>> ---
>> - The phrase "network opacity" feels like a negative objective. How about 
>> "network confidentiality"?
>> - s/RSVP-TE signaled Traffic/RSVP-TE-signaled Traffic/
>> - s/Label Switching Path/Label Switched Path/
>>
>> --
>> 1. Introduction
>> ---
>> - s/either set up using the RSVP-TE signaling protocol or Segment 
>> Routing/set up using either the RSVP-TE signaling protocol or Segment 
>> Routing/
>> - s/headend node/head-end node/  [x2, for consistency along the I-D]
>> - s/an Segment Routing Policy/a Segment Routing Policy/
>> - s/an Segment Routed (SR) Policy/a Segment Routing (SR) Policy/
>> - s/enables instantiation/enables the instantiation/
>> - s/type of interfaces or tunnel/type of interface or tunnel/
>> - s/SID-list/SID list/
>> - s/Path Computation Element Protocol/PCE communication Protocol/
>> - s/a network controller (acting as a PCE) /a PCE (acting as a network 
>> controller)/
>> - s/SID allocated by it/SID it allocated/ OLD
>>    A PCC could report the binding label/SID allocated by it to the
>>    stateful PCE via Path Computation State Report (PCRpt) message.
>> NEW
>>    A PCC could report to the stateful PCE the binding label/SID it
>>    allocated via a Path Computation LSP State Report (PCRpt) message.
>>
>> - s/Path Computation Update Request (PCUpd) message/Path Computation 
>> LSP Update Request (PCUpd) message/
>> - s/an MPLS label or SID/an MPLS label or a SID/
>> - s/PCE based/PCE-based/
>>
>> --
>> 3. Terminology
>> ---
>> - "TLV" is flagged as "well know" in the RFC Editor's list
>> (https://www.rfc-editor.org/materials/abbrev.expansion.txt): it can safely 
>> be removed from this section (otherwise, it should have been expanded at 1st 
>> occurrence in the introduction).
>> - "PCE" is similarly flagged, but PCC and PCEP aren't, so it can be kept 
>> (adding a period at the end of the line).
>> - s/Path Computation Element Protocol/Path Computation Element 
>> communication Protocol/
>>
>> --
>> 4. Path Binding TLV
>> ---
>> - s/TLV is called/TLV called/
>> - Since it's already allocated, Figure 2 may include the codepoint, i.e.
>> "Type = 55".
>> - 

[Pce] CFP for "IP + Optical Network" 2021

[julien.meuric]

FYI

---

The 17th International Conference on
IP + Optical Network (iPOP 2021)
September 30 – October 1, 2021 (Tentative)
Virtual web conference
https://www.pilab.jp/ipop2021/

The conference is intended to share the knowledge, new findings, and
experiences on the state-of-
the-art of IP and optical networking technologies among the industry and
the academia. It features
technical sessions and exhibitions. The opportunity to participate is
open to all.

CALL FOR PRESENTATIONS
The Technical Program Committee (TPC) for iPOP 2021 is soliciting
presentation proposals for
this conference. Protocol design, experiments, theories,
implementations, and operational
experiences are solicited.
The topics of the conference will include but not be limited to the
following:

  * SDN/NFV expectation for 5G and IoT
  * Network service based on cloud/edge computing
  * Service Function Chaining (SFC)
  * AI/ML for PHY and MAC
  * AI/ML for network automation
  * Big data analytics for managing softwarized networks
  * Intent-based networking
  * Policy-based management
  * Network abstraction/virtualization/slicing
  * Control plane (OpenFlow, MPLS/GMPLS, etc.)
  * SDN for packet and optical transport networks
  * Open source software for SDN/NFV
  * Optical disaggregation and its management
  * Data center and WAN orchestration
  * Multi-layer/region networks
  * Carrier Ethernet and MPLS-TP for backhauling
  * Quality of Service (QoS) / Quality of Experience (QoE)
  * Traffic engineering, path computation element
  * Flex-grid/elastic optical networks
  * Standardization/interoperability/testbeds

If you wish to submit a topic for consideration, please send an extended
abstract of 400 words and a maximum
of 1 page, including figures and diagrams, speaker’s name, affiliation,
and contact information to the TPC at
ipop2021-...@pilab.jp. Please see https://www.pilab.jp/ipop2021/ for
more details.

Important Dates

  * Submission deadline of one-page abstract: Jul. 9, 2021
  * Notification of acceptance: Aug, 20, 2021
  * Submission deadline of final presentation slides: Sep. 10, 2021



_

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

Re: [Pce] Adoption of draft-litkowski-pce-state-sync

[julien.meuric]

Hi all,

It looks like we have support without opposition on this I-D. It's
adopted by the WG.

Authors, please submit it as draft-ietf-pce-state-sync-00 and then start
addressing the comments pointed out during the adoption poll.

Regards,

Dhruv & Julien


On 17/05/2021 15:40, julien.meu...@orange.com wrote:
> Dear all,
>
> The document draft-litkowski-pce-state-sync has reached the head of our
> adoption queue
> (https://datatracker.ietf.org/doc/draft-litkowski-pce-state-sync/).
>
> Do you consider this I-D is a good foundation for a WG item? Please
> share your feedback using the PCE mailing list by May 31.
>
> Regards,
>
> Dhruv & Julien
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid

[julien.meuric]

Hi Cheng,

Thanks for the update and sorry for the late feedback.

I've spotted a couple of nits:
- In the abstract, s/It further specify/It further specifies/
- In the intro:
    * I'd put the word "either" after the word "using" (cf. below);
    * a space was mistakenly dropped on "aPath".

About the issue left open below, the text currently says "The PCE SHOULD
allocated [...] and respond". Either you should mention what happens
when this SHOULD doesn't apply or you may consider upgrading to MUST.

Regards,

Julien


On 03/06/2021 09:54, Chengli (Cheng Li) wrote:
> Hi Julien,
>
> We have updated to document to address your comments, please check.
>
> URL:
> https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-09.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-09
>
> Only one comment left: 
>
> - The paragraph about by-PCE allocation should say what happens otherwise, 
> i.e. error behavior.(Section 8)
>
> I don't know what kind of error  will happen, it seems not error will occur.
>
> Thanks for the deep review!
> Cheng 
>
>
>
>
>
> -Original Message-
> From: Chengli (Cheng Li) 
> Sent: Saturday, May 29, 2021 9:18 AM
> To: 'julien.meu...@orange.com' ; 
> draft-ietf-pce-binding-label-...@ietf.org
> Cc: pce@ietf.org
> Subject: RE: [Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid
>
> Hi Julien，
>
> Many thanks for your comments! Will address the comments and then post the 
> new revision for discussion ASAP.
>
> Respect,
> Cheng
>
>
>
>
>
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of julien.meu...@orange.com
> Sent: Saturday, May 29, 2021 1:47 AM
> To: draft-ietf-pce-binding-label-...@ietf.org
> Cc: pce@ietf.org
> Subject: [Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid
>
> Dear authors,
>
> Please find below the review of the aforementioned document.
>
> _Summary_
> The document looks ready for publication, but the fixes below should be 
> considered.
>
> _Issues_
> None.
>
> _Nits_
> --
> Abstract
> ---
> - The phrase "network opacity" feels like a negative objective. How about 
> "network confidentiality"?
> - s/RSVP-TE signaled Traffic/RSVP-TE-signaled Traffic/
> - s/Label Switching Path/Label Switched Path/
>
> --
> 1. Introduction
> ---
> - s/either set up using the RSVP-TE signaling protocol or Segment Routing/set 
> up using either the RSVP-TE signaling protocol or Segment Routing/
> - s/headend node/head-end node/  [x2, for consistency along the I-D]
> - s/an Segment Routing Policy/a Segment Routing Policy/
> - s/an Segment Routed (SR) Policy/a Segment Routing (SR) Policy/
> - s/enables instantiation/enables the instantiation/
> - s/type of interfaces or tunnel/type of interface or tunnel/
> - s/SID-list/SID list/
> - s/Path Computation Element Protocol/PCE communication Protocol/
> - s/a network controller (acting as a PCE) /a PCE (acting as a network 
> controller)/
> - s/SID allocated by it/SID it allocated/ OLD
>    A PCC could report the binding label/SID allocated by it to the
>    stateful PCE via Path Computation State Report (PCRpt) message.
> NEW
>    A PCC could report to the stateful PCE the binding label/SID it
>    allocated via a Path Computation LSP State Report (PCRpt) message.
>
> - s/Path Computation Update Request (PCUpd) message/Path Computation LSP 
> Update Request (PCUpd) message/
> - s/an MPLS label or SID/an MPLS label or a SID/
> - s/PCE based/PCE-based/
>
> --
> 3. Terminology
> ---
> - "TLV" is flagged as "well know" in the RFC Editor's list
> (https://www.rfc-editor.org/materials/abbrev.expansion.txt): it can safely be 
> removed from this section (otherwise, it should have been expanded at 1st 
> occurrence in the introduction).
> - "PCE" is similarly flagged, but PCC and PCEP aren't, so it can be kept 
> (adding a period at the end of the line).
> - s/Path Computation Element Protocol/Path Computation Element communication 
> Protocol/
>
> --
> 4. Path Binding TLV
> ---
> - s/TLV is called/TLV called/
> - Since it's already allocated, Figure 2 may include the codepoint, i.e.
> "Type = 55".
> - s/TLV comprise of:/TLV comprises:/
> - s/and first 20 bits/and the first 20 bits/
> - s/a 16 octet IPv6 address/a 16-octet IPv6 address/
> - s/Note that, multiple/Note that multiple/
> - s/Following flag/The following flag/
> - s/For the BT as 0/When the BT is 0/  [idem w/ 1 and 2]
> - s/the 32-bits represent/the 32 bits represent/
> - s/the 128-bits represent/the 128 bits represent/
> - s/This section specify/This section specifies/
> - s/The Binding Value consist of/The Binding Value consists of/
> - s/The 128-bits IPv6 address/The 128-bit IPv6 address/
>
> --
> 5. Operation
> ---
> - s/via PCRpt message/via a PCRpt message/
> - s/send PCErr 

[Pce] Shepherd's Review of draft-ietf-pce-binding-label-sid

[julien.meuric]

Dear authors,

Please find below the review of the aforementioned document.

_Summary_
The document looks ready for publication, but the fixes below should be
considered.

_Issues_
None.

_Nits_
--
Abstract
---
- The phrase "network opacity" feels like a negative objective. How
about "network confidentiality"?
- s/RSVP-TE signaled Traffic/RSVP-TE-signaled Traffic/
- s/Label Switching Path/Label Switched Path/

--
1. Introduction
---
- s/either set up using the RSVP-TE signaling protocol or Segment
Routing/set up using either the RSVP-TE signaling protocol or Segment
Routing/
- s/headend node/head-end node/  [x2, for consistency along the I-D]
- s/an Segment Routing Policy/a Segment Routing Policy/
- s/an Segment Routed (SR) Policy/a Segment Routing (SR) Policy/
- s/enables instantiation/enables the instantiation/
- s/type of interfaces or tunnel/type of interface or tunnel/
- s/SID-list/SID list/
- s/Path Computation Element Protocol/PCE communication Protocol/
- s/a network controller (acting as a PCE) /a PCE (acting as a network
controller)/
- s/SID allocated by it/SID it allocated/
OLD
   A PCC could report the binding label/SID allocated by it to the
   stateful PCE via Path Computation State Report (PCRpt) message.
NEW
   A PCC could report to the stateful PCE the binding label/SID it
   allocated via a Path Computation LSP State Report (PCRpt) message.

- s/Path Computation Update Request (PCUpd) message/Path Computation LSP
Update Request (PCUpd) message/
- s/an MPLS label or SID/an MPLS label or a SID/
- s/PCE based/PCE-based/

--
3. Terminology
---
- "TLV" is flagged as "well know" in the RFC Editor's list
(https://www.rfc-editor.org/materials/abbrev.expansion.txt): it can
safely be removed from this section (otherwise, it should have been
expanded at 1st occurrence in the introduction).
- "PCE" is similarly flagged, but PCC and PCEP aren't, so it can be kept
(adding a period at the end of the line).
- s/Path Computation Element Protocol/Path Computation Element
communication Protocol/

--
4. Path Binding TLV
---
- s/TLV is called/TLV called/
- Since it's already allocated, Figure 2 may include the codepoint, i.e.
"Type = 55".
- s/TLV comprise of:/TLV comprises:/
- s/and first 20 bits/and the first 20 bits/
- s/a 16 octet IPv6 address/a 16-octet IPv6 address/
- s/Note that, multiple/Note that multiple/
- s/Following flag/The following flag/
- s/For the BT as 0/When the BT is 0/  [idem w/ 1 and 2]
- s/the 32-bits represent/the 32 bits represent/
- s/the 128-bits represent/the 128 bits represent/
- s/This section specify/This section specifies/
- s/The Binding Value consist of/The Binding Value consists of/
- s/The 128-bits IPv6 address/The 128-bit IPv6 address/

--
5. Operation
---
- s/via PCRpt message/via a PCRpt message/
- s/send PCErr with/send a PCErr with/
- s/existing instances/the existing instances/
- s/the old binding value/the former binding value/
- s/the old TE-PATH-BINDING TLV/the former TE-PATH-BINDING TLV/
- s/Note that, other instances/Note that other instances/
- s/a specific binding value(s)/a (or several) specific binding value(s)
- s/Note that in case of an error,/Note that, in case of an error,/
- s/can carry/can include/
- s/request withdrawal/request the withdrawal/  [x2]
- s/the old binding value/the former binding value/
- s/the old TE-PATH-BINDING TLV/the former TE-PATH-BINDING TLV/
- s/making the length field of the TLV as 4/bringing the Length field of
the TLV to 4/
- s/request PCC/request a PCC/

--
8. PCE Allocation of Binding label/SID
---
- s/on its own accord/of its own accord/  [x2]
- s/A PCC would set this bit/A PCC MUST set this bit/
- s/A PCE would set this bit/A PCE MUST set this bit/
- s/towards PCC/towards the PCC/
- s/a PCE would set this bit to 0/a PCE MUST set this bit to 0/
- s/a PCE could set/a PCE MUST set/

- OLD
A PCC could request that the PCE allocate the binding label/SID by
setting P=1, D=1, and including...
  NEW
To request that the PCE allocate the binding label/SID, a PCC MUST set
P=1, D=1, and include...

- s/The PCE would allocate/The PCE SHOULD allocate/
- The paragraph about by-PCE allocation should say what happens
otherwise, i.e. error behavior.
- s/out of scope of/out of the scope of/

--
9. Implementation Status
---
- Huawei: "An experimental code-point is used and plan to request early
code-point allocation from IANA after WG adoption." If the
implementation doesn't use the early allocated code point, I wonder if
it was worth the effort.
- Cisco: "An experimental code-point is currently used." Currently in
April 2021? Same comment as above.

--
11. Manageability Considerations
---
- s/the policy based on which PCC needs to allocates /the policy the PCC
needs to apply when allocating/
- s/Mechanisms defined/ The mechanisms defined/  [x4]
- s/to PCEP extensions defined/to the PCEP extensions defined/

--
12. IANA Considerations
---
- The new Error-Type entry should include Error-value 0 as 

[Pce] Fwd: NomCom 2021-2022 Call for Volunteers

[julien.meuric]

Dear PCE'rs,

Even if we don't meet face-to-face, the NomCom keeps working and needs
volunteers.

Thanks,

Dhruv & Julien


 Forwarded Message 
Date:   Wed, 26 May 2021 12:39:36 -0400
From:   g_e_montenegro=40yahoo@dmarc.ietf.org


Hi,

 

As you may have seen, the NomCom 2021-2022 Call for Volunteers went out
today:

 

https://mailarchive.ietf.org/arch/msg/ietf-announce/T_WVH96pH-5QVTRqd0yTT1TaPaU/

 

The IETF benefits from having a good, sizable pool of volunteers to be
NomCom members.

 

Please consider publicizing the announcement in your respective WGs.

 

Thanks,

 

Gabriel

(as NomCom Chair)

 

 

 


_

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] Adoption of draft-litkowski-pce-state-sync

[julien.meuric]

Dear all,

The document draft-litkowski-pce-state-sync has reached the head of our
adoption queue
(https://datatracker.ietf.org/doc/draft-litkowski-pce-state-sync/).

Do you consider this I-D is a good foundation for a WG item? Please
share your feedback using the PCE mailing list by May 31.

Regards,

Dhruv & Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Pending issues with draft-ietf-pce-binding-label-sid

[julien.meuric]

Hi WG,

We did not hear any objections and thus we request the authors to post
an update with a new R flag in TE-PATH-BINDING TLV as well as all the
other previously agreed changes. Regarding the term "binding label/SID",
we leave it to the authors' discretion and any further AD/IESG comment
on it.

Thanks!

Dhruv & Julien


On 07/04/2021 19:23, Dhruv Dhody wrote:
> Hi WG,
>
> We have some pending issues with draft-ietf-pce-binding-label-sid, as
> part of the WGLC, that needs more inputs from the WG.
>
> (1) Use of an explicit R flag to remove TE-PATH-BINDING TLV
> Olivier and others suggest using a new R flag to explicitly remove
> TE-PATH-BINDING. The current text requires all the TE-PATH-BINDING
> TLVs that apply from that point on to be encoded.
>
> A new R flag would have an impact on any existing
> implementation/deployment. Please confirm on the list (or to the
> chairs directly) if you object to the suggested change.
>
> (2) Use of the term "Binding Label/SID"
> Tom asked to use binding value instead.
> As per authors
> - Binding value is the term when referring to the specified value in
> the TLV
> - binding label/SID is used in the generic sense
>
> We also found label/SID or SID/label terms to be in use in multiple
> RFCs - RFC 8403, RFC 8660, RFC 8664, RFC 8665.
>
> Is the WG happy with the continued use of the term "binding label/SID"?
>
> (3) Flags related to SR Policy
> Adrian suggested removing them. There was no objection to this [1];
> authors are requested to act on this.
>
> Please provide your inputs by 13th April, so that we can make progress
> with this I-D. Working copy and Diff can be found at [2] and [3].
>
> Thanks!
> Dhruv & Julien
>
> [1] https://mailarchive.ietf.org/arch/msg/pce/ODZGisT_Tq7aMmZ8QeE91FWHqIw/
> [2]
> https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt
> [3]
> https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-07.txt=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

[julien.meuric]

Hi Tom,

What really matters for the IANA early allocation is that the behaviors
associated to the code points are clear and stable. Assuming the WG
agrees on moving to the "binding value" terminology all along the
document, then the technical specification wouldn't change (i.e. it
would clearly be backward compatible [1]) and we could update the phrase
in IANA entry accordingly at final allocation time.

Cheers,

Julien

--
[1] https://www.rfc-editor.org/rfc/rfc7120.html#section-3.2


On 27/03/2021 13:02, tom petch wrote:
> 
> Adrian
>
> I share your comments about the terminology in this I-D which is not precise, 
> failing to specify 'MPLS label' and failing to use 'MPLS label stack entry' 
> but I think that the worst part is this 'binding/Label SID' which to me is a 
> classic example of how not to choose an identifier.  The I-D does use 
> 'binding value' in one place as what appears to be one of the many different 
> terms for this concept and I think that term much better.
>
> Since this term, whatever it is, gets embedded in IANA, I said that the IANA 
> early allocation should not proceed until this is resolved, but you may not 
> take it that far.
>
> Tom Petch


_

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

Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp

[julien.meuric]

Hi all,

After discussing with Tom and the authors, we believe that a reasonable
way to progress this early allocation is to postpone the allocation of
the error codes. We'll proceed accordingly.

Enjoy the week-end,

Dhruv & Julien


On 01/02/2021 11:54, julien.meu...@orange.com wrote:
> Hi WG,
>
> We have received a request from the authors of
> draft-ietf-pce-segment-routing-policy-cp for an early code point allocation.
>
> RFC 7120 requires to meet the following criteria to proceed:
>
> 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 why. If
> the chairs hear no objections by Monday, February 15th, we will kick off
> the early allocation request.
>
> Thanks!
>
> Dhruv & Julien
>
>
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

[julien.meuric]

Hi Tom,

As agreed with the authors, we'll proceed with the early allocation
request by leaving the error codes pending upcoming updates (i.e.
request allocation for PCEP TLV and LSP object flags). This will leave
you some time to find an agreement on the final wording of the error
messages.

Thank you for your careful review,

Dhruv & Julien


On 22/03/2021 13:14, tom petch wrote:
> 
> I am unclear how much is being requested of IANA here but ..
>
> s.11.1.1 starts the registry at zero which is consistent with the rest of the 
> I-D.  Is there any need to reserve the value of zero as something special?  
> Probably not but something to consider
>
> TBD4 and TBD5 have almost identical Error-value which I think unhelpful.  The 
> wording should be more distinctive IMHO.  If this is part of the Early 
> Allocation request, then it is better to fix it now rather than getting into 
> IANA in this form. Perhaps
> 'Unable to amend the..
> 'Unable to allocate a..
> And along with TBD2  and TBD6, as in my separate e-mail, I find 'Binding 
> label/SID' clumsy and would prefer a replacement such as 'Binding value'
>
> Tom Petch




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

[julien.meuric]

Hi Adrian,

Thanks a lot for your thorough review.

Your comment about draft-ietf-pce-pcep-extension-for-pce-controller is
legitimate. Good news: it's in the RFC Editor queue
(https://www.rfc-editor.org/current_queue.php#draft-ietf-pce-pcep-extension-for-pce-controller)
and associated code points have already been allocated
(https://www.iana.org/assignments/pcep/pcep.xhtml#pcecc-capability).

Cheers,

Dhruv & Julien


On 23/03/2021 11:17, Adrian Farrel wrote:
> Hi Julien, WG, authors.
>
> Code point allocation: Is the request for all of the code points in the
> document? What about the not-yet-allocated code point from
> [I-D.ietf-pce-pcep-extension-for-pce-controller]. This spec can't be
> implemented without it.
>
> WG last call: I have a few questions/issues/nits below.
>
> Best,
> Adrian
>
> == Questions / Issues ==
>
> Abstract
>
> What is the difference between "a Binding Segment Identifier (BSID)" and
> a "binding Segment-ID (SID)"?
>
> ---
>
> Abstract
>
> "Such a binding label/SID"
> This is the first use of "label". You need some context.
>
> ---
>
> Abstract
>
>This document proposes
>an approach for reporting binding label/SID to Path Computation
>Element (PCE) for supporting PCE-based Traffic Engineering policies.
>
> Who does the reporting?
> Same in Section 1 top of page 4.
>
> ---
>
> 3.
>
>o  BT = 0: The binding value is an MPLS label carried in the format
>   specified in [RFC5462] where only the label value is valid, and
>   other fields MUST be considered invalid.  The Length MUST be set
>   to 7.
>
> I don't think that RFC 5462 is the right reference. That document simply
> renames a field in the MPLS label stack entry.
>
> So, are you carrying an MPLS label or an MPLS label stack entry? Either
> is possible, although since you're only interested in the label, it
> might be more normal to carry just the label value in the least
> significant 20 bits of the binding value field. That would be consistent
> with a Length of 7.
>
> But, if you want to carry the full label stack entry (with the other
> fields  ignored) then perhaps...
>o  BT = 0: The binding value is an MPLS label carried in an MPLS 
>   label stack entry format as specified in [RFC3032] where only the
>   label value is valid, and other fields MUST be ignored.  The
>   Length MUST be set to 8.
>
> This would be more consistent with:
>o  BT = 1: Similar to the case where BT is 0 except that all the
>   fields on the MPLS label entry are set on transmission.  However,
>   the receiver MAY choose to override TC, S, and TTL values
>   according its local policy.  The Length MUST be set to 8.
> But here you may want a little more clarity as:
>o  BT = 1: Similar to the case where BT is 0 except that all the
>   fields of the MPLS label stack entry are set on transmission of
>   the PCEP message containing the TLV.  A PCC receiver of this TLV 
>   in a PCEP message MAY choose to override TC, S, and TTL values 
>   according its local policy.  The Length MUST be set to 8.
>
> But, at the bottom of the section...
>For the BT as 0, the 20 bits represent the MPLS
>label.  For the BT as 1, the 32-bits represent the label stack entry
>as per [RFC5462].
> Which is going back on itself (and using the wrong reference).
>
> Just make a decision on the meaning of BT=0 and make the text clean.
>
> ---
>
> 3.
>
> I'm a bit puzzled as to why this document defines two flags for the 
> Path Binding TLV Flags field, when this document clearly doesn't use or
> depend on them.
>
> In order to not make [I-D.ietf-spring-segment-routing-policy] a 
> normative reference, perhaps you should not mention the specific bits,
> create the registry (in 11.1.1) as empty, and simply not that 
> [I-D.ietf-spring-segment-routing-policy] defines some flags.
>
> (Obviously, [I-D.ietf-spring-segment-routing-policy] will need to make
> assignments from the registry.)
>
> ---
>
> 4.
>
>Multiple TE-PATH-BINDING TLVs are allowed to be present in the same
>LSP object.  This signifies the presence of multiple binding SIDs for
>the given LSP.
>
> If one of these contains a bad value, and a PCErr is sent according to 
> the previous paragraph, what happens to all the other Binding Values?
> Are they used or discarded?
>
> ---
>
> 4.
>
>For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the
>SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV
>by setting the BT (Binding Type) to 3, instead of 2.  The choice of
>interpreting SRv6 Endpoint Behavior and SID Structure when none is
>explicitly specified is left up to the implementation.
>
> I puzzled about the alternative to "RECOMMENDED".  I wondered if the
> second sentence was meant to offer that guidance, but perhaps it is
> intended to only to cover the case when no Path Binding TLV is present.
> Two concepts in one paragraph?
>
> ---
>
> 4.
>
>If a PCC wishes to withdraw 

Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

[julien.meuric]

Hi Hooman,

To respond to your comment, we usually follow the list below:
1- Gauge interest on the mailing list about an I-D,
2- Gauge interest when the I-D is presented to the WG,
3- If enough of 1 and 2, do a 1st poll in the room during WG meetings,
4- If enough of 3, add the I-D to the adoption queue.

Without face-to-face meeting, we sometimes skip 3. Considering its
depth, we often revise the order in the adoption queue with respect to
consensus and document maturity (consider thanking Dhruv for that). As a
result, your effort should focus on progressing technical discussions
rather than process requests: I believe the discussion in progress will
end up in improving your I-D, which will be valuable whatever the
further steps.
Contrary to what I've read, please note PCE-CC isn't a prerequisite and
there's no such statement like "the working group is only dictating
PCECC and is not open to any other option but PCECC for the purpose of
programming the PCC and multicast".

Thanks,

Julien


On 10/03/2021 04:39, Bidgoli, Hooman (Nokia - CA/Ottawa) wrote:
> HB> Dear chairs I am not sure if I understand the criteria of how
> drafts move from “Individual documents that authors consider ready for
> WG adoption” to “WG Adoptoin call queue”. I am guessing it is chairs
> consent that moves the draft between the 2 queues, not the adaptation
> request? 




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

[julien.meuric]

Hi all,

This message initiates a 2-week PCE WG Last Call for
draft-ietf-pce-binding-label-sid-07. Please review and share your
feedback, whatever it is, using the PCE mailing list. This WGLC will end
on Thursday April 1st (no kidding).


Moreover, we have received a request from the authors for a code point
allocation to support interoperability testing.

RFC 7120 requires to meet the following criteria to proceed:

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 why. If
the chairs hear no objections by Thursday, March 25th, we will kick off
the "early" allocation request.

Thanks,

Dhruv & 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

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

[julien.meuric]

Hi Adrian,

Thank you for your feedback.

If evidence is needed, how about binding label?
https://tools.ietf.org/html/draft-ietf-pce-binding-label-sid-06#section-11.2
Note it's also reused in
https://tools.ietf.org/html/draft-ietf-pce-sr-path-segment-03#section-4.2

Have a nice week-end,

Julien


On 18/02/2021 16:57, Adrian Farrel wrote:
> Thanks to the authors for cleaning this up a lot since last time.
>
> I don't object to adoption. Would be nice to have evidence of someone
> needing a bit now, but by the time this becomes an RFC it is reasonably
> possible.
>
> Adrian
>
> -Original Message-
> From: Pce  On Behalf Of Dhruv Dhody
> Sent: 01 February 2021 17:48
>
> Hi WG,
>
> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.
>
> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03
>
> This is a small draft that extends the flags in the LSP Objects by
> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
> sub-registry "LSP Object Flag Field" is almost fully assigned.
>
> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field
>
> 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.
>
> Please respond by Monday 15th Feb.
>
> Thanks!
> Dhruv & Julien
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>


_

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

Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp

[julien.meuric]

Hi Tom,

Thank you for your valuable feedback.

Some of the issues you point out are easy to address and we've already
requested the authors to revise the I-D accordingly. To fully resolve
your concern, could you please point any other specific parts where you
feel you have to "interpret the words the way you think they should have
been"? If you even have some text to suggest, that could smoothly ease
the update.

Thanks,

Dhruv & Julien


On 17/02/2021 12:46, tom petch wrote:
> 
> 
> I am sure that IANA will cope because they always do, but it will be by 
> reading between the lines, applying intelligence to what the authors may have 
> meant, and so on.  Editorially this is a poor I-D (as yet), and that quality 
> verges on the technical aspects.
>
> Thus 7.3 says the I-D defines five new TLV and lists four; this also occurs 
> in the body of the I-D.  A reader might also notice the absence of TBD2 and 
> wonder.
>
> Or the new Association.  Thus needs an identifier.  Trouble is, the I-D uses 
> (at least) three different ones; this looseness of terminology can lead to 
> problems down the line.  (MPLS I see as a classic in how not to specify IANA 
> registries and I see this heading the same way).
>
> Likewise the identifiers used in s.7 do not match those in current use, a 
> good way of storing up future trouble.
>
> Is the specification adequate?  Only if you do not take it literally and 
> interpret the words the way you think they should have been.
>
> Tom Petch
>


_

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

Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

[julien.meuric]

Hi Hooman,

Please keep in mind that adoption isn't a prerequisite to start getting
input. You've already started to get some. Technical discussion on the
list is part of the normal working process and it helps the chairs to
gauge WG consensus.

Note the adoption queue on the wiki page. If you want to progress your
work, please consider both actions:
- helping flushing the queues by sharing your feedback on the mailing
list, especially during adoption polls and WG last calls;
- socializing your I-D by addressing received comments: that doesn't
mean including every single suggestion, but in case the authors disagree
with a point made, the WG deserves some elaboration.

Thanks,

Julien


On 09/02/2021 16:06, Bidgoli, Hooman (Nokia - CA/Ottawa) wrote:


> HB> sure this is cosmetics and we will follow the WG suggestion, that said 
> this should not stop the adaptation call. The sooner we have adaptation call 
> the sooner we can have input.
>
> HB> to close, as you mentioned some of the co-authors have vast experience in 
> PCE WG and the same co-authors have agreed and recommended ERO 
> implementation. As such I ask the chairs for adaptation call again ASAP. We 
> will fix the cosmetics to be inline with WG recommendations asap.


_

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] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp

[julien.meuric]

Hi WG,

We have received a request from the authors of
draft-ietf-pce-segment-routing-policy-cp for an early code point allocation.

RFC 7120 requires to meet the following criteria to proceed:

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 why. If
the chairs hear no objections by Monday, February 15th, we will kick off
the early allocation request.

Thanks!

Dhruv & Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04

[julien.meuric]

Hi all,

Co-author hat on, I support the adoption the I-D and second Olivier in
agreeing with Dhruv's point.

Cheers,

Julien


On 12/01/2021 11:38, Dhruv Dhody wrote:
> Hi WG,
>
> The response has been limited so far. Thanks to Oliver for responding
> to the comments.
>
> Since the adoption period coincided with holidays, we are extending
> the adoption call for another week (i.e. Monday 18th Jan). We *need*
> to hear from more of you before taking a call. Please respond with
> your support (or not) for this work and if this I-D is a good basis to
> be further refined under the control of the WG.
>
> Regards,
> Dhruv
>
> On Fri, Jan 8, 2021 at 2:57 PM Dhruv Dhody  wrote:
>> Hi WG,
>>
>> Happy New Year!
>>
>> Just a reminder, the WG Adoption poll ends on Monday 11th Jan, please
>> respond to the call with your support (or not), comments, etc.
>> Please be more vocal on the list [1].
>>
>> Thanks!
>> Dhruv & Julien
>>
>> [1] 
>> https://datatracker.ietf.org/meeting/109/materials/slides-109-pce-1-introduction-01
>>> Please be Vocal
>>>
>>> o During WG Adoption and WG LC calls, the response is less.
>>>
>>> o Please be vocal on the list to help us gauge the consensus better.
>>>
>>> o The working group mailing lists are looked at by the IESG, IAB, and 
>>> others (internal and external to IETF) to determine interest/participation 
>>> level in our standards process.
>>>
>>> o Please review ideas from your peers, these are community outputs of the 
>>> working group as a whole.
>>>
>> On Fri, Dec 18, 2020 at 6:22 PM Dhruv Dhody  wrote:
>>> Hi WG,
>>>
>>> This email begins the WG adoption poll for
>>> draft-dugeon-pce-stateful-interdomain-04.
>>>
>>> https://datatracker.ietf.org/doc/html/draft-dugeon-pce-stateful-interdomain-04
>>>
>>> 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.
>>>
>>> To accommodate for the holiday season, this adoption poll will end on
>>> 11th Jan 2021 (Monday).
>>>
>>> Thanks!
>>> Dhruv
> 


_

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] Fwd: secdir review of draft-ietf-pce-association-policy-15

[julien.meuric]

FYI

 Forwarded Message 
Date:   Thu, 31 Dec 2020 11:41:09 -0800
From:   Scott G. Kelly 
To: sec...@ietf.org , i...@ietf.org ,
draft-ietf-pce-association-policy@ietf.org


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

The summary of the review is ready.

From the abstract, this document introduces a simple mechanism to
associate policies to a group of Label Switched Paths (LSPs) via an
extension to the Path Computation Element (PCE) Communication Protocol
(PCEP).

The security considerations section references security considerations
from RFCs 5394, 5440, 8231, 8281, 8408, and 8697. In addition, it
recommends securing sessions with TLS in accordance with RFCs 8253 and 7525.

Because this protocol extension utilizes TLVs, there is an explicit call
for care in decoding and utilizing these TLVs due to the potential for
attack via malformed payloads.

I'm not a routing expert, but I think the authors have adequately
covered security considerations for this extension.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll on draft-dugeon-pce-stateful-interdomain-04

[julien.meuric]

Hi Hari,

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

Cheers,

Julien


On 18/12/2020 23:11, 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




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-zhao-pce-pcep-extension-pce-controller-sr-09?

[julien.meuric]

Hi all,

It is time to close this poll. We have a consensus to put this document
into the hands of the PCE WG.

Authors, please submit the same I-D as
draft-ietf-pce-pcep-extension-pce-controller-sr-00.

Thanks,

Dhruv & Julien


On 26/11/2020 16:34, julien.meu...@orange.com wrote:
> Hi all,
>
> PCECC extensions are progressing towards the IESG. It is time to share
> your thoughts about draft-zhao-pce-pcep-extension-pce-controller-sr-09.
> Do you believe the I-D is a right foundation for a PCE WG item? Please
> use the PCE mailing list to express your comments, support or
> disagreement, including applicable rationale, especially for the latter.
>
> Thanks,
>
> Dhruv & Julien
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Adoption of draft-zhao-pce-pcep-extension-pce-controller-sr-09?

[julien.meuric]

Hi all,

PCECC extensions are progressing towards the IESG. It is time to share
your thoughts about draft-zhao-pce-pcep-extension-pce-controller-sr-09.
Do you believe the I-D is a right foundation for a PCE WG item? Please
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latter.

Thanks,

Dhruv & Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd's Review of draft-ietf-pce-pcep-extension-for-pce-controller-07

[julien.meuric]

Hi Shuping,

Thanks for the update. Please see [JM] below.

Cheers,

Julien


On 14/11/2020 07:17, Pengshuping (Peng Shuping) wrote:
> Hi Julien,
>
> Thank you for your comments. We have handled the shepherd review and an 
> update is posted. Please find the diff and responses inline. Thank you!
>
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
> and 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-pce-pcep-extension-for-pce-controller-07=draft-ietf-pce-pcep-extension-for-pce-controller-08
>
> Best regards, 
> Shuping 
>
>> -Original Message-
>> From: julien.meu...@orange.com [mailto:julien.meu...@orange.com]
>> Sent: Wednesday, October 21, 2020 10:51 PM
>>
>> Hi authors of draft-ietf-pce-pcep-extension-for-pce-controller,
>>
>> Please find below my review of the aforementioned I-D.
>>
>> Regards,
>>
>> Julien
>>
>> ---
>>
>> *Main Concerns*
>>
>> - From a PCECC operation stand point, it feels odd that what is referred to 
>> as
>> "basic PCECC LSP setup" is actually PCC triggered, whereas the PCE-initiatied
>> option does exist as well. Even though it adds an additional PCInitiate
>> message, I would suggest to define the latter as the "basic setup", which
>> would not only address that comment, but would also mitigate the following
>> concerns on PCC-triggered setup.
>> - I have 2 issues with PCC-triggered setup:
>>   * it adds LSP characteristics and egress-related information in the ingress
>> PCC, which is not straightforward in a PCECC context (certainly not for a
>> "base setup");
>>   * the behavior triggered by the initial PCRpt is implementation-specific in
>> the PCE: as per section 5.8.3 of RFC 8231, I could configure my PCE to just
>> store the reported info, or make it wait for whatever event before actually
>> starting something ("PCE *decides* to update the LSP", "the PCE *can*
>> modify LSP parameters of delegated LSPs").
>>   => Assuming the PCC-triggerred option is really needed, this limitation
>> should be more explicit.
> The order has been changed and the text is added to say that in case of 
> PST=PCECC it SHOULD calculate and set up the path based on the PCECC 
> technique.
[JM] Thank you for the changes. I believe both of them do improve the I-D.

>> - At the end of section 6.1, some errors are defined with respect to the
>> number of CCI objects in a message. If the ingress PCE has a particular role
>> (e.g. PLSP-ID allocation), how do other PCCs know if they are transit or
>> egress to be able to check the number of CCIs they get?
>> AFAIU, at 1st setup, only inconsistencies between the O bit and the number
>> of CCIs can trigger an error; on LSP updates the node may add an additional
>> check with respect to its role before the update: those situations need to be
>> clarified.
> The source and destination are part of the LSP-IDENTIFIERS TLV, that can help 
> identify Ingress, egress and Transit. The text has been added for that.
[JM] Fine, thanks.

>> - There is no reference to RFC 8741. Is it applicable? If so, then how?
> Added.
[JM] OK, fine.

>> *Nits*


>> - Figure 1: all figures have the same message ordering, though the order only
>> matters when using PCC-allocated labels (leaving initial and last messages
>> apart); have you considered shuffling the message order a bit on figures for
>> PCE-allocated cases?
> It's true from the point of view of the messages on wire and thus we don't 
> put this in the specification, but internally the PCE would still allocate 
> label from the internal space from Egress towards Ingress as it would need to 
> make sure the in-label and out-label matches and processing would be in the 
> same order. Thus it is better to keep the ordering the same!
[JM] This looks implementation specific to me. I don't see anything
precluding pushing multiple CCIs in parallel, relying on crankback by
updating both ends of a link in case of initial allocation issue. I
agree on one thing: shuffling the figure may not be worth the effort.
[JM] By the way, some of the arrows on the figures deserve to be polished:
  * end point alignment, space vs. dash...
  * spacing after comas are inconsistent (no space seem to be readable).



>> --
>> Section 12.
>> ---
>> - The following references may be moved from Normative to Informative:
>>   * RFC 7420,
>>   * RFC 7225,
>>   * RFC 8126,
>>   * RFC 8174,
>>   * RFC 8233.
>>
> Moved RFC 7420, RFC 7525.
> RFC 8126, RFC 8174 are kept as Normative as per recently published RFCs.
> RFC 8233 is a wrong reference, it should be RFC 8232 (and moved to 
> informational).
[JM] Fine for 8174. RFC 8126 is targeted to document authors, it isn't
mandatory reading for readers/implementers. But that's a super-nit I'd
be happy to defer to the RFC Editor. ;-)




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Shepherd's Review of draft-ietf-pce-pcep-extension-for-pce-controller-07

[julien.meuric]

Hi authors of draft-ietf-pce-pcep-extension-for-pce-controller,

Please find below my review of the aforementioned I-D.

Regards,

Julien

---

*Main Concerns*

- From a PCECC operation stand point, it feels odd that what is referred
to as "basic PCECC LSP setup" is actually PCC triggered, whereas the
PCE-initiatied option does exist as well. Even though it adds an
additional PCInitiate message, I would suggest to define the latter as
the "basic setup", which would not only address that comment, but would
also mitigate the following concerns on PCC-triggered setup.
- I have 2 issues with PCC-triggered setup:
  * it adds LSP characteristics and egress-related information in the
ingress PCC, which is not straightforward in a PCECC context (certainly
not for a "base setup");
  * the behavior triggered by the initial PCRpt is
implementation-specific in the PCE: as per section 5.8.3 of RFC 8231, I
could configure my PCE to just store the reported info, or make it wait
for whatever event before actually starting something ("PCE *decides* to
update the LSP", "the PCE *can* modify LSP parameters of delegated LSPs").
  => Assuming the PCC-triggerred option is really needed, this
limitation should be more explicit.
- At the end of section 6.1, some errors are defined with respect to the
number of CCI objects in a message. If the ingress PCE has a particular
role (e.g. PLSP-ID allocation), how do other PCCs know if they are
transit or egress to be able to check the number of CCIs they get?
AFAIU, at 1st setup, only inconsistencies between the O bit and the
number of CCIs can trigger an error; on LSP updates the node may add an
additional check with respect to its role before the update: those
situations need to be clarified.
- There is no reference to RFC 8741. Is it applicable? If so, then how?


*Nits*
--
Global
---
- Consistency on capitalization of ingress/transit/egress to be corrected.
--
Abstract
---
- s/PCE-based central controller (PCECC)/PCE-based Central Controller
(PCECC)/
- s/"calculated/setup"/"calculated/set up"/
- s/each network devices/each network device/
--
Section 1.
---
- s/offload path computation function/offload the path computation function/
- s/PCE-based central controller (PCECC)/PCE-based Central Controller
(PCECC)/
- s/such a way that, extensions/such a way that extensions/
- s/extensions for other use cases is/extensions for other use cases are/
--
Section 4.
---
- s/PCE speaker supporting/A PCE speaker supporting/
- s/PCE speaker needs/A PCE speaker needs/
- s/needs the means/needs means/
- s/PCECC based LSP/PCECC-based LSPs/
- s/PCECC based label allocations/PCECC-based label allocations/
- s/provide a means/provide a mean/  [x2]
- s/between PCE and PCC/between the PCE and the PCC/
--
Sections 5. & 5.1.
---
- s/PCE as the Central Controller/PCE as a Central Controller/
- s/reuses existing Active stateful PCE mechanism/reuses the existing
active stateful PCE mechanism/
- s/control the LSP/control LSPs/
--
Section 5.4.
---
- s/the PCEP speaker MUST send a PCErr/the receiving PCEP speaker MUST
send a PCErr/
- OLD
   [...] If the PCEP
   Speakers support the extensions of this draft but did not advertise
   this capability attempts a PCECC operation then a PCErr message with
   Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted
   PCECC operations when PCECC capability was not advertised) will be
   generated and the PCEP session will be terminated.
  NEW
   [...] If a PCEP speaker
   which supports the extensions of this draft but did not advertise
   this capability attempts a PCECC operation, then a PCErr message with
   Error-Type=19 (Invalid Operation) and Error-Value=TBD3 (Attempted
   PCECC operations when PCECC capability was not advertised) MUST be
   generated by its peer and the PCEP session will be terminated.

- s/PCECC-CAPABILITY sub-TLV/the PCECC-CAPABILITY sub-TLV/  [x3]
- s/STATEFUL-PCE-CAPABILITY TLV/the STATEFUL-PCE-CAPABILITY TLV/  [x2]
- s/in OPEN Object/in the OPEN Object/
- s/it MUST send/the receiving peer MUST send/
- s/and I flag/and the I flag/
--
Section 5.5.
---
- s/pertaining to PCECC/pertaining to a PCECC/
- s/the PCECC LSP is intended/that PCECC LSP is intended/
--
Section 5.5.1.
---
- s/Basic PCECC LSP set up/Basic PCECC LSP Setup/
- s/included for PCECC LSP/included for PCECC LSPs/
- s/"so the transit LSR could"/"so a transit/egress LSR could"/
- s/include SPEAKER-ENTITY-ID TLV/include the SPEAKER-ENTITY-ID TLV/
- OLD
   [...] sets up
   the path by sending PCInitiate message to each node along the path of
   the LSP.  The PCC generates a Path Computation State Report (PCRpt)
   and includes the central controller instruction (CCI) and the
   identified LSP.  The CC-ID uniquely identifies the central controller
   instruction within a PCEP session.  The PCC further responds with the
   PCRpt messages including the CCI and LSP objects.
  NEW
   [...] sets up
   the path by sending a PCInitiate message to each 

Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

[julien.meuric]

Dear WG,

This LC has ended. Some comments have been discussed on the list:
authors, please resolve them and publish a revised document accordingly.

Thanks,

Dhruv & Julien


On 05/08/2020 18:18, julien.meu...@orange.com wrote:
> Hi all,
>
> This message initiates a 3-week WG Last Call on
> draft-ietf-pce-pcep-extension-for-pce-controller-06. Please review and
> share your feedback, whatever it is, using the PCE mailing list.
> This LC will end on Wednesday August 26, 11:59pm (any timezone).
>
> Please note that this I-D is related to
> draft-zhao-pce-pcep-extension-pce-controller-sr which is already in our
> WG adoption queue.
>
> Thanks,
>
> Dhruv & Julien
>




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

[julien.meuric]

Hi all,

This message initiates a 3-week WG Last Call on
draft-ietf-pce-pcep-extension-for-pce-controller-06. Please review and
share your feedback, whatever it is, using the PCE mailing list.
This LC will end on Wednesday August 26, 11:59pm (any timezone).

Please note that this I-D is related to
draft-zhao-pce-pcep-extension-pce-controller-sr which is already in our
WG adoption queue.

Thanks,

Dhruv & 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] Fwd: Nomcom 2020-2021 Second Call For Volunteers

[julien.meuric]

Hi PCE WG,

You may consider volunteering for the new NomCom. Please note that 2 of
the Routing ADs are going to reach the end of term in 2021.

Cheers,

Julien


 Forwarded Message 
Date:   Wed, 10 Jun 2020 11:54:56 -0700
From:   NomCom Chair 2020 


This is the second sending of the call for volunteers for the 2020-2021
NomCom.

I wanted to mention a few updates from the previous email (sent 2 weeks
ago):
- I've fixed the URL at the bottom of the email to point to
https://datatracker.ietf.org/nomcom/2020/ instead of /2019/. This was a
test to see if anyone was paying attention. Apparently, some people were. ;)
- The IETF 108 registration form includes a checkbox that will let you
volunteer. You can use this instead of emailing me, when you register
for IETF 108.
- I currently have 39 volunteers. Last year had 149. I need more volunteers!
-
The IETF NomCom appoints people to fill the open slots on the LLC, IETF
Trust, the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random
way from a pool of volunteers. The more volunteers, the better chance we
have of choosing a random yet representative cross section of the IETF
population.

The details of the operation of the NomCom can be found in BCP 10 (RFC
8713). RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788
(one-off update to RFC 8713 / BCP 10) to tell us who is eligible to
volunteer:

Members of the IETF community must have attended at least three of
the last five in-person IETF meetings in order to volunteer.

The five meetings are the five most recent in-person meetings that
ended prior to the date on which the solicitation for NomCom
volunteers was submitted for distribution to the IETF community.
Because no IETF 107 in-person meeting was held, for the 2020-2021
Nominating Committee those five meetings are IETFs
102 [Montreal, Canada; July 2018],
103 [Bangkok, Thailand; November 2018],
104 [Prague, Czech Republic; March 2019],
105 [Montreal, Canada; July 2019], and 106 [Singapore; November 2019].

Keep in mind that eligibility is based on in-person attendance at the
five listed meetings. You can check your eligibility at:
https://www.ietf.org/registration/nomcom.py.

If you qualify, please volunteer. Before you decide to volunteer, please
remember that anyone appointed to this NomCom will not be considered as
a candidate for any of the positions that the 2020 - 2021 NomCom is
responsible for filling.

People commonly volunteer by ticking the box on IETF registration forms.
The IETF 106 form did not ask whether people were willing to volunteer.
IETF 107 did ask, but all those registrations were canceled. I have
asked the Secretariat if it is possible to get the list if volunteers
from canceled IETF 107 registrations. If that list is available, I will
contact all who are verified as eligible. But given the uncertainty of
this process, I would encourage people to volunteer directly (see the
bottom of this email for instructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF
meeting, and thus the positions for which this NomCom is responsible, are

IETF Trust:
Joel Halpern

LLC:
Maja Andjelkovic

IAB:
Jari Arkko
Jeff Tantsura
Mark Nottingham
Stephen Farrell
Wes Hardaker
Zhenbin Li

IESG:
Alissa Cooper, IETF Chair/GEN AD
Alvaro Retana, RTG AD
Barry Leiba, ART AD
Deborah Brungard, RTG AD
Éric Vyncke, INT AD
Magnus Westerlund, TSV AD
Roman Danyliw, SEC AD
Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the
General area has 1; all other areas have 2 ADs. Thus, all areas (that
have more than one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and should
be completed in January 2021. The NomCom will have regularly scheduled
conference calls to ensure progress. There will be activities to collect
requirements from the community, review candidate questionnaires, review
feedback from community members about candidates, and talk to candidates.

While being a NomCom member does require some time commitment it is also
a very rewarding experience.

As a member of the NomCom it is very important that you be willing and
able to attend either videoconference or in-person meetings (which may
not happen) during 14-20 November (IETF 109 - Bangkok) to conduct
interviews. Videoconference attendance will be supported whether or not
there are in-person meetings. Orientation and setting of the NomCom
schedule will be done by videoconference during the week 20-24 July
(exact time and date to be determined after NomCom membership is
finalized on July 12), the week prior to IETF 108. Being at IETF 110
(Prague) is not essential.

Please volunteer by sending me an email before 23:59 UTC June 24, 2020,
as follows:

To: nomcom-chair-2...@ietf.org
Subject: 

Re: [Pce] Early code point allocation for draft-ietf-pce-association-policy

[julien.meuric]

Hi all,

As we have not received any objection, we consider that we have a
consensus on this early codepoint allocation. We are thus going to
proceed with the request.

Cheers,

Dhruv & Julien


On 22/04/2020 19:07, Dhruv Dhody wrote:
> Hi WG,
>
> We have received a request from the authors of
> draft-ietf-pce-association-policy for an early code point allocation.
>
> RFC 7120 requires to meet the following criteria to proceed:
>
>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, May 1st, we
> will kick off the early allocation request.
>
> Best regards and stay safe,
>
> Dhruv & 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

Re: [Pce] Agenda building for IETF 107

[julien.meuric]

Hi PCE'rs,

The slot requests we've received so far don't look in a rush. We believe
it'll be more convenient to skip the proposed April 7 and set up a
virtual meeting later, e.g. in May and June, hopefully when the global
situation resolves.

We'll poll the list on time to identify a date and a time slot that will
fit the majority.

Take care,

Dhruv & Julien


On 11/03/2020 11:20, Dhruv Dhody wrote:
> Hi WG,
>
> By now you would have seen the note from the IESG regarding the
> in-person IETF 107 meeting [1]. We are still waiting for further
> instructions on further planning of the virtual WG session. Please
> bear with us.
>
> We are still accepting slot request on the WG agenda, please make the
> request SOON, this would also help us in planning the virtual WG
> meeting.
>
> In the meantime, the mailing list is always open for business, please
> use it to describe the motivation for your new drafts, list updates to
> your existing I-Ds, discuss open issues etc.
>
> Take care!
> Dhruv & Julien
>
> [1] https://mailarchive.ietf.org/arch/msg/ietf/wxgxvqtHNdtuHqoXAjSqJulrrCA/
>
> On Wed, Mar 4, 2020 at 11:12 AM Dhruv Dhody  wrote:
>> Hi WG,
>>
>> The PCE WG session in Vancouver is scheduled for Tuesday Afternoon
>> session I [1]. If you need some face-to-face time to progress some
>> work, please send a slot request to the chairs/secretary directly by
>> Friday March 13th including:
>> - the draft(s) you want to discuss,
>> - the expected presenter name, (mention clearly if the presenter would
>> be remote)
>> - the requested duration, including question time as part of the slot,
>> - the reason why you want to be on the agenda; What do you want to
>> achieve? Why is a presentation necessary to achieve it?
>>
>> Please note - Asking for a slot does not mean you will get one. We
>> will be prioritizing moving WG work first as well as drafts that were
>> discussed on the mailing list. Please make sure to introduce your new
>> draft or summarize an update in the mailing list. The last date to
>> submit drafts is Monday March 9th [2].
>>
>> Thanks!
>> PCE Chairs & Secretary
>>
>> [1] https://datatracker.ietf.org/meeting/107/agenda.html
>> [2] https://datatracker.ietf.org/meeting/important-dates/


_

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] Fwd: Last Call: (Working Group GitHub Administration) to Informational RFC

[julien.meuric]

FYI


 Forwarded Message 
Subject:Last Call: 
(Working Group GitHub Administration) to Informational RFC
From:   The IESG 
Reply-To:   last-c...@ietf.org



The IESG has received a request from the GitHub Integration and Tooling WG
(git) to consider the following document: - 'Working Group GitHub
Administration'
 as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-02-28. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.

Abstract


The use of GitHub in IETF working group processes is increasing.
This document describes possible uses and conventions for working
groups which are considering starting to use GitHub. It does not
mandate any processes, and does not require changes to the processes
used by current and future working groups not using GitHub.

Discussion of this document takes place on the ietf-and-github
mailing list (ietf-and-git...@ietf.org), which is archived at
.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-git-github-wg-configuration/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-git-github-wg-configuration/ballot/


No IPR declarations have been submitted directly on this I-D.




___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

_

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

Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

[julien.meuric]

Hi Rakesh,

Thanks for the quick update. We're ready to adopt this version. You may
now submit it as draft-ietf-pce-sr-bidir-path-00.

Cheers,

Dhruv & Julien


On 06/02/2020 18:40, Rakesh Gandhi wrote:
> Hi Julien,
> We have posted a revised draft 07 to address the comment on the author
> list.
> We plan to address the remained comments in the adopted revision.
> Please let us know if ok to post draft-ietf-pce-sr-bidir-path-00.
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-li-pce-sr-bidir-path-07
> https://datatracker.ietf.org/doc/html/draft-li-pce-sr-bidir-path-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-li-pce-sr-bidir-path-07
>
> Thanks,
> Rakesh (behalf of authors)
>
>
>
> On Wed, Feb 5, 2020 at 4:09 PM  > wrote:
>
> Hi all,
>
> This I-D has enough support to be adopted.
>
> Before we proceed, we'd like to see an update addressing at least the
> issue about the number of names on the front page. Authors, please
> submit a -07 version accordingly, so that we can move the draft
> forward.
>
> Thanks,
>
> Dhruv & Julien
>
>
> On 17/01/2020 11:12, julien.meu...@orange.com
>  wrote:
> > Hi all,
> >
> > It is time to share your thoughts about
> draft-li-pce-sr-bidir-path-06.
> > Do you believe the I-D is a right foundation for a PCE WG item?
> Please
> > use the PCE mailing list to express your comments, support or
> > disagreement, including applicable rationale, especially for the
> latter.
> >
> > Thanks,
> >
> > Dhruv & Julien
> >
> > ___
> > Pce mailing list
> > Pce@ietf.org 
> > https://www.ietf.org/mailman/listinfo/pce
>
>
> ___
> Pce mailing list
> Pce@ietf.org 
> https://www.ietf.org/mailman/listinfo/pce
>


_

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

Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

[julien.meuric]

Hi all,

This I-D has enough support to be adopted.

Before we proceed, we'd like to see an update addressing at least the
issue about the number of names on the front page. Authors, please
submit a -07 version accordingly, so that we can move the draft forward.

Thanks,

Dhruv & Julien


On 17/01/2020 11:12, julien.meu...@orange.com wrote:
> Hi all,
>
> It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.
> Do you believe the I-D is a right foundation for a PCE WG item? Please
> use the PCE mailing list to express your comments, support or
> disagreement, including applicable rationale, especially for the latter.
>
> Thanks,
>
> Dhruv & Julien
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] CFP for the 16th International Conference on IP + Optical Network (iPOP 2020)

[julien.meuric]

Hi all,

The CFP is available at:  https://www.pilab.jp/ipop2020/proposals/cfp.html.

The important dates are the following;
    Submission deadline of one-page abstract:  February 28, 2020
    Notification of acceptance:  April 2, 2020
    Submission deadline of final presentation slides:  May
8, 2020

Cheers,
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] Adoption of draft-li-pce-sr-bidir-path-06?

[julien.meuric]

Hi all,

It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.
Do you believe the I-D is a right foundation for a PCE WG item? Please
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latter.

Thanks,

Dhruv & Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Fwd: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-03.txt

[julien.meuric]

Hi all,

The I-D defining the IGP extensions to discover the PCEP security
capabilities was presented to the PCE WG during IETF 105. Please be
aware that it is progressing as an LSR WG document
(https://mailarchive.ietf.org/arch/msg/lsr/1CqjNObC5hoZaKDMrVTGwO0Axd0)
and note particularly the agreed wording of section 4:
"
   The introduction of the additional sub-TLVs should be viewed as an
   exception to the [RFC5088][RFC5089] policy justified by the need to
   know the new information prior to establishing a PCEP session.  The
   restrictions defined in [RFC5089][RFC5089] should still be considered
   to be in place.
"

Cheers,

Dhruv & Julien


 Forwarded Message 
Date:   Thu, 31 Oct 2019 23:23:54 -0700
From:   internet-dra...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title : IGP extension for PCEP security capability support in the PCE
discovery
Authors : Diego R. Lopez
Qin Wu
Dhruv Dhody
Michael Wang
Daniel King
Filename : draft-ietf-lsr-pce-discovery-security-support-03.txt
Pages : 9
Date : 2019-10-31

Abstract:
When a Path Computation Element (PCE) is a Label Switching Router
(LSR) participating in the Interior Gateway Protocol (IGP), or even a
server participating in IGP, its presence and path computation
capabilities can be advertised using IGP flooding. The IGP
extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
to advertise path computation capabilities using IGP flooding for
OSPF and IS-IS respectively. However these specifications lack a
method to advertise PCEP security (e.g., Transport Layer
Security(TLS), TCP Authentication Option (TCP-AO)) support
capability.

This document proposes new capability flag bits for PCE-CAP-FLAGS
sub-TLV that can be announced as attribute in the IGP advertisement
to distribute PCEP security support information. In addition, this
document updates RFC 5088 and RFC 5089 to allow advertisement of Key
ID or Key Chain Name Sub-TLV to support TCP AO security capability.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-pce-discovery-security-support-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-security-support-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-03


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/

___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


_

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

Re: [Pce] Shepherd Review of draft-ietf-pce-pcep-flowspec

[julien.meuric]

Hi Adrian,

The resolutions below are fine by me. Let's see how the discussion
progresses on that filter/route switch and we'll be able to move forward.

Thanks,

Julien


On 05/01/2020 19:51, Adrian Farrel wrote:
> Hi Julien,
>
> Long ago you sent your review. Comments in line.
>
> At the same time, we see that IDR has basically completed work on 
> draft-ietf-idr-rfc5575bis and we think we should update this document to use 
> that as a reference instead of RFC 5575 and RFC 7674.
>
> Finally, someone contacted us privately to ask that we add a flag to a PCEP 
> flowspec to indicate that it should not be installed as a data plane filter, 
> but should be installed as a 'normal route' with longest prefix matching. 
> That is a simple change, but nevertheless a change of technical substance. 
> I'll send a separate email to the list to see whether anyone else is 
> interested and determine whether we can craft some text.
>
> I'll do a new revision and then start the thread for the additional point 
> noted above.
>
> Best wishes for the New Year,
> Adrian
>
> ===
>
>> I still have one pending question, related to section 8.7. (Priorities
>> and Overlapping Flow Specifications). I understand this section as
>> "priorities within PCEP-installed flow specs follow the same ordering
>> rules as BGP-installed flow specs, i.e. [RFC5575]". Let us now look at a
>> device supporting both protocols to install flow specs:
>> - Is there an implicit scope associated to each set of flow specs making
>>   them mutually exclusive?
>> - If both sets can overlap, can we assume that priority rules do not
>>   care about the protocol used to install the flow specs?
>> Adding a couple of sentences may be enough to clarify that.
> You raise a very good point. I am not certain how often this is going to 
> arise, but it seems almost certain that were we to decide it could never 
> arise, it would immediately become a requirement from the field. So we should 
> address it.
>
> Now, draft-ietf-idr-rfc5575bis-18.txt talks only about BGP, but section 5.1 
> gives a description of how flow specifications are ordered for traffic 
> matching regardless of what order they arrive in BGP. I think we should 
> assume that all traffic is open to all flowspecs whether installed by BGP for 
> firewalls or routing, or installed by PCEP for classification onto traffic 
> paths (LSPs or SR paths). I believe that similar work is being looked at for 
> classification of traffic onto service function chains, and I imagine that 
> those flowspecs might also coincide with BGP and PCEP flowspecs.
>
> I think that all we need do is:
> - call out that both protocols might be simultaneously present and 
> distributing flowspecs for installation
> - make the observation that the rules defined in section 5.1 of 
> draft-ietf-idr-rfc5575bis apply regardless of which protocol distributed the 
> flowspec.
>
> That brings me to the text in 8.7:
> OLD
>Flow specifications can overlap.  For example, two different flow
>specifications may be identical except for the length of the prefix
>in the destination address.  In these cases the PCC must determine
>how to prioritize the flow specifications so as to know to which path
>to assign packets that match both flow specifications.  That is, the
>PCC must assign a precedence to the flow specifications so that it
>checks each incoming packet for a match in a predictable order.
>
>The processing of BGP Flow Specifications is described in [RFC5575].
>Section 5.1 of that document explains the order of traffic filtering
>rules to be executed by an implementation of that specification.
>
>PCCs MUST apply the same ordering rules as defined in [RFC5575].
> NEW
>Flow specifications can overlap.  For example, two different flow
>specifications may be identical except for the length of the prefix
>in the destination address.  In these cases the PCC must determine
>how to prioritize the flow specifications so as to know to which path
>to assign packets that match both flow specifications.  That is, the
>PCC must assign a precedence to the flow specifications so that it
>checks each incoming packet for a match in a predictable order.
>
>The processing of BGP Flow Specifications is described in 
>[I-D.ietf-idr-rfc5575bis].  Section 5.1 of that document explains the
>order of traffic filtering rules to be executed by an implementation
>of that specification.
>
>PCCs MUST apply the same ordering rules as defined in 
>[I-D.ietf-idr-rfc5575bis].
>
>Furthermore, it is possible that Flow Specifications will be distributed
>by BGP as well as by PCEP as described in this document.  In such 
>cases implementations supporting both approaches MUST apply the
>prioritization and ordering rules as set out in [I-D.ietf-idr-rfc5575bis]
>regardless of which protocol distributed the Flow Specifications,
>however implementations MAY 

[Pce] WG LC for draft-ietf-pce-stateful-pce-lsp-scheduling

[julien.meuric]

Dear PCE WG,

This message starts a 2-week PCE WG Last Call for
draft-ietf-pce-stateful-pce-lsp-scheduling-10. Please review the
document and share your comments and/or interest using the PCE mailing
list by Thursday December 19.

Thanks,

Dhruv & Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Fwd: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pce-pcep-flowspec

[julien.meuric]

Hi all,

The chairs have not received any objection on progressing this I-D. We
thus consider there is no reason to delay its publication when it is ready.

Thanks,

Dhruv & Julien


On 05/11/2019 14:58, julien.meu...@orange.com wrote:
> Dear PCE WG,
>
> Since this IPR disclosure was shared after the end the WG LC, the chairs
> want to be make there is an opportunity to comment. If you have any
> concern about this I-D regarding that IPR, please share it on the
> mailing list. If no objection is raised by November 12, we'll resume the
> publication process, as usual.
>
> Thanks,
>
> Julien
>
>
>  Forwarded Message 
> Date: Fri, 1 Nov 2019 09:18:12 -0700
> From: IETF Secretariat 
>
>
> Dear Dhruv Dhody, Adrian Farrel, Zhenbin Li:
>
>
> An IPR disclosure that pertains to your Internet-Draft entitled "PCEP
> Extension for Flow Specification" (draft-ietf-pce-pcep-flowspec) was
> submitted to the IETF Secretariat on 2019-11-01 and has been posted on the
> "IETF Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/3840/). The title of the IPR disclosure is
> "Huawei Technologies Co.,Ltd's Statement about IPR related to
> draft-ietf-pce-pcep-flowspec"
>
>
> Thank you
>
> IETF Secretariat
>
>
> _
>
> 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
>




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Shepherd Review of draft-ietf-pce-pcep-flowspec

[julien.meuric]

Dear authors,

Thank for addressing the comments received during WG LC and RtgDir
reviews. Technically, the I-D looks almost ready.

I still have one pending question, related to section 8.7. (Priorities
and Overlapping Flow Specifications). I understand this section as
"priorities within PCEP-installed flow specs follow the same ordering
rules as BGP-installed flow specs, i.e. [RFC5575]". Let us now look at a
device supporting both protocols to install flow specs:
- Is there an implicit scope associated to each set of flow specs making
them mutually exclusive?
- If both sets can overlap, can we assume that priority rules do not
care about the protocol used to install the flow specs?
Adding a couple of sentences may be enough to clarify that.

Please find below a few additional nits.
--
1. Introduction
---
- The abstract uses "traffic engineered networks", the intro "traffic
engineering networks". I do not have any strong preference, but
consistency would be welcome. (By the way, no hyphen in
"traffic-engineered"?)
- s/to Generalized MPLS (GMPLS) networks/to Generalized MPLS
(GMPLS)-controlled networks/
- s/about the the LSPs/about the LSPs/

- OLD:
   The data flows
   intended for a tunnel can be described using Flow Specification
   Components, and when PCEP is in use for tunnel initiation it makes
   sense for that same protocol to be used to distribute the Flow
   Specification Components that describe what data is to flow on those
   tunnels.
  NEW:
   The data flows
   intended for a tunnel can be described using Flow Specification
   Components; when PCEP is in use for tunnel initiation, it makes
   sense for that same protocol to be used to distribute the Flow
   Specification Components that describe what data is to flow on those
   tunnels.
--
3.2. Elements of Procedure
---
- s/in each case including whether/in each case. This includes whether/
--
6. Flow Filter TLV
---
OLD:
   Only one Flow Filter TLV can be
   present and represents the complete definition of a Flow
   Specification for traffic to be placed on the tunnel indicated by the
   PCEP message in which the PCEP Flow Spec Object is carried.
NEW:
   Only one Flow Filter TLV can be
   present and represents the complete definition of a Flow
   Specification for traffic to be placed on a tunnel; this tunnel is
   indicated by the PCEP message in which the PCEP Flow Spec Object
   is carried.
--
7. Flow Specification TLVs
---
[Page 14]
"Two bit flags (S and G) are defined.  They have the common meanings for
wildcarding in multicast."
-> At least a reference would be appreciated to teach about what
"common" refers to.

[Page 15]
  "if a Multicast Flow
   Specification TLV is received with S bit = 0 and G bit = 1 the
   receiver SHOULD respond"
-> Is there a reason why it is not a MUST?
--
13. Manageability Considerations
---
- s/view the the Flow Specifications/view the Flow Specifications/
- s/implementations MUST support indicating/implementations MUST
indicate/  [Guessing it was wrongly fixed in -06.]
--


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] Fwd: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pce-pcep-flowspec

[julien.meuric]

Dear PCE WG,

Since this IPR disclosure was shared after the end the WG LC, the chairs
want to be make there is an opportunity to comment. If you have any
concern about this I-D regarding that IPR, please share it on the
mailing list. If no objection is raised by November 12, we'll resume the
publication process, as usual.

Thanks,

Julien


 Forwarded Message 
Date:   Fri, 1 Nov 2019 09:18:12 -0700
From:   IETF Secretariat 


Dear Dhruv Dhody, Adrian Farrel, Zhenbin Li:


An IPR disclosure that pertains to your Internet-Draft entitled "PCEP
Extension for Flow Specification" (draft-ietf-pce-pcep-flowspec) was
submitted to the IETF Secretariat on 2019-11-01 and has been posted on the
"IETF Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/3840/). The title of the IPR disclosure is
"Huawei Technologies Co.,Ltd's Statement about IPR related to
draft-ietf-pce-pcep-flowspec"


Thank you

IETF Secretariat


_

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] WG Last Call of draft-ietf-pce-pcep-flowspec

[julien.meuric]

Hi all,

In our WGLC queue, draft-ietf-pce-pcep-flowspec has been stable for a
while. This message starts a 2-week WG last call on this I-D. Please
review the document and share your feedback using the PCE mailing list
by Monday October, 28.

You will note that the I-D includes an implementation section. If you
have an implementation, you may also contact the chairs privately.

Thanks,

Dhruv & 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

Re: [Pce] Adoption of draft-li-pce-sr-path-segment?

[julien.meuric]

Hi all,

It looks like there is support on this I-D and all authors have
responded to the IPR check. We can adopt it as a WG document.

Authors, please submit the I-D as "draft-ietf-pce-sr-path-segment-00".

Thanks,

Dhruv & Julien


On 25/09/2019 18:20, julien.meu...@orange.com wrote:
> Hi PCE WG,
>
> In our adoption poll queue, draft-li-pce-sr-path-segment has been there
> for a little while, after it was discussed face to face. We would now
> like you to voice your opinion on the list: do you think this I-D can be
> the foundation for a PCE WG's work item?
>
> Please send your feedback to the PCE mailing list, including any comment
> you would like to share, especially if you think the WG should not adopt
> it. This poll will end on October 9.
>
> Thanks,
>
> Dhruv & 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] Adoption of draft-li-pce-sr-path-segment?

[julien.meuric]

Hi PCE WG,

In our adoption poll queue, draft-li-pce-sr-path-segment has been there
for a little while, after it was discussed face to face. We would now
like you to voice your opinion on the list: do you think this I-D can be
the foundation for a PCE WG's work item?

Please send your feedback to the PCE mailing list, including any comment
you would like to share, especially if you think the WG should not adopt
it. This poll will end on October 9.

Thanks,

Dhruv & 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

Re: [Pce] Shepherd Review of draft-farrel-pce-stateful-flags-01

[julien.meuric]

Hi,

IMHO, including the new reference in the registry could be valuable and
makes no harm. And now that the text is written, why leaving it out?

Thanks Hari and Adrian,

Julien


On 22/09/2019 22:16, Adrian Farrel wrote:
> Hi,
>
> I’m willing to be guided here.
>
> I don’t think the new draft makes any changes to how a code point seen in in 
> the wild should be interpreted.
> And the “updates” relationship will be in place.
>
> But if people think it is valuable we could have…
>
> IANA maintains a registry called the “Path Computation Element Protocol 
> (PCEP) Numbers” registry with a subregistry called " SRP Object Flag Field". 
> IANA is requested to update the Reference in that subregistry to include a 
> reference to this document in addition to [RFC8281].
>
> Best,
> Adrian
>
>> This document is well written and clear. Thanks for the update. Please find 
>> below
>> my comments on draft-farrel-pce-stateful-flags-01.
>>
>> OLD:
>> 8. IANA Considerations
>> This document makes no requests for IANA action
>>
>> NEW:
>> The current IANA for this object has reference to "RFC8281" 
>> (https://www.iana.org/
>> assignments/pcep/pcep.xhtml#srp-object-flag-field) Dont we want that refer 
>> to this
>> new draft since we have updated the text ?
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[Pce] Clarifications and Updates to RFC 8231

[julien.meuric]

Dear PCE WG,

As part of the WG business, we have recently identified some
expectations surrounding RFC 8231. The chairs have been thinking on the
way to progress associated improvements.
Thus, it seems to us that properly splitting the resulting work will be
more efficient, avoiding to delay too much the easy pieces. We suggest
to work on both an Informational clarification and Standard Track
updates. The former may start from some of material in
draft-koldychev-pce-operational. The latter has already started with
draft-farrel-pce-stateful-flags. This I-D being a very focused and
uncontroversial fix, we will move it directly to WGLC and we expect any
other standards track updates to be collected together in a new I-D.

Thanks,

Dhruv & 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

Re: [Pce] Shepherd Review of draft-ietf-pce-association-diversity-07

[julien.meuric]

Hi Mahendra,

This revision looks good. Thanks.

Julien


On 05/07/2019 06:40, Mahendra Singh Negi wrote:
> Hi Julien,
>
> Many thanks for the detailed review comments, we have fixed all the comments 
> and new version is posted, please find the new-version and version-diff links 
> below:
>
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-08
>
> To answer your question:
> Complementary question: why an optional behavior (SHOULD) instead of 
> mandatory (MUST)? ->   Yes MUST is appropriate and updated in the new version.
>
>
> Thanks,
> Mahendra
>
> -Original Message-
> From: julien.meu...@orange.com [mailto:julien.meu...@orange.com] 
> Sent: 28 June 2019 20:53
>
> Hi authors,
>
> Please find below my detailed comments on 
> draft-ietf-pce-association-diversity. I originally started to review -06. 
> Thanks for posting -07 after Dhruv's comments, as it addressed some on mine 
> as well.
>
> The main technical concern lies in section 4.6, in case no solution is found 
> by the PCE. Section 4.3, about SVEC, relies on PCRep with NO-PATH, which is 
> consistent with existing PCEP specification. IMHO, section 4.6 is confusing 
> and incomplete. What about the following?
>
> OLD
>    [...] the PCE SHOULD
>    reply with a PCUpd message containing an empty ERO.  In addition to
>    the empty ERO Object, the PCE MAY add the NO-PATH-VECTOR TLV [...]
>
> NEW
>     [...] the PCE MUST
>    reply to a request (PCEReq) with a PCRep message containing a NO-PATH
>    object. In case of network event leading to an impossible strict
>    disjointness, the PCE SHOULD send a PCUpd message containing an empty
>    ERO to the corresponding PCCs. In addition to the NO-PATH or the
>    empty ERO object, the PCE MAY add the NO-PATH-VECTOR TLV [...]
>
> Complementary question: why an optional behavior (SHOULD) instead of 
> mandatory (MUST)?
>
>
> Nits:
> --
> Global and usual nit: the flag name. The I-D has a collection of X 
> flag/X-flag/X-Flag/flag X/etc that needs consistency. Many PCEP documents use 
> "X flag".
> --
> Title
> ---
> - s/communication Protocol (PCEP) extension for signaling LSP diversity 
> constraint/Communication Protocol (PCEP) Extension for LSP Diversity 
> Constraint Signaling/
> --
> Abstract
> ---
> - s/Communication Protocol/communication Protocol/
> - s/knows that LSPs in the same group/knows that the LSPs in the same group/
> - s/needs to/need to/
> --
> 2. Terminology
> ---
> - s/Communication Protocol/communication Protocol/
> --
> 3.  Motivation
> ---
> - s/above, consider that/above, let us consider that/
> - s/difficult. Whereas, computation/difficult, whereas computation/
> - s/These messages uses/These messages use/
> - s/the disjoint path computation/a disjoint path computation/
> - s/disjoint group-ids/disjoint group IDs/
> - s/should allow to overcome/allows to overcome/
> - s/association source could/the association source could/
> --
> 4. Protocol extension
> ---
> - s/Protocol extension/Protocol Extension/
> - s/Association group/Association Group/
> - s/TLVs - Global Association Source or Extended Association ID are 
> included/TLVs - Global Association Source or Extended Association ID - are 
> included/
> - s/to uniquely identifying/to uniquely identify/
> - s/Association object -/Association object:/
> - s/[I-D.ietf-pce-association-group]
> specify/[I-D.ietf-pce-association-group] specifies/
> - s/in the PCEP messages/in PCEP messages/
> - s/Refer [I-D.ietf-pce-association-group]/Refer to 
> [I-D.ietf-pce-association-group]/
> - s/more LSPs. But a PCE/more LSPs, but a PCE/
> - s/in how many LSPs/in the number of LSPs/
> - s/vendor specific behavioral information/vendor-specific behavioral 
> information/
> - OLD
>  When unset, PCE is allowed to relax disjointness
>  by using either applying a requested objective function or any
>  other behavior if no objective function is requested (e.g.:
>  using a lower disjoint type (link instead of node) or relaxing
>  disjointness constraint fully)
>   NEW
>  When unset, the PCE is allowed to relax disjointness
>  by either applying a requested objective function (cf. section
>  4.4 below) or using any other behavior if no objective function
>  is requested (e.g. using a lower disjoint type (link instead of
>  node) or fully relaxing disjointness constraint).
>
> - s/The flags  L, N, and S/The L, N and S flags/
> - s/The flag P/The P flag/
> - s/the flag T/the T flag/
> - s/both SVEC and ASSOCIATION object/both SVEC and ASSOCIATION objects/
> - s/in SVEC object/in the SVEC object/
> - s/with NO-PATH object/with a NO-PATH object/
> - s/Disjointness objective functions/Disjointness Objective Functions/
> - s/The PCEP OF-List TLV allow/Whereas the PCEP OF-List TLV allows/
> - s/Incompatible OF 

Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT)

[julien.meuric]

Hi Ben,

Would this address your previous comment? (Please see the text in brackets.)

   The semantic of the LOAD-BALANCING object is not changed.  When the
   bandwidth can be summarized into scalars (e.g., for circuit-switched
   technologies, Traffic Parameters express detailed container
   requirements implicitly mapping to a well-defined bandwidth), if a
   PCC requests the computation of a set of TE-LSPs so that the total of
   their generalized bandwidth is X, the maximum number of TE-LSPs is N,
   and each TE-LSP must at least have a bandwidth of B, it inserts a
   BANDWIDTH object specifying X as the required bandwidth and a
   LOAD-BALANCING object with the Max-LSP and Min Bandwidth Spec fields
   set to N and B, respectively.

Thanks,

Julien


On 02/07/2019 18:51, Benjamin Kaduk wrote:
> On Mon, Jul 01, 2019 at 11:45:04AM +0200, julien.meu...@orange.com wrote:
>> Hi Ben,
>>
>> Thank you for following up. Please see [JM] below.
>>
>>
>> On 29/06/2019 02:51, Benjamin Kaduk wrote:
>>> Hi Julien,
>>>
>>> On Fri, Jun 28, 2019 at 03:26:33PM +0200, julien.meu...@orange.com wrote:
 Hi Ben,

 Apologies for the late response.
>>> I probably wouldn't have been able to reply much before now anyway -- I've
>>> been quite busy (and have some other documents' authors waiting for
>>> feedback as well).
>>>
 Let us focus on your first DISCUSS comment which is the main one. You
 raised a legitimate point that we acknowledge. After discussion, we
 propose to modify the end of section 2.4 as follows:

 OLD

The semantic of the LOAD-BALANCING object is not changed.  If a PCC
requests the computation of a set of TE-LSPs so that the total of
their generalized bandwidth is X, the maximum number of TE-LSPs is N,
and each TE-LSP must at least have a bandwidth of B, it inserts a
BANDWIDTH object specifying X as the required bandwidth and a LOAD-
BALANCING object with the Max-LSP and Min Bandwidth Spec fields set
to N and B, respectively.

 NEW

    The semantic of the LOAD-BALANCING object is not changed.  When the
    bandwidth can be expressed as scalars (e.g., for circuit-switched
    technologies), if a PCC requests the computation of a set of TE-LSPs
    so that the total of their generalized bandwidth is X, the maximum
    number of TE-LSPs is N, and each TE-LSP must at least have a
    bandwidth of B, it inserts a BANDWIDTH object specifying X as the
    required bandwidth and a LOAD-BALANCING object with the Max-LSP and
    Min Bandwidth Spec fields set to N and B, respectively.

    For technologies based on statistical multiplexing (e.g., InterServ,
    Ethernet), the exact bandwidth management (e.g., Ethernet's Excessive
    Rate) is left to the PCE's policies, according to the operator's
    configuration. If required, further documents may introduce a new
    mechanism to finely express complex load balancing policies within
    PCEP.


 Would that update address that part of your DISCUSS? (The remaining
 parts will be straightforward once this one is resolved.)
>>> I seem to have forgotten some of the details of what fields are in the
>>> various objects, but let's see what I can say regardless of that.
>>> I think the general approach of specifying behavior when there's an obvious
>>> scalar bandwidth and leaving the choice to the PCE in other cases is a good
>>> approach.
>>>
>>> For the specifics, we probably don't want to say "when the bandwidth can be
>>> expressed as a scalar" and "for technologies based on statistical
>>> multiplexing" just in case there ends up being some third category, so the
>>> second paragraph could start off as something like "In all other cases,
>>> including for technologies based on statistical multiplexing [...]".
>> [JM] You're right. That's a safer wording, easy to include.
>>
>>> It also seems like for the first case, we would be able to use the
>>> un-modified RFC 5440 BANDWIDTH and not need the generalized form?  But
>>> perhaps I misremember/misunderstand...
>> [JM] This is indeed what the current wording suggests, so I propose to
>> change "expressed by scalars" with "summarized into scalars". The idea
>> here is to accommodate existing constructs from RSVP-TE signaling, which
>> are compound objects allowing to specify more detailed information than
>> aggregated values. E.g., a single 10 Gb/s circuit vs. a group of 4 x 2.5
>> Gb/s containers.
>> That would lead us to the following text:
>>
>>    The semantic of the LOAD-BALANCING object is not changed.  When the
>>    bandwidth can be summarized into scalars (e.g., for circuit-switched
>>    technologies), if a PCC requests the computation of a set of TE-LSPs
>>    so that the total of their generalized bandwidth is X, the maximum
>>    number of TE-LSPs is N, and each TE-LSP must at least have a
>>    bandwidth of B, it inserts a 

Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT)

[julien.meuric]

Hi Ben,

Thank you for following up. Please see [JM] below.


On 29/06/2019 02:51, Benjamin Kaduk wrote:
> Hi Julien,
>
> On Fri, Jun 28, 2019 at 03:26:33PM +0200, julien.meu...@orange.com wrote:
>> Hi Ben,
>>
>> Apologies for the late response.
> I probably wouldn't have been able to reply much before now anyway -- I've
> been quite busy (and have some other documents' authors waiting for
> feedback as well).
>
>> Let us focus on your first DISCUSS comment which is the main one. You
>> raised a legitimate point that we acknowledge. After discussion, we
>> propose to modify the end of section 2.4 as follows:
>>
>> OLD
>>
>>The semantic of the LOAD-BALANCING object is not changed.  If a PCC
>>requests the computation of a set of TE-LSPs so that the total of
>>their generalized bandwidth is X, the maximum number of TE-LSPs is N,
>>and each TE-LSP must at least have a bandwidth of B, it inserts a
>>BANDWIDTH object specifying X as the required bandwidth and a LOAD-
>>BALANCING object with the Max-LSP and Min Bandwidth Spec fields set
>>to N and B, respectively.
>>
>> NEW
>>
>>    The semantic of the LOAD-BALANCING object is not changed.  When the
>>    bandwidth can be expressed as scalars (e.g., for circuit-switched
>>    technologies), if a PCC requests the computation of a set of TE-LSPs
>>    so that the total of their generalized bandwidth is X, the maximum
>>    number of TE-LSPs is N, and each TE-LSP must at least have a
>>    bandwidth of B, it inserts a BANDWIDTH object specifying X as the
>>    required bandwidth and a LOAD-BALANCING object with the Max-LSP and
>>    Min Bandwidth Spec fields set to N and B, respectively.
>>
>>    For technologies based on statistical multiplexing (e.g., InterServ,
>>    Ethernet), the exact bandwidth management (e.g., Ethernet's Excessive
>>    Rate) is left to the PCE's policies, according to the operator's
>>    configuration. If required, further documents may introduce a new
>>    mechanism to finely express complex load balancing policies within
>>    PCEP.
>>
>>
>> Would that update address that part of your DISCUSS? (The remaining
>> parts will be straightforward once this one is resolved.)
> I seem to have forgotten some of the details of what fields are in the
> various objects, but let's see what I can say regardless of that.
> I think the general approach of specifying behavior when there's an obvious
> scalar bandwidth and leaving the choice to the PCE in other cases is a good
> approach.
>
> For the specifics, we probably don't want to say "when the bandwidth can be
> expressed as a scalar" and "for technologies based on statistical
> multiplexing" just in case there ends up being some third category, so the
> second paragraph could start off as something like "In all other cases,
> including for technologies based on statistical multiplexing [...]".
[JM] You're right. That's a safer wording, easy to include.

> It also seems like for the first case, we would be able to use the
> un-modified RFC 5440 BANDWIDTH and not need the generalized form?  But
> perhaps I misremember/misunderstand...
[JM] This is indeed what the current wording suggests, so I propose to
change "expressed by scalars" with "summarized into scalars". The idea
here is to accommodate existing constructs from RSVP-TE signaling, which
are compound objects allowing to specify more detailed information than
aggregated values. E.g., a single 10 Gb/s circuit vs. a group of 4 x 2.5
Gb/s containers.
That would lead us to the following text:

   The semantic of the LOAD-BALANCING object is not changed.  When the
   bandwidth can be summarized into scalars (e.g., for circuit-switched
   technologies), if a PCC requests the computation of a set of TE-LSPs
   so that the total of their generalized bandwidth is X, the maximum
   number of TE-LSPs is N, and each TE-LSP must at least have a
   bandwidth of B, it inserts a BANDWIDTH object specifying X as the
   required bandwidth and a LOAD-BALANCING object with the Max-LSP and
   Min Bandwidth Spec fields set to N and B, respectively.

   In all other cases, including for technologies based on statistical
   multiplexing (e.g., InterServ, Ethernet), the exact bandwidth
   management (e.g., Ethernet's Excessive Rate) is left to the PCE's
   policies, according to the operator's configuration. If required,
   further documents may introduce a new mechanism to finely express
   complex load balancing policies within PCEP.

Is it better?

Thank you,

Julien

> Thanks,
>
> Ben
>
>>
>> On 11/04/2019 20:48, Benjamin Kaduk wrote:
>>> On Thu, Apr 11, 2019 at 01:23:37PM +0100, Adrian Farrel wrote:
 As a general response, Ben, I would say that PCEP is only catching up with 
 GMPLS in this document. Thus, everything it is doing wrt bandwidth has 
 been built for some while in GMPLS RSVP-TE implementations.

 It is probable that more careful references to the GMPLS signalling RFCs 
 would address some of your 

[Pce] Shepherd Review of draft-ietf-pce-association-diversity-07

[julien.meuric]

Hi authors,

Please find below my detailed comments on
draft-ietf-pce-association-diversity. I originally started to review
-06. Thanks for posting -07 after Dhruv's comments, as it addressed some
on mine as well.

The main technical concern lies in section 4.6, in case no solution is
found by the PCE. Section 4.3, about SVEC, relies on PCRep with NO-PATH,
which is consistent with existing PCEP specification. IMHO, section 4.6
is confusing and incomplete. What about the following?

OLD
   [...] the PCE SHOULD
   reply with a PCUpd message containing an empty ERO.  In addition to
   the empty ERO Object, the PCE MAY add the NO-PATH-VECTOR TLV [...]

NEW
    [...] the PCE MUST
   reply to a request (PCEReq) with a PCRep message containing a NO-PATH
   object. In case of network event leading to an impossible strict
   disjointness, the PCE SHOULD send a PCUpd message containing an empty
   ERO to the corresponding PCCs. In addition to the NO-PATH or the
   empty ERO object, the PCE MAY add the NO-PATH-VECTOR TLV [...]

Complementary question: why an optional behavior (SHOULD) instead of
mandatory (MUST)?


Nits:
--
Global and usual nit: the flag name. The I-D has a collection of X
flag/X-flag/X-Flag/flag X/etc that needs consistency. Many PCEP
documents use "X flag".
--
Title
---
- s/communication Protocol (PCEP) extension for signaling LSP diversity
constraint/Communication Protocol (PCEP) Extension for LSP Diversity
Constraint Signaling/
--
Abstract
---
- s/Communication Protocol/communication Protocol/
- s/knows that LSPs in the same group/knows that the LSPs in the same group/
- s/needs to/need to/
--
2. Terminology
---
- s/Communication Protocol/communication Protocol/
--
3.  Motivation
---
- s/above, consider that/above, let us consider that/
- s/difficult. Whereas, computation/difficult, whereas computation/
- s/These messages uses/These messages use/
- s/the disjoint path computation/a disjoint path computation/
- s/disjoint group-ids/disjoint group IDs/
- s/should allow to overcome/allows to overcome/
- s/association source could/the association source could/
--
4. Protocol extension
---
- s/Protocol extension/Protocol Extension/
- s/Association group/Association Group/
- s/TLVs - Global Association Source or Extended Association ID are
included/TLVs - Global Association Source or Extended Association ID -
are included/
- s/to uniquely identifying/to uniquely identify/
- s/Association object -/Association object:/
- s/[I-D.ietf-pce-association-group]
specify/[I-D.ietf-pce-association-group] specifies/
- s/in the PCEP messages/in PCEP messages/
- s/Refer [I-D.ietf-pce-association-group]/Refer to
[I-D.ietf-pce-association-group]/
- s/more LSPs. But a PCE/more LSPs, but a PCE/
- s/in how many LSPs/in the number of LSPs/
- s/vendor specific behavioral information/vendor-specific behavioral
information/
- OLD
 When unset, PCE is allowed to relax disjointness
 by using either applying a requested objective function or any
 other behavior if no objective function is requested (e.g.:
 using a lower disjoint type (link instead of node) or relaxing
 disjointness constraint fully)
  NEW
 When unset, the PCE is allowed to relax disjointness
 by either applying a requested objective function (cf. section
 4.4 below) or using any other behavior if no objective function
 is requested (e.g. using a lower disjoint type (link instead of
 node) or fully relaxing disjointness constraint).

- s/The flags  L, N, and S/The L, N and S flags/
- s/The flag P/The P flag/
- s/the flag T/the T flag/
- s/both SVEC and ASSOCIATION object/both SVEC and ASSOCIATION objects/
- s/in SVEC object/in the SVEC object/
- s/with NO-PATH object/with a NO-PATH object/
- s/Disjointness objective functions/Disjointness Objective Functions/
- s/The PCEP OF-List TLV allow/Whereas the PCEP OF-List TLV allows/
- s/Incompatible OF codes/Incompatible OF code/
- s/listed below -/listed below:/
- The last example at the end of section 4.4 shows that the
specification doesn't prohibit redundant constraints. I would be nice to
add a sentence explicitly stating that in the previous paragraph.
- s/P-flag considerations/P Flag Considerations/
- s/fulfill the customer requirement/fulfill customer's requirements/
- s/Consider, this customer/Let us consider that this customer/
- s/( and/(and/
- s/allows a simple expression that/allows to simply express that/
- s/If PE->PE2/If PE1->PE2/
- Many P-flag/P-Flag to be fixed in section 4.5.
- s/Disjointness computation issues/Disjointness Computation Issues/
- s/T-bit/T flag/  [x2]
--
5. Security Considerations
---
- s/which do not/which does not/
- s/defines following new PCEP TLVs/defines the following new PCEP TLVs/
- s/PCEP-ERROR codes/PCEP-ERROR Codes/
- s/defines new Error-Type and Error-Value/defines new Error-Value
within existing Error-Type/
- s/Incompatible OF codes/Incompatible OF code/
--
8. 

Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT)

[julien.meuric]

Hi Ben,

Apologies for the late response.

Let us focus on your first DISCUSS comment which is the main one. You
raised a legitimate point that we acknowledge. After discussion, we
propose to modify the end of section 2.4 as follows:

OLD

   The semantic of the LOAD-BALANCING object is not changed.  If a PCC
   requests the computation of a set of TE-LSPs so that the total of
   their generalized bandwidth is X, the maximum number of TE-LSPs is N,
   and each TE-LSP must at least have a bandwidth of B, it inserts a
   BANDWIDTH object specifying X as the required bandwidth and a LOAD-
   BALANCING object with the Max-LSP and Min Bandwidth Spec fields set
   to N and B, respectively.

NEW

   The semantic of the LOAD-BALANCING object is not changed.  When the
   bandwidth can be expressed as scalars (e.g., for circuit-switched
   technologies), if a PCC requests the computation of a set of TE-LSPs
   so that the total of their generalized bandwidth is X, the maximum
   number of TE-LSPs is N, and each TE-LSP must at least have a
   bandwidth of B, it inserts a BANDWIDTH object specifying X as the
   required bandwidth and a LOAD-BALANCING object with the Max-LSP and
   Min Bandwidth Spec fields set to N and B, respectively.

   For technologies based on statistical multiplexing (e.g., InterServ,
   Ethernet), the exact bandwidth management (e.g., Ethernet's Excessive
   Rate) is left to the PCE's policies, according to the operator's
   configuration. If required, further documents may introduce a new
   mechanism to finely express complex load balancing policies within
   PCEP.


Would that update address that part of your DISCUSS? (The remaining
parts will be straightforward once this one is resolved.)

Thank you,

Julien


On 11/04/2019 20:48, Benjamin Kaduk wrote:
> On Thu, Apr 11, 2019 at 01:23:37PM +0100, Adrian Farrel wrote:
>> As a general response, Ben, I would say that PCEP is only catching up with 
>> GMPLS in this document. Thus, everything it is doing wrt bandwidth has been 
>> built for some while in GMPLS RSVP-TE implementations.
>>
>> It is probable that more careful references to the GMPLS signalling RFCs 
>> would address some of your points. Specifically RFC 3473 and RFC 7025. But I 
>> think section 2.3 already does this, so I'm not quite sure where to make 
>> this clarification.
> (I only see it referencing 7025 but not 3473.)
>
> And it looks like only the LOAD-BALANCING object, that tries to enforce
> that the component TE-LSPs each contribute some minmium bandwidth, is
> going to require much thinking.  Any other text changes on this point ought
> to be fairly mechanical.
>
>> FWIW, I have never heard of anyone applying Intserv approaches to GMPLS. 
>> Reservations are not statistical, and in most cases the resources are 
>> physical quantities and assigned directly.
> My main complaint here is that we're going from a scalar bandwidth number,
> that can use regular arithmetic comparisons (trichotomy) and have a clear
> sense of whether a minimum threshold value is achieved, to a more
> complicated structure (a mathematician might think of it as a vector
> space), where we no longer have a single clear metric or trichotomy
> comparison between different vectors in the space.  If we said that, even
> though the generalized bandwidth structure is this larger "vector" thing,
> the load-balancing object was going to still just use a single scalar for
> minimum bandwidth (and we defined how to compute the scalar bandwidth from
> a given generalized bandwidth structure/vector), this issue would
> evaporate.  The problem arises when we take the same generalized bandwidth
> structure and try to use it (the structure/vector) as the minimum threshold
> value.  Do I compare the components piece by piece and require each
> individual component to surpass the stated minimum?  That is well-defined
> in a procedural sense but may not make practical sense for all the
> generalized bandwidth structures defined now or in the future.
>
> -Ben
>
>> Cheers,
>> Adrian
>>
>> --
>>
>> This document makes some well-needed extensions to existing PCEP
>> concepts such as bandwidth, but I'm not convinced that the way they
>> interact with existing PCEP functionality is sufficiently well specified
>> to admit interoperable implementation.  Specifically, we introduce the
>> generalized bandwidth structures and reuse that encoding for the
>> generalized load balancing structures, which includes a notion of
>> "minimum bandwidth specification".  But now that the bandwidth
>> specification is a compound data structure instead of a scalar type,
>> it's not guaranteed that we have a strict linear ordering with
>> well-defined minimum.  If we consider the specific case of Intserv, do I
>> insist upon all three of the minimum bucket rate, minimum bucket size,
>> and minimum peak data rate?  Or perhaps I only care about the peak data
>> rate and not the bucket size/rate.  We need more text in order to
>> 

[Pce] Shepherd Review of draft-ietf-pce-stateful-path-protection-05

[julien.meuric]

Hi authors of draft-ietf-pce-stateful-path-protection,

Thank you for the update following Dhruv's comments.

To summarize, I mainly have 2 issues to point out:
- The I-D depends on RFC 4872 and reuses the P, S and PT flags (which is
great); however, the side effect of redefining (why?) the expansion of
the S bit (Standby vs. Secondary) leads to a common behavior with an
opposite flag value between the specifications! As suggested by the
reference in section 3.2., we expect alignment here.
- In sections 4.5 and 6.3, the Error-Type for associations has shifted
from 26 (early allocated by IANA) to 29 (from nowhere); this mistake
makes me wonder about the implementation status of the I-D.

Then, looking at the details.
--
Header
---
- As pointed out by Dhruv, we still miss a valid justification for the 7
names listed on the front page, all the more as you exceed the
recommended threshold by 2.
--
Abstract
---
- s/A stateful Path Computation Element/An active stateful Path
Computation Element/
- s/for a stateful PCE/for an active stateful PCE/
--
1. Introduction
---
- s/the PCE Initiated mode/the PCE-Initiated mode/
--
3. PCEP Extensions
---
- s/[I-D.ietf-pce-association-group]
specify/[I-D.ietf-pce-association-group] specifies/
- s/The length field is 16 bit-long and has/The length field (16 bits) has/
- s/Following flags are currently defined -/The following flags are
currently defined:/
- s/Following values are/The following values are/
- s/i.e. P bit is unset/i.e. as if P bit is unset/
--
4. Operation
---
- s/[RFC8231], the the association group/[RFC8231]. The association group/
- s/to a LSP/to an LSP/
- s/includes PPAG./includes PPAGs./
- s/PCC Initiated/PCC-Initiated/
- s/remove on or more/remove one or more/
- s/PCC would report/PCC reports/
- s/via Path Computation Report(PCRpt) message/via the Path Computation
Report (PCRpt) message/
- s/LSPs to a stateful PCE/LSPs to an active PCE/
- s/where PCE would/where the PCE would/
- s/via Path Computation Update(PCUpd) message/via the Path Computation
Update (PCUpd) message/
- s/to PCC via PCUpd message/to the PCC via the PCUpd message/
- s/refer [I-D.litkowski-pce-state-sync]/refer to
[I-D.litkowski-pce-state-sync]/
- s/PCE Initiated LSPs/PCE-Initiated LSPs/
- s/both the PCE and PCC/both the PCE and the PCC/
- s/uses PCUpd or Path Computation Initiate(PCInitiate) message/uses the
PCUpd or the Path Computation Initiate (PCInitiate) messages/
- s/at PCC/at the PCC/
- s/Same procedure/The same procedure/
- s/with Error-Type= 29/with Error-Type 26/
- s/and Error-Value = TBD3/and Error-Value TBD3/
- s/1:N (with N=1),/1:N with N=1,/
- s/and protection LSP/and one protection LSP
- s/a PCEP Speaker/a PCEP speaker/
- s/with Error-Type=29/with Error-Type 26/
- s/and Error-Value = TBD4/and Error-Value TBD4/
- s/continue to apply/continues to apply/
--
5. Other considerations
---
- s/Other considerations/Other Considerations/
- s/LSPs.The/LSPs. The/
- s/for the the protection LSP/for the protection LSP/
- s/both ASSOCIATION object/both ASSOCIATION objects/
- s/and disjoint association/and the disjoint association/
--
6. IANA considerations
---
- s/IANA considerations/IANA Considerations/
- s/Action [RFC8126]. Each bit should be tracked with the following
qualities:/Action [RFC8126]./  [The sentence appears twice.]
- s/new Error-Type and Error-Value/new Error-Value/
- The table in section 6.3 is confusing. A way to clarify would be to
say: "allocate new error values for Error-Type 26 within [...]" and
change the 1st column into "Error-Value".
--


Cheers,

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

Re: [Pce] WG LC for draft-ietf-pce-association-diversity and draft-ietf-pce-stateful-path-protection

[julien.meuric]

Hi all,

We have not heard from anyone on this WG LC before it ended. Though we
prefer detailed comments, it would be great to see at least if you
believe these I-Ds are ready to be sent to the IESG. If you (intend to)
implement any of them, that would be nice to let the chairs know as well.

Thanks,

ADJ

On 23/04/2019 10:52, julien.meu...@orange.com wrote:
> Hi all,
>
> Only one week left to review: no reason to wait for the last minute, do
> not be shy to share your comments and/or implementation status.
>
> Thanks,
>
> Adrian, Dhruv & Julien
>
>
> On 09/04/2019 16:05, julien.meu...@orange.com wrote:
>> Hi all,
>>
>> This message initiates a bulk WG Last Call for both
>> draft-ietf-pce-association-diversity-06 and
>> draft-ietf-pce-stateful-path-protection-04. Please review these
>> documents and share your feedback using the PCE mailing list.
>>
>> If you have an implementation of any of them, you may let the chairs
>> know privately.
>>
>> This double LC will last for 3 weeks and will end on Tuesday April 30.
>>
>> Thanks,
>>
>> Adrian, Dhruv & 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

Re: [Pce] WG LC for draft-ietf-pce-association-diversity and draft-ietf-pce-stateful-path-protection

[julien.meuric]

Hi all,

Only one week left to review: no reason to wait for the last minute, do
not be shy to share your comments and/or implementation status.

Thanks,

Adrian, Dhruv & Julien


On 09/04/2019 16:05, julien.meu...@orange.com wrote:
> Hi all,
>
> This message initiates a bulk WG Last Call for both
> draft-ietf-pce-association-diversity-06 and
> draft-ietf-pce-stateful-path-protection-04. Please review these
> documents and share your feedback using the PCE mailing list.
>
> If you have an implementation of any of them, you may let the chairs
> know privately.
>
> This double LC will last for 3 weeks and will end on Tuesday April 30.
>
> Thanks,
>
> Adrian, Dhruv & 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] WG LC for draft-ietf-pce-association-diversity and draft-ietf-pce-stateful-path-protection

[julien.meuric]

Hi all,

This message initiates a bulk WG Last Call for both
draft-ietf-pce-association-diversity-06 and
draft-ietf-pce-stateful-path-protection-04. Please review these
documents and share your feedback using the PCE mailing list.

If you have an implementation of any of them, you may let the chairs
know privately.

This double LC will last for 3 weeks and will end on Tuesday April 30.

Thanks,

Adrian, Dhruv & 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] New PCE Secretary

[julien.meuric]

Dear PCE WG,

With Dhruv becoming a co-chair of the WG, we had an empty secretary position. 
The call for volunteers was successful and we appreciate the interest expressed 
for the WG. Among these, the chairs have decided to appoint Hariharan 
Ananthakrishnan from Netflix as a secretary of the PCE WG. Those of you who 
were on Etherpad during the Prague session may have noticed he was already 
taking care of the minutes.

Please welcome Hari to this position!

Cheers,

Adrian, Dhruv & 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

Re: [Pce] Shepherd Review of draft-ietf-pce-association-group-06

[julien.meuric]

This sentence is clear enough to address my concern.

Thank you!

Julien


On 07/03/2019 15:00, Dhruv Dhody wrote:
> Hi Julien, 
>
> My bad! 
> I did some digging and we added this based on Adrian's comment [1]
> back in Feb last year (and my memory failed me). 
>
> How about - 
>
>    The Assoc-type MAY appear more than once in the OP-CONF-ASSOC-RANGE
>    TLV in the case of a non-contiguous Operator-configured Association
>    Range.  The PCEP speaker originating this TLV MUST NOT carry
>    overlapping ranges for an association type.  If a PCEP peer receives
>    overlapping ranges for an association type, it MUST consider the Open
>    message malformed and MUST reject the PCEP session with error type 1
>    and error value 1 (PCEP session establishment failure / Reception of
>    an invalid Open message).
>
> Thanks! 
> Dhruv 
>
> [1] https://mailarchive.ietf.org/arch/msg/pce/QSobS2pul-lIlMLXV4KcBhwgBM0
>
> On Thu, Mar 7, 2019 at 6:45 PM  > wrote:
>
> Hi Dhruv,
>
> Congratulation from the prompt update. I'm fine with the 
> notation
> for ranges.
>
> The only open issue is the text you add below:
> - Is there a reason to prohibit, for a given Association type, split
> operator-configured ranges? I don't think this is what the original
> version suggested.
> - Assuming we proceed with this new rule, then why so much text about
> overlapping ranges? To have this happen, the TLV would already break
> that "present only once" rule: why would an implementation care about
> checking if ranges overlap if the TLV is already wrong?
>
> Thanks,
>
> Julien
>
>
> On 07/03/2019 09:28, Dhruv Dhody wrote:
> >> --
> >> 5.1. Procedure
> >> ---
> >> - The current text only indirectly tackles the case where a
> given Assoc-
> >> type is advertised multiple times, when forbidding overlapping
> ranges. A
> >> complementary sentence explicitly mentioning non-overlapping
> ranges would
> >> be welcome.
> > [[Dhruv Dhody]] Added -
> >
> >    An Assoc-Type MUST be present only once in the
> OP-CONF-ASSOC-RANGE
> >    TLV, if the same Assoc-Type is present more than once, the PCEP
> >    session MUST be rejected with error type 1 and error value 1
> (PCEP
> >    session establishment failure / Reception of an invalid Open
> >    message).
> >
>
> 
> _
>
> 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.
>


_

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

Re: [Pce] Shepherd Review of draft-ietf-pce-association-group-06

[julien.meuric]

Hi Dhruv,

Congratulation from the prompt update. I'm fine with the  notation
for ranges.

The only open issue is the text you add below:
- Is there a reason to prohibit, for a given Association type, split
operator-configured ranges? I don't think this is what the original
version suggested.
- Assuming we proceed with this new rule, then why so much text about
overlapping ranges? To have this happen, the TLV would already break
that "present only once" rule: why would an implementation care about
checking if ranges overlap if the TLV is already wrong?

Thanks,

Julien


On 07/03/2019 09:28, Dhruv Dhody wrote:
>> --
>> 5.1. Procedure
>> ---
>> - The current text only indirectly tackles the case where a given Assoc-
>> type is advertised multiple times, when forbidding overlapping ranges. A
>> complementary sentence explicitly mentioning non-overlapping ranges would
>> be welcome.
> [[Dhruv Dhody]] Added - 
>
>An Assoc-Type MUST be present only once in the OP-CONF-ASSOC-RANGE
>TLV, if the same Assoc-Type is present more than once, the PCEP
>session MUST be rejected with error type 1 and error value 1 (PCEP
>session establishment failure / Reception of an invalid Open
>message).
>

_

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] Shepherd Review of draft-ietf-pce-association-group-06

[julien.meuric]

Hi authors,

Please find below the comments to be resolved to move
draft-ietf-pce-association-group forward. Most of them are editorial, so
this looks promising.

Thanks,

Julien


--
Abstract
---
- "LSP[s]" should be expanded at first use, all the more as it has 5
listed expansions in RFC Editor's dictionary (some of them being
incorrect IMHO).
--
1. Introduction
---
- s/GMPLS- controlled/GMPLS-controlled/
--
2. Terminology
---
- When importing definitions, PCEP messages are sometimes referred to as
"Full Phrase" (e.g. "LSP State Report", "LSP Update Request"), sometimes
as "PCAbbrev" (e.g. PCReq, PCRep, PCInitiate). Consistency among imports
would be welcome, combining both ways may be the easiest (e.g. "LSP
Update Request/PCUpd").
--
3.1. Motivation
---
- OLD
   Stateful PCE provides the ability to update existing LSPs and to
   instantiate new ones. To enable support for PCE-controlled make-
   before-break and for protection...
  NEW
   Stateful PCE provides the ability to update existing LSPs and to
   instantiate new ones. There are various situations where several
   LSPs need to share common information. E.g., to support for
   PCE-controlled make-before-break and for protection...

- s/working and protections LSPs/working and protection LSPs/
- s/tunnel. Whereas some/tunnel, whereas some/
- s/some association could/some associations could/
- s/policy based association/policy-based association/
--
3.2. Relationship with the SVEC List
---
- s/are quite different./are quite different, though some use case may
overlap./
- s/association type, should/association type should/
--
3.3.  Operation Overview
---
- s/Whereas, some/Whereas some/
- s/The association are/The associations are/
- s/LSP state clean up/LSP state clean-up/
--
3.4. Operator-configured Association Range
---
- OLD
   it is necessary to configure a range of association identifiers that
   are marked for operator-configured associations to avoid any
   association identifier clash within the scope of the association
   source.
  NEW
   it is necessary to distinguish a range of association identifiers that
   are marked for operator-configured associations to avoid any
   association identifier clash within the scope of the association
   source. This document assumes that these 2 ranges are configured.
--
4.1.1. Procedure
---
- OLD
   The PCEP
   speaker could still use the ASSOCIATION object, if the peer does not
   support the association, it would react as per the procedure
   described in Section 6.4.
  NEW
   In this case, the PCEP
   speaker could still use the ASSOCIATION object: if the peer does not
   support the association, it will react as per the procedure described
   in Section 6.4.

- s/a association type/an association type/
- s/that specify/that specifies/
- The last sentence of the paragraph puzzled me a bit. The current
wording may suggests that "it is RECOMMENDED to support the
aforementioned OPTIONAL TLV", which is inconsistent 2119 language. My
guess is that it should say: "In case the use of the ASSOC-Type-List TLV
is triggered by a mandatory association type, then it is RECOMMENDED
that the PCEP implementation include..." Is my understanding correct?
--
5.1. Procedure
---
- s/In which case/In this case/
- s/would be applied./applies./
- s/the Assoc-Type/the Assoc-type/
- s/carry overlapping range/carry overlapping ranges/
- s/an association-type/an association type/
- s/receives overlapping range/receives overlapping ranges/
- s/for the association type/for an association type/
- The current text only indirectly tackles the case where a given
Assoc-type is advertised multiple times, when forbidding overlapping
ranges. A complementary sentence explicitly mentioning non-overlapping
ranges would be welcome.
- OLD
   In case, there is an operator-configured association that was
   configured with association parameters (such as association
   identifier, association type and association source) at the local
   PCEP speaker, later the PCEP session gets established with the
   association source and a new operator-configured range is learned
   during session establishment. At this time...
  NEW
   There may be cases where an operator-configured association was
   configured with association parameters (such as association
   identifier, association type and association source) at the local
   PCEP speaker, and later the PCEP session gets established with the
   association source and a new operator-configured range is learned
   during session establishment. At this time...

- s/that were not/that are not/
- s/new operator configured range/new operator-configured range/
- s/removing any LSPs/disassociating any LSPs/
- s/an operator configured association/an operator-configured association/
--
6.1.  Object Definition
---
- s/The value 0x and 0x0/The values 0x and 0x0/
--
6.1.3.  Association Source
---
- s/node that originate/node that originates/
- OLD
   set the 

Re: [Pce] Adoption Poll for draft-lazzeri-pce-residual-bw

[julien.meuric]

Hi all,

It is time to close this poll. Despite Adrian's reminder (Feb 1), no one
has voiced about the I-D. Even though nobody objected to the adoption,
the expressed support is very limited. As a result, we believe that the
WG is not ready to work on this item now and the draft is not adopted.

Thanks to the authors who put some effort the propose that work.

Regards,

AD


On 13/12/2018 14:05, Julien Meuric wrote:
> Dear WG,
>
> We discussed about draft-lazzeri-pce-residual-bw a couple of times
> during past IETF meetings. At that time, those in the room who had read
> it looked quite interested, but they were just a few. We now request a
> feedback from the list: do you support the adoption of
> draft-lazzeri-pce-residual-bw as a starting point for a PCE work item?
> (https://tools.ietf.org/html/draft-lazzeri-pce-residual-bw-01)
>
> Please respond to the list, including your reasons if you do not support.
>
> Thanks
>
> Julien
>
>
> P.S.: We are aware that the latest version of the I-D has expired, but
> an adoption would solve that and a lack of interest may help the authors
> focus their effort on something else than a simple timer reset.
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-wson-rwa-ext-11: (with DISCUSS and COMMENT)

[julien.meuric]

  
  
Hi Benjamin, hi Young,

Sorry for jumping onto the discussion, but it seems to me that there
are 2 slightly different issues tackled below:

1- scoping the wavelength restriction:
    * Young's response below remains true from a generic signaling
stand point,
    * I would had that the WDM data plane we are controlling in this
context implies a label continuity between hops by default, unless
the node has an additional hardware capability (i.e.
termination/regeneration) it can control; as a result, a restriction
scoped to the PCC from the generic protocol's perspective implicitly
means "restriction till the other end of the wavelength (several
hops downstream)" in our technology-specific context [side note:
facing these multi-hops constraints is part of the use cases for the
PCE architecture];

2- the "Identifier" field, inherited from RFC 6205: my reading of
the definition brings us in the prescriptive/ERO use case, where 0
leaves freedom and non-zero relies on a "MUST"; the latter puzzles
me for 2 reasons:
    * from a PCE implementer's perspective, we end up with a
mandatory field whose actual use is fuzzy (maybe Daniele could help
us with his CCAMP chair hat),
    * an implementation needing to report an error related to a
blocking issue with that field has no clear specification to follow
(a well define error behavior may be required).
An easy way to address both concerns may be to temper the language
from RFC 6205 when the field is used in a PCEP context.

Thanks,

Julien


On 07/02/2019 02:27, Leeyoung wrote:


  Section 4.3.2
   
  RFC 6205 says that the "Identifier" is a
per-node assigned and scoped value that may change on a per-hop
basis.  I don't see where our base label gets scoped to a node
(just that it's part of a PCReq message which does not seem
scoped to a node), so this seems problematic.
   
  YL>> RFC 6205 is written from the
  perspective of GMPLS signaling which is on a per-hop basis.
  Here we are using the same encoding, but from the PCEP
  perspective. In the PCEP, PCC is the head-end node and the
  head-end node would apply the wavelength restriction to its
  out-going interfaces. If the restriction applies to globally,
  then GMPLS signaling will carry this information to
  sub-sequent nodes. If the restriction locally applies, then
  PCE-CC mechanism (PCE talks to each node) would allow the
  restriction to be applied to each node.  This draft was
  written the restriction would be applied globally (as a
  mechanism for limiting the tunable range of wavelength
  globally so that the head-end node can propagate this
  restriction to other node (via GMPLS signaling mechanism).  


  _

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

Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-wson-rwa-ext-11: (with DISCUSS and COMMENT)

[julien.meuric]

  
  
Hi Young,

FWIW, the IANA already manages several similar registries with the
same 3 entries (e.g.,
https://www.iana.org/assignments/lmp-parameters/lmp-parameters.xhtml#lmp-parameters-15).
Creating one will help addressing this concern raised by Alexey and
Benjamin.

Thanks,

Julien


On 07/02/2019 02:27, Leeyoung wrote:


  What is the mechanism for extensibility of
future Link Identifier sub-TLV types?  Should there be a
registry?
   
  YL>>  I am not sure if we need
  reserve for future interface type. Typical PCEP/GMPLS RFCs do
  not go beyond this three types and the unnumbered type is
  flexible enough to accommodate other types than IPv4 and IPv6.



  _

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

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

[julien.meuric]

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


_

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] IPR Check on draft-ietf-pce-stateful-pce-auto-bandwidth

[julien.meuric]

Dear authors of draft-ietf-pce-stateful-pce-auto-bandwidth,

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-auto-bandwidth beyond the one with the ID
2996. If so, please indicate 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 other IPR that applies, please reply saying
"Appart from disclosure #2996, I am not aware of any other IPR that
applies to this draft".

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

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

Re: [Pce] Fw: New Version Notification for draft-zhang-pce-resource-sharing-08.txt

[julien.meuric]

Hi again,

Thank you Adrian for sharing your support on this I-D. We agree that no
one expressed disagreement on that work. It therefore leaves this I-D in
a draw situation: it missed an opportunity to get adopted, but there is
no reason to exclude another poll to distinguish between bad poll timing
and lack of support.
I suggest the authors to keep on working on the document, including the
list as much as possible and we will eventually consider a 2nd adoption
poll.

Cheers,

Julien


On 27/11/2018 21:35, Adrian Farrel wrote:
> Hi Haomian,
>
> Thanks for continuing to move this work forward.
>
> As I said back in October, I think the topic is in scope for the working 
> group. I have read this recent version of the draft and think it is ready for 
> adoption.
>
> Although the previous adoption poll did not have a lot of support, no one 
> spoke against, and there does appear to be a group of people willing to work 
> on it - I see 6 names on the document and a further 3 who supported adoption.
>
> If the chairs think that the draft can progress in the WG, that would be 
> fine. If not, could they give a hint of what the authors should do?
>
> Thanks,
> Adrian
>
> -Original Message-
> From: Pce  On Behalf Of Zhenghaomian (Zhenghaomian, 
> Optical  Technology Research Dept)
> Sent: 19 November 2018 09:48
>
> Dear WG, 
>
> According to IETF 103 discussion, we update this work with a few changes in 
> the text to better specify the motivation. We believe this work is 
> technically ready for WG adoption, again. 
>
> Please take a look and your comments are highly welcome, thank you. 
>
> Best wishes,
> Haomian (on behalf of all authors)
>
> -邮件原件-
> 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
> 发送时间: 2018年11月19日 15:55
> 收件人: Victor Lopez ; Zhangxian (Xian) ; 
> Oscar de Dios ; Oscar Gonzalez de Dios ; 
> Zhenghaomian (Zhenghaomian, Optical  Technology Research Dept) 
> 
> 主题: New Version Notification for draft-zhang-pce-resource-sharing-08.txt
>
>
> A new version of I-D, draft-zhang-pce-resource-sharing-08.txt
> has been successfully submitted by Haomian Zheng and posted to the IETF 
> repository.
>
> Name: draft-zhang-pce-resource-sharing
> Revision: 08
> Title:Extensions to Path Computation Element Protocol (PCEP) 
> to Support Resource Sharing-based Path Computation
> Document date:2018-11-19
> Group:Individual Submission
> Pages:14
> URL:
> https://www.ietf.org/internet-drafts/draft-zhang-pce-resource-sharing-08.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-zhang-pce-resource-sharing/
> Htmlized:   
> https://tools.ietf.org/html/draft-zhang-pce-resource-sharing-08
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-zhang-pce-resource-sharing
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-zhang-pce-resource-sharing-08
>
> Abstract:
>Resource sharing in a network means two or more Label Switched Paths
>(LSPs) use common piece(s) of resource along their paths. This can
>help save network resource and is useful in scenarios such as LSP
>recovery or when two LSPs do not need to be active at the same time.
>A Path Computation Element (PCE) is responsible for path computation
>with such requirement. The resource-sharing-based path computation
>with better efficiency can be achieved together with the association
>object in PCEP.
>
>This document extends the Path Computation Element Protocol (PCEP)
>in order to support resource sharing-based path computation, which
>is a special case in the association path computation.
>
>   
> 
>
>
> 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


_

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 

Re: [Pce] RtgDir Early Review: draft-ietf-pce-gmpls-pcep-extensions

[julien.meuric]

Hi all,

Dave, thank you for this careful review. Though I'd by fine to liaise to
ITU-T SG15 for information, I'm not that sure that our process requires
liaising "for review": PCEP isn't a controversial technology which would
need special treatment with respect to ITU-T. How strong do you feel on
that?

Cyril and authors, please make sure to address Dave's comments.

Cheers,

Julien


On 18/11/2018 14:48, David Sinicrope wrote:
>
> Hello
>
> I have been selected to do a routing directorate “early” review of
> this draft. 
> https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions
>
> The routing directorate will, on request from the working group chair,
> perform an “early” review of a draft before it is submitted for
> publication to the IESG. The early review can be performed at any time
> during the draft’s lifetime as a working group document. The purpose
> of the early review depends on the stage that the document has reached.
>
> As this document is in working group last call, my focus for the
> review was to determine whether the document is ready to be published.
> Please consider my comments along with the other working group last
> call comments.
>
> For more information about the Routing Directorate, please
> see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Document: draft-ietf-pce-gmpls-pcep-extensions-12.txt 
> Reviewer: David Sinicrope
> Review Date: November 17, 2018
> Intended Status: Standards Track
>
> *Summary:* 
>
>   * This document is basically ready for publication, but has nits and
> clarifications that should be considered prior to being submitted
> to the IESG.
>
> *Comments:*
>
> Although a bit terse on motivation the document is of good quality and
> detail providing the level of information needed for protocol
> specification and implementation.
>
> The comments provided below are aimed at improving readability,
> comprehension and consumption of the document by those that would use
> it for architecture, solution design and implementation.
>
>  
>
> Abstract.  Please provide some detail scope and purpose beyond one
> line.  This is supposed to answer why / whether I should delve into
> the document.
>
>  
>
> General Comments (no particular section)
>
> 1. Given that this document is providing the detail for the
> requirements in 7025, it might be advantageous to the reader to
> structure the document according to the requirements listed in 7025.
>
>  
>
> 2. The document gives a sparse highlight of what extensions are needed
> and why Section 1 and then launches into the details in section2 and
> on.  More elaboration on motivation and gaps and requirements would be
> helpful to better understand why the extensions are needed.
>
>  
>
> 3. This should be liaised to ITUT SG15 Q12 and Q14 for review.  Maybe
> Q11/15 too.
>
>  
>
> Sec 1.2 - RFC 7025 has 13 different requirements listed.  
>
>  
>
> 1. Why are they repeated here and not simply referenced? One must have
> both documents to fully understand the requirements this document is
> addressing, so there is no need to restate (and possibly misstate) the
> agreed requirements here for readability 
>
>  
>
> 2. Why is this only a subset of the requirements in RFC 7025?  Is
> there less covered here than in RFC7025?  If so this must be spelled
> out in terms of coverage.  Perhaps a table to explain the functions
> noted in 7025 vs what this document covers.
>
>  
>
>  
>
> Introduction - this document assumes a significant familiarity with
> rfc7025 and the other documents listed.  It should state this outright.
>
>  
>
>  
>
> Sec 1.3 - please correlate these to the requirements they are
> addressing.  Also please provide more explanation.  Some of these are
> seemingly contradictory the way they are listed currently. E.g.
> END-POINTS and ERO make it sound confused as to whether the 7025
> requirement on unnumbered interfaces is addressed  or not.
>
> Some examples would go a long way to providing clarity
>
> Note: I noted this is done later in the specific extensions, but could
> also be done here.
>
>  
>
> Sec 1.3 - PCEP objects, needs plural
>
>  
>
> Sec 1.3 - they can’t be shortcomings if they were not designed for the
> use noted.  Perhaps “gaps in functional coverage” or “areas for
> enhancement” is a better description.
>
>  
>
> Sec 1.3 - why is the infusion/exclusion of labels a shortcoming? 
> Please elaborate.
>
>  
>
> Sec 1.3 – Protection should be listed with the others “shortcomings”
> right now looks like a summary which it isn’t.  Indent this text.
>
>  
>
> Sec 1.3 covered pcep extensions - covered by what? This document?  If
> so, please say so. Also say/elaborate on why they are needed.  Note: I
> can see this is done much more in the individual sections describing
> the extension.  It would suffice then to add a note here that more
> detail on motivation is provided with each individual extension.
>
>  
>
> Sec 2.2 - excellent cross reference to RFC 7025. I see 

Re: [Pce] [Lsr] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[julien.meuric]

Hi all,

PCE chair hat on, I need to rectify the statement below: at this stage,
PCE, as a WG, has not reach any consensus on this I-D, which has only
been discussed within the LSR WG. There may be individuals involved in
both WGs, but that is not a PCE WG consensus.

However, I suggest that the PCE WG's members (BCC'd) share their view on
this poll using the LSR mailig list.

Thanks,

Julien


On 13/11/2018 23:10, Acee Lindem (acee) wrote:
>
> At the LSR WG meeting in Bangkok, there was general agreement that we
> should adopt this draft given that the PCE WG believes it is useful.
> Please indicate your support or objection prior to 12:00 AM UT,
> Wednesday November 26^th , 2018. Note the authors may refresh the
> draft to address some comments prior to that time.
>
>  
>
>  
>
> Thanks,
>
> Acee
>
>
> ___
> Lsr mailing list
> l...@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr


_

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] Fwd: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[julien.meuric]

Dear PCE'rs,

Please note the poll in progress in the LSR WG. You may share your
feedback on the LSR list.

Regards,

Julien


 Message transféré 
Date:   Tue, 13 Nov 2018 22:10:47 +
From:   Acee Lindem (acee) 


At the LSR WG meeting in Bangkok, there was general agreement that we
should adopt this draft given that the PCE WG believes it is useful.
Please indicate your support or objection prior to 12:00 AM UT,
Wednesday November 26^th , 2018. Note the authors may refresh the draft
to address some comments prior to that time.

 

 

Thanks,

Acee


_

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

Re: [Pce] 答复: Building the PCE Agenda for IETF 103

[julien.meuric]

Hi,

The correct link is the displayed one, wherever it redirects you to:
https://datatracker.ietf.org/meeting/103/materials/agenda-103-pce/

Julien


P.S.: The original message was sent in both raw text and HTML, both
showing up the correct string. The HTML version however includes:
  https://datatracker..ietf.org/meeting/103/materials/agenda-103-pce/;>
    https://datatracker.ietf.org/meeting/103/materials/agenda-103-pce/
  
So if your mail client prefers to detect URLs from the text, you get the
right link; if it follows the exact HTML syntax, it gets the hidden
double dot. I'd be tempted to blame the sender, but who really cares? ;-)


Le 25/10/2018 à 11:59, Fatai Zhang a écrit :
>
> OK, thanks.
>
>  
>
> It seems that it is mischievous only on my machine, ☺
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
> Thanks
>
>  
>
> Fatai
>
>  
>
> *发件人:*Belotti, Sergio (Nokia - IT/Vimercate)
> [mailto:sergio.belo...@nokia.com]
> *发送时间:*2018年10月25日17:45
>
>  
>
> Hi Dhruv, Fatai,
>
>  
>
> Link is working properly also on my machine.
>
>  
>
> My 2 cents
>
> Thanks
>
> sergio
>
>  
>
> *From:*Pce mailto:pce-boun...@ietf.org>> *On
> Behalf Of *Dhruv Dhody
> *Sent:* Thursday, October 25, 2018 11:39 AM
>
>  
>
> Hi Fatai, 
>
>  
>
> The link works on my machine(s) (i tried on all of them). I dont see
> the ".." in the email [1].
>
> Maybe your local issue?
>
>  
>
> Thanks! 
>
> Dhruv 
>
> [1] https://www.ietf.org/mail-archive/web/pce/current/msg06061.html
>
>  
>
> On Thu, Oct 25, 2018 at 3:04 PM Fatai Zhang  > wrote:
>
> Hi Dhruv,
>
>  
>
> When I clicked the link you provided, it went
> tohttps://datatracker..ietf.org/meeting/103/materials/agenda-103-pce/
> ,
> and it showed something wrong.
>
>  
>
> I think the correct link should be:
> https://datatracker.ietf.org/meeting/103/materials/agenda-103-pce/
>
>  
>
>  
>
>  
>
>  
>
> Thanks
>
>  
>
> Fatai
>
>  
>
> *发件人**:*Pce [mailto:pce-boun...@ietf.org
> ] *代表***Dhruv Dhody
> *发送时间**:*2018年10月25日16:14
>
>  
>
> Hi WG, 
>
>  
>
> The draft agenda is published
> - https://datatracker.ietf.org/meeting/103/materials/agenda-103-pce/
> 
>
>  
>
> Please send the meeting slides to both your chairs and the
> secretery by *_Friday 2nd November. _*Since we are scheduled for
> Monday it is important to upload the meeting material in advance. 
>
>  
>
> Thanks! 
>
> Dhruv, (Jon & Julien)
>
>  
>
> On Wed, Oct 10, 2018 at 10:09 AM Dhruv Dhody  > wrote:
>
> Hi WG,
>
>  
>
> The PCE WG session in Bangkok is tentatively scheduled for
> Monday afternoon 
>
> [1]. If you need some face-to-face time to progress some work,
> please send 
>
> a slot request to the secretary and the chairs by Monday
> October 22nd 
>
> including:
>
> - the draft(s) you want to discuss,
>
> - the expected presenter name,
>
> - the requested duration, including question time as part of
> the slot,
>
> - the reason why you need face-to-face time as opposed to
> using the mailing
>
> list (open 24/7).
>
>  
>
> Thank you,
>
> Dhruv, Jon & Julien
>
>  
>
> [1] https://datatracker.ietf.org/meeting/103/agenda.html
>


_

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