[Pce] Re: WGLC for draft-ietf-pce-stateful-pce-vendor-03

[Dongjie (Jimmy)]

Hi Chairs,

I’ve read the latest version of this document and support its publication. It 
is useful to extend the usage of vendor information object/TLV to stateful PCE.

Best regards,
Jie

From: Dhruv Dhody [mailto:d...@dhruvdhody.com]
Sent: Thursday, July 4, 2024 9:17 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-stateful-pce-vendor-03.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.html

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 Thursday 18 July 2024.

A general reminder to the WG to be more vocal during the last-call/adoption.

Thanks,
Dhruv & Julien
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: WG Adoption of draft-li-pce-controlled-id-space-16

[Dongjie (Jimmy)]

Dear Chairs and authors,

I’ve reviewed this document and support its adoption. I have one comment which 
is for authors’ consideration (after adoption).

Section 6 currently considers that the ID space allocated to PCE could be 
withdrawn by resetting the PCE session. If possible some less interruptive 
mechanism for ID space withdrawal or update may be considered.

Best regards,
Jie

From: Dhruv Dhody 
Sent: Friday, May 17, 2024 7:10 PM
To: pce@ietf.org
Cc: pce-chairs ; draft-li-pce-controlled-id-sp...@ietf.org
Subject: [Pce] WG Adoption of draft-li-pce-controlled-id-space-16

Hi WG,

This email begins the WG adoption poll for draft-li-pce-controlled-id-space-16

https://datatracker.ietf.org/doc/draft-li-pce-controlled-id-space/

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 3rd June 2024.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

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

[Dongjie (Jimmy)]

Hi Julien,

I support the publication of this document. 

It provides one necessary piece of the whole SRv6 picture, and the document has 
been quite mature after several rounds of update. Thanks to the authors!

Best regards,
Jie

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of
> julien.meu...@orange.com
> Sent: Tuesday, February 14, 2023 1:39 AM
> To: pce@ietf.org
> Subject: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15
> 
> 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

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

[Dongjie (Jimmy)]

Hi WG,

I’ve read this document and support its adoption. YANG module is an important 
component for the deployment of PCEP SRv6.

Best regards,
Jie

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Li Cong
Sent: Wednesday, September 14, 2022 11:56 PM
To: pce@ietf.org
Subject: Re: [Pce] WG Adoption of draft-li-pce-pcep-srv6-yang-07

Hi WG,

This draft provides a PCEP-SRv6 YANG module,  which is very useful for the SRv6 
deployment.

I support the adoption of this draft.

Best regards,
Cong Li

发件人: Dhruv Dhody mailto:d...@dhruvdhody.com>>
日期: 2022年9月2日 星期五 下午5:09
收件人: "pce@ietf.org" mailto:pce@ietf.org>>
抄送: 
"draft-li-pce-pcep-srv6-y...@ietf.org"
 
mailto:draft-li-pce-pcep-srv6-y...@ietf.org>>
主题: WG Adoption of draft-li-pce-pcep-srv6-yang-07
重发发件人: mailto:alias-boun...@ietf.org>>

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.

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

Re: [Pce] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

[Dongjie (Jimmy)]

Hi Sasha and Christian,

To my understanding the potential services of CS-SR require some level of 
performance guarantee, which means the traffic needs to be distinguished from 
other traffic in the network and be treated separately. As discussed in this 
thread, one approach would be to steer the traffic to a separate queue or a 
separate set of resources.

I agree with Sasha that requesting a dedicated traffic class may not be easy. 
Sasha gave a mechanism based on the coexistence of MPLS-TP and SR-MPLS. An 
alternative to that would be to use a separate set of SR SIDs for the CS-SR, 
and associate such set of SR SIDs with a separate set of network resources 
(e.g. sub-interfaces or queue). That could be achieved by using resource-aware 
SIDs as defined in draft-ietf-spring-resource-aware-segments.

Best regards,
Jie

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, July 26, 2022 3:48 PM
To: Christian Schmutzer (cschmutz) 
Cc: draft-schmutzer-spring-cs-sr-policy@ietf.org; spr...@ietf.org; Rotem 
Cohen ; Nitsan Dolev ; 
pce@ietf.org; Michael Gorokhovsky 
Subject: Re: [Pce] A technical concern regarding 
draft-schmutzer-spring-cs-sr-policy-00

Christian,
Lots of thanks for your prompt response to my concerns about the SR-CS Policy 
draft.
Unfortunately I will not be able to attend the SPRING session later today (even 
remotely).

Regarding your explanation, I believe that the key point is the sentence 
“everything not running over CS-SR has no bandwidth guarantee, is of lower 
priority and can undergo packet drops during DiffServ PHB processing”.

This statement is an assumption that:

  1.  Is critical for SR-CS to deliver its promise
  2.  Is actually a requirement (and quite a strong one) for the operator of 
the SR network to enforce strict separation of traffic that uses SR-CS and all 
the rest of traffic to different traffic classes. Implementing this requirement 
in a live operational network may be quite a non-trivial operation
  3.  Unless I am mistaken, is not explicitly stated in the current version of 
the draft (or in any of the associated drafts),

At the same time, I agree that, if this assumption holds, SR-CS can deliver its 
promise.

Please notice also that in the  case of MPLS networks the same results can be 
achieved with MPLS-TP running as “ships in the night” with SR-MPLS but without 
the overhead of deep label stacks required by SR-CS. This approach has been 
developed and deployed for quite some time now. IMHO it would be interesting to 
compare these two approaches.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com

From: Christian Schmutzer (cschmutz) 
mailto:cschm...@cisco.com>>
Sent: Monday, July 25, 2022 6:45 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: Christian Schmutzer (cschmutz) 
mailto:cschm...@cisco.com>>; 
draft-schmutzer-spring-cs-sr-policy@ietf.org;
 spr...@ietf.org; Rotem Cohen 
mailto:rotem.co...@rbbn.com>>; Nitsan Dolev 
mailto:nitsan.do...@rbbn.com>>; 
pce@ietf.org; Michael Gorokhovsky 
mailto:michael.gorokhov...@rbbn.com>>
Subject: [EXTERNAL] Re: A technical concern regarding 
draft-schmutzer-spring-cs-sr-policy-00

Hi Sasha,

Many thanks for reviewing draft-schmutzer-pce-cs-sr-policy 
(draft-schmutzer-spring-cs-sr-policy) and sharing your input / concerns. Let me 
try to address them.

CS-SR policies don’t require additional unprotected adj-SIDs. The unprotected 
adj-SID part of the two adj-SIDs you mentioned typically being present per link 
in a network does suffice.

Further the draft does not assume bandwidth guarantees for those unprotected 
adj-SIDs. Bandwidth is managed by the PCE at a link level and bandwidth 
guarantees are achieved by ensuring that the total amount of bandwidth 
requested by all candidate-paths going via a link is kept below the reservable 
maximum bandwidth defined.

To ensure a link is never congested by just CS-SR traffic, end-to-end 
path-protection and restoration is used. This ensures traffic does only flow 
along a path (working, protect or restore) for which bandwidth admission 
control has been done during path establishment.

You are correct, mechanisms such as TI-LFA may lead to congestion, but the 
assumption is that everything not running over CS-SR, has no bandwidth 
guarantee, is of lower priority and can undergo packet drops during DiffServ 
PHB processing.

There are many ways to fulfil those PHB processing requirements. One way is to 
mark CS-SR policy traffic with a unique EXP/DSCP and map it into a dedicated 
priority queue. CS-SR traffic may share a EXP/DSCP and/or queue with other 
traffic if the operate is certain that the queue will never be congested (i.e. 
the non CS-SR traffic is important but has very low volume and the queue’s 
bandwidth is 

Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06

[Dongjie (Jimmy)]

Hi Chairs,

I support the adoption of this document.

Best regards,
Jie

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Friday, June 24, 2022 4:59 PM
To: pce@ietf.org
Cc: draft-chen-pce-pcep-i...@ietf.org
Subject: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06

Hi WG,

This email begins the WG adoption poll for draft-chen-pce-pcep-ifit-06.

https://datatracker.ietf.org/doc/draft-chen-pce-pcep-ifit/

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 11th July 2022.

Please be more vocal during WG polls!

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

Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

[Dongjie (Jimmy)]

Hi Chairs,

I’ve read this document and support its adoption.

And here are my replies to the questions:

Should this draft be adopted by the PCE WG?

Yes

Please state your reasons - Why / Why not?

PMTU is an important characteristic of the path, which needs to be considered 
in both path computation and path instantiation.

What needs to be fixed before or after adoption?

Since this extension is generic and applicable to both SR and non-SR paths, the 
description about SR related mechanisms in the introduction section may be 
simplified.

Are you willing to work on this draft?

Yes, I am willing to review the future versions of this document.

Best regards,
Jie


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Tuesday, March 29, 2022 12:09 AM
To: pce@ietf.org
Cc: draft-li-pce-pcep-p...@ietf.org
Subject: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.

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

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 11th April 2022.

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

Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

[Dongjie (Jimmy)]

Hi Samuel,

Thanks for your response, please see some replies inline [Jie #3]

From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Tuesday, March 22, 2022 6:42 PM
To: Dongjie (Jimmy) 
Cc: draft-tokar-pce-sid-a...@ietf.org; Dhruv Dhody ; 
pce@ietf.org; Mahendra Negi 
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Please see inline .

Regards,
Samuel

From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Monday, March 21, 2022 5:07 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Samuel,

Sorry for the late reply.  It is good to see this document adopted, and please 
see some further replies inline with [Jie #2]:


From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Tuesday, February 22, 2022 5:49 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Thanks for your comments. Please see inline :

Regards,
Samuel

From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Monday, February 21, 2022 4:45 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Samuel,

Thanks for your reply. Please see further inline:

From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Friday, February 18, 2022 7:27 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Combining responses for 1. and 2. as those are related:

Encoding of SID/ERO-subobject level was used, because of multiple reasons:

a)  We may need to signal SL, which is explicitly configured by user (not 
just computed by PCE) and in such case user can potentially mix SIDs with 
different algorithms (if user is accepting risk of loops or if user knows that 
it cannot happen for various reasons in that specific case).

[Jie] Do you mean using PCEP to signal a configured SID list which consists of 
SIDs with different algorithms? To avoid the risk of loop, normally user would 
prefer to configure either SID list with strict path, or SIDs with consistent 
algorithm. Even if it is known that there is no loop, different algorithms 
represent different requirements to the path, logically can a path built with 
different algorithms meet specific requirement?

Thus it would be helpful to describe the typical scenario(s) of configuring 
SIDs with different algorithms .

 In most of the cases, requirements == algo used, but there are cases, where 
it may not be possible. Some examples.

·case b) bellow (inter-domain)

·support for less capable nodes (e.g. some node/nodes without 
SSPF/Algo1 support, but user want to use SSPF SIDs wherever possible and where 
user knows that it is still safe to mix SIDs). Implementation (PCE/PCC) can 
have local policy (e.g. some configuration) to decide if potentially unsafe 
paths should be used or blocked.

As soon as we have at least possible use case (even if it is corner case), it 
may be bad idea to block it on protocol level. I agree that it may be good to 
describe use cases above in the draft.

[Jie #2] OK, I understand there can be cases of falling back from a specific 
Algorithm to the default algorithm, in such case the PCE may need to be 
responsible for determining whether the path with Mixed SID is safe or not, as 
the PCCs may not have enough information for such check.

 Ack. If PCE is doing path-computation, then it can be responsible for 
considering if path is safe or not. If it is explicitly configured SL on PCC, 
then PCC/operator are responsible. Anyway – I assume that we are in sync that 
algo per SID/hop may be needed.

[Jie #3] Yes. And some descriptions to the draft to reflect the discussion in 
this thread would be helpful.



b)  Different algorithm ID != different algorithm. With flex-algo different 
ID can be used for identification of same algorithm (e.g. in different IGP 
domains). Mixing SIDs with different algorit

Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

[Dongjie (Jimmy)]

Hi Samuel,

Sorry for the late reply.  It is good to see this document adopted, and please 
see some further replies inline with [Jie #2]:


From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Tuesday, February 22, 2022 5:49 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Thanks for your comments. Please see inline :

Regards,
Samuel

From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Monday, February 21, 2022 4:45 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Samuel,

Thanks for your reply. Please see further inline:

From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Friday, February 18, 2022 7:27 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Combining responses for 1. and 2. as those are related:

Encoding of SID/ERO-subobject level was used, because of multiple reasons:

a)  We may need to signal SL, which is explicitly configured by user (not 
just computed by PCE) and in such case user can potentially mix SIDs with 
different algorithms (if user is accepting risk of loops or if user knows that 
it cannot happen for various reasons in that specific case).

[Jie] Do you mean using PCEP to signal a configured SID list which consists of 
SIDs with different algorithms? To avoid the risk of loop, normally user would 
prefer to configure either SID list with strict path, or SIDs with consistent 
algorithm. Even if it is known that there is no loop, different algorithms 
represent different requirements to the path, logically can a path built with 
different algorithms meet specific requirement?

Thus it would be helpful to describe the typical scenario(s) of configuring 
SIDs with different algorithms .

 In most of the cases, requirements == algo used, but there are cases, where 
it may not be possible. Some examples.

·case b) bellow (inter-domain)

·support for less capable nodes (e.g. some node/nodes without 
SSPF/Algo1 support, but user want to use SSPF SIDs wherever possible and where 
user knows that it is still safe to mix SIDs). Implementation (PCE/PCC) can 
have local policy (e.g. some configuration) to decide if potentially unsafe 
paths should be used or blocked.

As soon as we have at least possible use case (even if it is corner case), it 
may be bad idea to block it on protocol level. I agree that it may be good to 
describe use cases above in the draft.

[Jie #2] OK, I understand there can be cases of falling back from a specific 
Algorithm to the default algorithm, in such case the PCE may need to be 
responsible for determining whether the path with Mixed SID is safe or not, as 
the PCCs may not have enough information for such check.


b)  Different algorithm ID != different algorithm. With flex-algo different 
ID can be used for identification of same algorithm (e.g. in different IGP 
domains). Mixing SIDs with different algorithm ID in such case is safe, but we 
would not be able to signal such path in PCEP.

[Jie] I agree in the inter-domain case, the same algorithm can be represented 
using different IDs, and SIDs associated with different algorithm IDs can be 
used to build an inter-domain path to meet certain requirement. I’d suggest to 
add some description about this case to the document, and it would be better to 
limit the usage of different algorithm IDs in the ERO to this inter-domain case 
only.

 I’m not sure if we can really have hard requirement for PCC or PCE to check 
it. E.g. in case of configured SID list on PCC - PCC may not have visibility to 
whole topology in case of inter-domain paths, so it may not be able to verify 
it. E.g. consider that user configured SID list like this:

1.  Label 26000 (algo 128)

2.  Label 26005 (algo 129)
PCC can just blindly report such path to PCE even if it does not know if both 
SIDs are in same area/domain or not. If we will strictly say that it is not 
valid, then user configured path can result in breaking protocol level 
limitations. Same applies to PCE, which can be potentially used only as a proxy.

[Jie #2] Agree that the PCC may not have visi

Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

[Dongjie (Jimmy)]

Hi Samuel,

Thanks for your reply. Please see further inline:

From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Friday, February 18, 2022 7:27 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Combining responses for 1. and 2. as those are related:

Encoding of SID/ERO-subobject level was used, because of multiple reasons:

a)  We may need to signal SL, which is explicitly configured by user (not 
just computed by PCE) and in such case user can potentially mix SIDs with 
different algorithms (if user is accepting risk of loops or if user knows that 
it cannot happen for various reasons in that specific case).

[Jie] Do you mean using PCEP to signal a configured SID list which consists of 
SIDs with different algorithms? To avoid the risk of loop, normally user would 
prefer to configure either SID list with strict path, or SIDs with consistent 
algorithm. Even if it is known that there is no loop, different algorithms 
represent different requirements to the path, logically can a path built with 
different algorithms meet specific requirement?

Thus it would be helpful to describe the typical scenario(s) of configuring 
SIDs with different algorithms .


b)  Different algorithm ID != different algorithm. With flex-algo different 
ID can be used for identification of same algorithm (e.g. in different IGP 
domains). Mixing SIDs with different algorithm ID in such case is safe, but we 
would not be able to signal such path in PCEP.

[Jie] I agree in the inter-domain case, the same algorithm can be represented 
using different IDs, and SIDs associated with different algorithm IDs can be 
used to build an inter-domain path to meet certain requirement. I’d suggest to 
add some description about this case to the document, and it would be better to 
limit the usage of different algorithm IDs in the ERO to this inter-domain case 
only.


c)  Also related to explicit SL – in some cases, user may configure SL 
explicitly on headend. Headend may not be able to resolve complete SL, so it 
may not be sure if algorithm of all SIDs is same.

[Jie] Understood.

3. We defined new types in older version of this draft – see:
https://datatracker.ietf.org/doc/html/draft-tokar-pce-sid-algo-03#section-6.1
but there were multiple comments indicating that it is resulting in too many 
new types (we need to extend draft for Adjacency SIDs as well) and it would be 
hard to maintain it for future – e.g. for cases where new NAI types are added. 
With this change we would have to double number of NAI types. Any extension 
like this in the future would double it again.

[Jie] Thanks for the pointer, I understand the cost of introducing new NAI 
types. While comparing to the format of SID types in BGP SR Policy, there is a 
fixed algorithm field and a A Flag is used to indicate whether this field 
carries an algorithm value or not. Perhaps another approach is to update the 
format of the existing NAI types to include the algorithm field. This could 
also better align the NAI types in PCEP with the Segment types in BGP.

Thoughts?

Best regards,
Jie

4. Makes sense. We will align it.

Regards,
Samuel

From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Friday, February 18, 2022 10:09 AM
To: Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>
Cc: 
draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; 
Mahendra Negi mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG, chairs,

I just read the latest version of this document. In general incorporating 
Algorithm into PCEP could be useful. While I have the below questions on this 
version and it would be helpful if they can be resolved before adoption.


1.  This document introduces the algorithm constraint in the LSPA object, 
which means the algorithm needs to be considered in the computation of the 
path. IMO this is important for computing a loop-free path. While the draft 
also says that the “the PCE MAY insert prefix SIDs with a different Algorithm 
in order to successfully compute a path.” Mixing SIDs with different algorithms 
in a path has the risk of loops. It is suggested that the document provides 
some analysis about such risk, and the example of scenarios where mixing SIDs 
with different algorithms is safe and desired.


2.  This is related to the first question. If the analysis shows that using 
SIDs with different algorithms in a path is not a good idea, then it would be 
unnecessary to carry the algorithm ID in SERO subobjects, instead carrying it 
as a path attribute would be enough.



3.  Assuming the answ

Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

[Dongjie (Jimmy)]

Hi WG, chairs,

I just read the latest version of this document. In general incorporating 
Algorithm into PCEP could be useful. While I have the below questions on this 
version and it would be helpful if they can be resolved before adoption.


1.   This document introduces the algorithm constraint in the LSPA object, 
which means the algorithm needs to be considered in the computation of the 
path. IMO this is important for computing a loop-free path. While the draft 
also says that the “the PCE MAY insert prefix SIDs with a different Algorithm 
in order to successfully compute a path.” Mixing SIDs with different algorithms 
in a path has the risk of loops. It is suggested that the document provides 
some analysis about such risk, and the example of scenarios where mixing SIDs 
with different algorithms is safe and desired.


2.   This is related to the first question. If the analysis shows that 
using SIDs with different algorithms in a path is not a good idea, then it 
would be unnecessary to carry the algorithm ID in SERO subobjects, instead 
carrying it as a path attribute would be enough.



3.   Assuming the answer to question 2 is YES, the SR-ERO and SRv6-ERO 
subobjects were defined with a fixed format (do not support sub-TLVs), this 
document introduces an additional optional field to those sub-objects, and use 
a new flag to indicate the existence of the new optional field. To my 
understanding this is not a usual approach for protocol extension. Usually a 
new Type needs to be defined for a new format. It would be necessary to 
understand the implication of using flags to indicate the modification to the 
format of an existing object.



4.   The term “SID Algorithm” in this document is different from that is 
used in the RFCs of SR/SRv6 IGP/BGP extensions, where it is called 
“SR-Algorithm”. Suggest to make them consistent.

Best regards,
Jie

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Friday, February 18, 2022 12:08 PM
To: pce@ietf.org
Cc: draft-tokar-pce-sid-a...@ietf.org; Mahendra Negi 
Subject: Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG,

A reminder to please respond to the WG adoption poll by Monday!

Please be more vocal. The silence makes it difficult to judge consensus.

Also, the IPR responses from Alex, Shuping, and Mahendra are missing still.

Thanks!
Dhruv & Julien

On Fri, Feb 4, 2022 at 10:44 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email begins the WG adoption poll for draft-tokar-pce-sid-algo-05.

https://datatracker.ietf.org/doc/draft-tokar-pce-sid-algo/

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 21st Feb 2022.

Have a great weekend.

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

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

[Dongjie (Jimmy)]

Hi Julien,

I've read both the previous version before the split and the latest version of 
this document, and I support its adoption. 

Best regards,
Jie

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of
> julien.meu...@orange.com
> Sent: Thursday, January 6, 2022 8:57 PM
> To: pce@ietf.org
> Subject: Re: [Pce] Adoption Poll for draft-li-pce-pcep-l2-flowspec
> 
> 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/
> 

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

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

[Dongjie (Jimmy)]

Yes, support. It introduces a useful feature to PCEP. 

Best regards,
Jie

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of
> julien.meu...@orange.com
> Sent: Tuesday, September 21, 2021 10:01 PM
> To: pce@ietf.org
> Subject: [Pce] Adoption of draft-dhody-pce-stateful-pce-optional
> 
> 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
> 

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

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

[Dongjie (Jimmy)]

Hi,

I've read the latest version of this document, and think it is ready for 
publication. 

Best regards,
Jie

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: Friday, September 4, 2020 1:13 PM
> To: pce@ietf.org
> Cc: draft-ietf-pce-association-pol...@ietf.org; pce-chairs 
> 
> Subject: [Pce] WGLC for draft-ietf-pce-association-policy
> 
> Hi WG,
> 
> This email starts a working group last call for 
> draft-ietf-pce-association-policy
> [1].  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 21st September 2020.
> 
> Thanks,
> Dhruv & Julien
> [1] https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

Re: [Pce] WG adoption poll for draft-barth-pce-segment-routing-policy-cp-06

[Dongjie (Jimmy)]

Hi, 

I support the adoption of this document. 

Best regards,
Jie

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: Sunday, June 7, 2020 3:45 PM
> To: pce@ietf.org
> Subject: [Pce] WG adoption poll for
> draft-barth-pce-segment-routing-policy-cp-06
> 
> Hi WG,
> 
> This email begins the WG adoption poll for
> draft-barth-pce-segment-routing-policy-cp-06.
> 
> https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/06/
> 
> 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.
> 
> This adoption poll will end on 22nd June 2020.
> 
> 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

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

[Dongjie (Jimmy)]

Hi WG,

I (as a coauthor) support the adoption of this document.

Best regards,
Jie



发件人：julien.meuric 
收件人：pce 
时 间：2020-01-17 18:13:12
主 题：[Pce] Adoption of draft-li-pce-sr-bidir-path-06?

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

Re: [Pce] IPR Poll on draft-li-pce-sr-bidir-path-06

[Dongjie (Jimmy)]

Hi Hari,

I am not aware of any IPR applies to this document.

Best regards,
Jie



发件人：Hariharan Ananthakrishnan 
收件人：Chengli (Cheng Li) ;Mach Chen 
;Weiqiang Cheng ;Lizhenbin 
;Dongjie (Jimmy) ;Rakesh Gandhi 
;xiong.quan 
抄 送：pce 
时 间：2020-01-18 02:31:59
主 题：IPR Poll on draft-li-pce-sr-bidir-path-06


Hi Authors,

In preparation for Working Group 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 IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

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

Re: [Pce] WG Last Call of draft-ietf-pce-pcep-flowspec

[Dongjie (Jimmy)]

Hi, 

This document is useful and stable, thus I support the publication. 

Best regards,
Jie

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of
> julien.meu...@orange.com
> Sent: Monday, October 14, 2019 8:55 PM
> To: pce@ietf.org
> Subject: [Pce] WG Last Call of draft-ietf-pce-pcep-flowspec
> 
> 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

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

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

[Dongjie (Jimmy)]

Hi, 

I (as a coauthor) support the adoption of this document. The PCEP extension 
will facilitate the deployment of Path Segment. 

Best regards,
Jie

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of
> julien.meu...@orange.com
> Sent: Thursday, September 26, 2019 12:21 AM
> To: pce@ietf.org
> Subject: [Pce] Adoption of draft-li-pce-sr-path-segment?
> 
> 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 mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll on draft-li-pce-sr-path-segment-08

[Dongjie (Jimmy)]

Hi Hari and WG,

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

Best regards,
Jie

From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Thursday, September 26, 2019 1:49 AM
To: Chengli (Cheng Li) ; Mach Chen 
; chengweiqi...@chinamobile.com; Dongjie (Jimmy) 
; Lizhenbin ; rgan...@cisco.com; 
xiong.q...@zte.com.cn
Cc: pce@ietf.org
Subject: IPR Poll on draft-li-pce-sr-path-segment-08


Hi Authors,



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

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

with IETF IPR rules.



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



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

in accordance with IETF IPR rules.



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

disclosed to the IETF.



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

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

timely manner.



Thanks,

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

Re: [Pce] Adrian stepping down as PCE co-chair

[Dongjie (Jimmy)]

Many thanks, Adrian!

-Jie

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, September 12, 2019 4:14 AM
To: pce@ietf.org
Cc: pce-chairs 
Subject: [Pce] Adrian stepping down as PCE co-chair

Hi,

As we noted earlier, Adrian stepped in to help us with the PCE document queue 
and help bring Dhruv on as a new chair. He has done a fantastic job and Dhruv 
and Julien are now ready to go forward.

We very much appreciate his support and thank him for all his help!

Deborah

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

Re: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07

[Dongjie (Jimmy)]

Yes, support the adoption. It provides an useful mechanism for the allocation 
and negotiation of binding SID.

Best regards,
Jie

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: Wednesday, August 21, 2019 1:45 AM
> To: pce@ietf.org
> Cc: pce-chairs 
> Subject: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07
> 
> Hi WG,
> 
> This email begins the WG adoption poll for
> draft-sivabalan-pce-binding-label-sid-07 [1].
> 
> Should this draft be adopted by the PCE WG? Please state your reasons - Why /
> Why not? What needs to be fixed before or after adoption? Are you willing to
> work on this draft? Review comments should be posted to the list.
> 
> One of the chairs did a pre-adoption review [2] and authors posted a new
> revision. Note that there are known implementations.
> 
> This adoption poll will end on 6th September 2019.
> 
> Thanks!
> Dhruv (for the chairs)
> 
> 
> [1] https://tools.ietf.org/html/draft-sivabalan-pce-binding-label-sid-07
> [2] https://mailarchive.ietf.org/arch/msg/pce/oaBIRA9FnNsV6-JrKKRCdwtLysk
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

Re: [Pce] Replacing Jon as PCE Co-Chair

[Dongjie (Jimmy)]

Many thanks for Jon’s great contribution, and big congratulations to Dhruv!

(It’s always a pleasure working with Adrian☺)

Best regards,
Jie

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Tuesday, January 29, 2019 12:13 AM
To: pce@ietf.org
Cc:  (rtg-...@ietf.org) ; 
pce-cha...@ietf.org
Subject: [Pce] Replacing Jon as PCE Co-Chair

Hi PCEers,

As announced at IETF103, Jon Hardwick has requested to step down as PCE 
Co-Chair. We thank him for his many years of service and wish him all the best!

As Jon is very difficult to replace and to help Julien over these next several 
months, I’ve decided to replace Jon with two Co-Chairs: Dhruv Dhody and Adrian 
Farrel.

Dhruv is one of our top lead technical contributors in PCE and he is currently 
the PCE secretary. I am sure he will be fantastic in his new role as Co-Chair. 
The difficulty is that he is a co-author on a high proportion of the PCE drafts 
and that is not a good thing for a Chair as it will severely burden the other 
Co-Chair with managing those documents. Because of this difficulty, I’ve asked 
Dhruv to re-allocate authorship on a majority of his drafts as quickly as 
possible. Dhruv has agreed.

While Dhruv is learning the ropes of being a Chair and re-distributing his 
drafts, I’ve asked Adrian to help. Adrian, of course, is well known to all of 
us. No introduction needed

It is expected Adrian will only be needed for approximately 4 months.

Welcome to both Dhruv and Adrian!

Thanks!
Deborah

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

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

[Dongjie (Jimmy)]

Yes/support.

Best regards,
Jie

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Saturday, October 13, 2018 10:47 PM
To: pce@ietf.org
Cc: draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org
Subject: [Pce] WG adoption poll for 
draft-zhao-pce-pcep-extension-for-pce-controller-08

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

Please review the draft and send an email to the list indicating "yes/support" 
or "no/do not support".  If indicating no, please state your reasons.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

The poll ends on Friday, October 26.

Many thanks,

Jon and Julien

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

[Pce] Solicit review comments on draft-dong-pce-discovery-proto-bgp-06

[Dongjie (Jimmy)]

Dear all,

draft-dong-pce-discovery-proto-bgp defines extensions to BGP for the 
advertisement of PCE discovery information. After several revisions, the draft 
is now getting stable. As suggested by the PCE chair, the authors would like to 
collect review comments also from the IDR WG.

Here is the link to the latest version:

https://tools.ietf.org/html/draft-dong-pce-discovery-proto-bgp-06

Comments are welcome.

Best regards,
Jie (on behalf of coauthors)

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

[Pce] FW: I-D Action: draft-dong-pce-discovery-proto-bgp-06.txt

[Dongjie (Jimmy)]

Hi all, 

We have uploaded a new version of draft-dong-pce-discovery-proto-bgp. According 
to the suggestions from the chairs, some changes are made to make this draft 
more focusing on the protocol part: 

- removed extra texts about various use cases

- aligned the draft to RFC 7752 (BGP-LS) in terms of encoding as well as text

The authors believe the draft is now in good shape and would appreciate further 
review and comments. Thanks.

Best regards,
Jie

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Thursday, October 27, 2016 3:34 PM
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-dong-pce-discovery-proto-bgp-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : BGP Extensions for Path Computation Element (PCE) 
Discovery
Authors : Jie Dong
  Mach(Guoyi) Chen
  Dhruv Dhody
  Jeff Tantsura
  Kenji Kumaki
  Tomoki Murai
Filename: draft-dong-pce-discovery-proto-bgp-06.txt
Pages   : 10
Date: 2016-10-27

Abstract:
   In networks where a Path Computation Element (PCE) is used for path
   computation, it is desirable for the Path Computation Clients (PCCs)
   to discover dynamically and automatically a set of PCEs along with
   certain information relevant for PCE selection.  RFC 5088 and RFC
   5089 define the PCE discovery mechanisms based on Interior Gateway
   Protocols (IGP).  This document defines extensions to BGP for the
   advertisement of PCE Discovery information.  The BGP based PCE
   discovery mechanism is complementary to the existing IGP based
   mechanisms.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-dong-pce-discovery-proto-bgp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-dong-pce-discovery-proto-bgp-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-dong-pce-discovery-proto-bgp-06


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[Pce] FW: I-D Action: draft-dong-pce-discovery-proto-bgp-05.txt

[Dongjie (Jimmy)]

Dear all,

A new revision of draft-dong-pce-discovery-proto-bgp has been submitted.

After the discussion with the co-authors of 
draft-kumaki-pce-bgp-disco-attribute, we agreed to work together and move 
forward with this BGP-LS based approach for PCE discovery. 

The major changes in this version are:

1. Added the PCE discovery for VPN use case, and the description of the 
AFI/SAFI setting for the public and VPN cases. 

2. Mr. Kumaki and Mr. Murai are added as co-authors, and Mr. Miyasaka is added 
as contributor.

As always, comments are welcome.

Best regards,
Jie

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Saturday, June 25, 2016 5:05 PM
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-dong-pce-discovery-proto-bgp-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : BGP Extensions for Path Computation Element (PCE) 
Discovery
Authors : Jie Dong
  Mach(Guoyi) Chen
  Dhruv Dhody
  Jeff Tantsura
  Kenji Kumaki
  Tomoki Murai
Filename: draft-dong-pce-discovery-proto-bgp-05.txt
Pages   : 10
Date: 2016-06-25

Abstract:
   In networks where Path Computation Element (PCE) is used for
   centralized path computation, it is desirable for the Path
   Computation Clients (PCCs) to automatically discover a set of PCEs
   and select the suitable ones to establish the PCEP session.  RFC 5088
   and RFC 5089 define the PCE discovery mechanisms based on Interior
   Gateway Protocols (IGP).  This document describes several scenarios
   in which the IGP based PCE discovery mechanisms cannot be used
   directly.  In such scenarios, BGP might be suitable, thus this
   document specifies the BGP extensions for PCE discovery.  The BGP
   based PCE discovery mechanism is complementary to the existing IGP
   based mechanisms.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-dong-pce-discovery-proto-bgp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-dong-pce-discovery-proto-bgp-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-dong-pce-discovery-proto-bgp-05


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[Pce] FW: I-D Action: draft-dong-pce-discovery-proto-bgp-04.txt

[Dongjie (Jimmy)]

Dear all, 

We have updated the BGP based PCE discovery draft to resolve the comments 
received during IETF94 meeting. 

The main changes are:

1. Specify the limitation in IGP based discovery, and improve the use cases of 
BGP based discovery mechanism.
2. Explicitly specify that the interaction between BGP and IGP based discovery 
is out of scope. 
3. Modify the recommended protocol-ID value for PCE discovery information.
4. Improve the operational considerations.
5. Editorial changes.

Any further review comments are welcome and authors believe this revision is 
ready for wg adoption. 

Many thanks,
Jie (on behalf of co-authors)

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Thursday, March 10, 2016 9:53 AM
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-dong-pce-discovery-proto-bgp-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : BGP Extensions for Path Computation Element (PCE) 
Discovery
Authors : Jie Dong
  Mach(Guoyi) Chen
  Dhruv Dhody
  Jeff Tantsura
Filename: draft-dong-pce-discovery-proto-bgp-04.txt
Pages   : 9
Date: 2016-03-09

Abstract:
   In networks where Path Computation Element (PCE) is used for
   centralized path computation, it is desirable for the Path
   Computation Clients (PCCs) to automatically discover a set of PCEs
   and select the suitable ones to establish the PCEP session.  RFC 5088
   and RFC 5089 define the PCE discovery mechanisms based on Interior
   Gateway Protocols (IGP).  This document describes several scenarios
   in which the IGP based PCE discovery mechanisms cannot be used
   directly.  In such scenarios, BGP might be suitable, thus this
   document specifies the BGP extensions for PCE discovery.  The BGP
   based PCE discovery mechanism is complementary to the existing IGP
   based mechanisms.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-dong-pce-discovery-proto-bgp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-dong-pce-discovery-proto-bgp-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-dong-pce-discovery-proto-bgp-04


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[Pce] FW: I-D Action: draft-dong-pce-discovery-proto-bgp-03.txt

[Dongjie (Jimmy)]

Dear all, 

We have submitted a new version of draft-dong-pce-discovery-proto-bgp. 

Changes compared to the previous version are:

1. A new BGP-LS protocol-ID is defined for PCE.
2. Editorial changes.

Comments on this new revision are appreciated.

Many thanks,
Jie (on behalf of co-authors)

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Tuesday, September 01, 2015 3:53 PM
> To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-dong-pce-discovery-proto-bgp-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> Title   : BGP Extensions for Path Computation Element
> (PCE) Discovery
> Authors : Jie Dong
>   Mach(Guoyi) Chen
>   Dhruv Dhody
>   Jeff Tantsura
>   Filename: draft-dong-pce-discovery-proto-bgp-03.txt
>   Pages   : 9
>   Date: 2015-09-01
> 
> Abstract:
>In networks where Path Computation Element (PCE) is used for
>centralized path computation, it is desirable for Path Computation
>Clients (PCCs) to automatically discover a set of PCEs and select the
>suitable ones to establish the PCEP session.  RFC 5088 and RFC 5089
>define the PCE discovery mechanisms based on Interior Gateway
>Protocols (IGP).  This document describes several scenarios in which
>the IGP based PCE discovery mechanisms cannot be used directly.  This
>document specifies the BGP extensions for PCE discovery in these
>scenarios.  The BGP based PCE discovery mechanism is complementary to
>the existing IGP based mechanisms.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-dong-pce-discovery-proto-bgp/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-dong-pce-discovery-proto-bgp-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-dong-pce-discovery-proto-bgp-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/
> 

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