[Pce] Re: Path segment supporting multiple segment lists in a candidate path

[Cheng Li]

Hi Dhruv,

You suggestion works to me. Simple and clear. Nice!

Thank you!
Cheng


From: Dhruv Dhody 
Sent: Friday, September 20, 2024 2:14 PM
To: Cheng Li 
Cc: xiong.q...@zte.com.cn; pce@ietf.org; draft-ietf-pce-sr-path-segm...@ietf.org
Subject: Re: [Pce] Re: Path segment supporting multiple segment lists in a 
candidate path

Hi Cheng,  Quan,

On Fri, Sep 20, 2024 at 2:52 PM Cheng Li 
mailto:40huawei@dmarc.ietf.org>> wrote:

Hi Quan,

Thank you for proposing the text. Please see my comment below.

Thanks,

Cheng



4.5.  Path Attributes Object



   The Path Attributes (PATH-ATTRIB) Object is used to carry per-path

   information and to act as a separator between several ERO/RRO objects

   as per [I-D.ietf-pce-multipath].

As per [RFC9545], a Path Segment can be used to uniquely identify a

   segment list or multiple segment lists in a candidate path or an SR

   policy.

__OLD__

When a set of path segments are used to identify multiple

   segment lists, the Path Segment TLV as described in the

   Section 4.2.1, MUST be carried in the PATH-ATTRIB Object to indicate

   the per-SR-path information regarding the Path Segment identifier.

__OLD__

[Cheng]This might be rephrased. My suggestion.

When multiple ERO/RRO objects are included as per [I-D.ietf-pce-multipath], to 
support multiple segment lists in an Candidate Path [ref to SR policy draft], 
the Path Segment TLV as described in the Section 4.2.1, MUST be carried in the 
PATH-ATTRIB Object to identify each SR path associated with a segment list.

Dhruv: This use of MUST here means that if a PATH-ATTRIB Object exists, the 
Path Segment TLV MUST be encoded in it. But we want to do that only in case 
when a different PSID is used by each segment list.



The P flag in LSP Object is used to indicate that the allocation of all path 
segments need to be done by the PCE. A Path Segment TLV encoded in the LSP 
Object apply to all the ERO/RRO, while a Path Segment TLV encoded in a 
PATH-ATTRIB Object only apply to its ERO. In the cases that all the segment 
lists are sharing a same PSID, the Path Segment TLV can be carried in the LSP 
Object or each PATH-ATTRIB Object, respectively.


Dhruv: I am unsure why we need to highlight the P flag here. The rest of the 
text makes sense if we set or unset the P flag.

Here is my suggestion -

The [I-D.ietf-pce-multipath] defines the PATH-ATTRIB object, which carries 
per-path information and serves as a separator between multiple ERO/RRO 
objects, enabling the encoding of multiple segment lists in a Candidate Path, 
as described in [I-D.ietf-pce-segment-routing-policy-cp]. The Path Segment TLV 
can be optionally included in the PATH-ATTRIB object to associate a segment 
list with the PSID. It’s important to note that the Path Segment TLV in the 
PATH-ATTRIB object applies to the path (the immediately following ERO/RRO), 
whereas the Path Segment TLV in the LSP object applies to all paths in the PCEP 
message. If the PSID is encoded in the PATH-ATTRIB object, it MUST be used to 
identify the SR path.

Thanks!
Dhruv


From: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> 
mailto:xiong.q...@zte.com.cn>>
Sent: Friday, September 20, 2024 10:59 AM
To: pce@ietf.org<mailto:pce@ietf.org>
Cc: 
draft-ietf-pce-sr-path-segm...@ietf.org<mailto:draft-ietf-pce-sr-path-segm...@ietf.org>
Subject: Path segment supporting multiple segment lists in a candidate path




Hi PCE WG,



A new version has been submitted as per 
https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-11.txt.



But in case of supporting multiple segment lists in a candidate path, it is 
required to add Path Segment TLV into Path Attributes Object as different path 
segment may identify different segment list . And in order to make it backward 
compatible to current implementation, it needs to allow carrying the TLV in 
both LSP and PATH-ATTRIB object. So I suggest to add a new section to describe 
this part of extension as following shown.





4.5.  Path Attributes Object



   The Path Attributes (PATH-ATTRIB) Object is used to carry per-path

   information and to act as a separator between several ERO/RRO objects

   as per [I-D.ietf-pce-multipath].



   As per [RFC9545], a Path Segment can be used to uniquely identify a

   segment list or multiple segment lists in a candidate path or an SR

   policy.  When a set of path segments are used to identify multiple

   segment lists, the Path Segment TLV as described in the

   Section 4.2.1, MUST be carried in the PATH-ATTRIB Object to indicate

   the per-SR-path information regarding the Path Segment identifier.

   The P flag in LSP Object is used to indicate that the allocation of

   all path segments need to be done by the PCE.  When one single path

   segment is used to identify all segment lists, the Path Segment TLV

   MAY be carried in the LSP Object or PATH-ATTRIB Object.  But the Path

   Segment TLV MUST be ignored in the LSP Object when 

[Pce] Re: Path segment supporting multiple segment lists in a candidate path

[Cheng Li]

Hi Quan,

Thank you for proposing the text. Please see my comment below.

Thanks,

Cheng



4.5.  Path Attributes Object



   The Path Attributes (PATH-ATTRIB) Object is used to carry per-path

   information and to act as a separator between several ERO/RRO objects

   as per [I-D.ietf-pce-multipath].

As per [RFC9545], a Path Segment can be used to uniquely identify a

   segment list or multiple segment lists in a candidate path or an SR

   policy.

__OLD__

When a set of path segments are used to identify multiple

   segment lists, the Path Segment TLV as described in the

   Section 4.2.1, MUST be carried in the PATH-ATTRIB Object to indicate

   the per-SR-path information regarding the Path Segment identifier.

__OLD__

[Cheng]This might be rephrased. My suggestion.

When multiple ERO/RRO objects are included as per [I-D.ietf-pce-multipath], to 
support multiple segment lists in an Candidate Path [ref to SR policy draft], 
the Path Segment TLV as described in the Section 4.2.1, MUST be carried in the 
PATH-ATTRIB Object to identify each SR path associated with a segment list.

The P flag in LSP Object is used to indicate that the allocation of all path 
segments need to be done by the PCE. A Path Segment TLV encoded in the LSP 
Object apply to all the ERO/RRO, while a Path Segment TLV encoded in a 
PATH-ATTRIB Object only apply to its ERO. In the cases that all the segment 
lists are sharing a same PSID, the Path Segment TLV can be carried in the LSP 
Object or each PATH-ATTRIB Object, respectively.


From: xiong.q...@zte.com.cn 
Sent: Friday, September 20, 2024 10:59 AM
To: pce@ietf.org
Cc: draft-ietf-pce-sr-path-segm...@ietf.org
Subject: Path segment supporting multiple segment lists in a candidate path




Hi PCE WG,



A new version has been submitted as per 
https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-11.txt.



But in case of supporting multiple segment lists in a candidate path, it is 
required to add Path Segment TLV into Path Attributes Object as different path 
segment may identify different segment list . And in order to make it backward 
compatible to current implementation, it needs to allow carrying the TLV in 
both LSP and PATH-ATTRIB object. So I suggest to add a new section to describe 
this part of extension as following shown.





4.5.  Path Attributes Object



   The Path Attributes (PATH-ATTRIB) Object is used to carry per-path

   information and to act as a separator between several ERO/RRO objects

   as per [I-D.ietf-pce-multipath].



   As per [RFC9545], a Path Segment can be used to uniquely identify a

   segment list or multiple segment lists in a candidate path or an SR

   policy.  When a set of path segments are used to identify multiple

   segment lists, the Path Segment TLV as described in the

   Section 4.2.1, MUST be carried in the PATH-ATTRIB Object to indicate

   the per-SR-path information regarding the Path Segment identifier.

   The P flag in LSP Object is used to indicate that the allocation of

   all path segments need to be done by the PCE.  When one single path

   segment is used to identify all segment lists, the Path Segment TLV

   MAY be carried in the LSP Object or PATH-ATTRIB Object.  But the Path

   Segment TLV MUST be ignored in the LSP Object when it is also

   included in the PATH-ATTRIB Object.



What is your thoughts? Any comments and suggestions are welcome. Thanks!



Best Regards,

Quan




___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: 答复: WG Last Call for draft-ietf-pce-iana-update

[Cheng Li]

Wow, this is a useful draft! I support to move this forward!
With the experimental type and value of error code, it can release the power of 
protocol extension, people can do many innovation in their own network.

My take is that this is a very good draft. 

One comment: How can we let business managers to understand the value of this 
kind of draft? LOL. Thanks for your contribution @DHRUV DHODY and 
@adr...@olddog.co.uk

Thanks,
Cheng




-Original Message-
From: Aijun Wang  
Sent: Tuesday, September 10, 2024 8:29 AM
To: julien.meu...@orange.com; pce@ietf.org
Subject: [Pce] 答复: WG Last Call for draft-ietf-pce-iana-update

Support its forwarding!

Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
julien.meu...@orange.com
发送时间: 2024年9月6日 20:24
收件人: pce@ietf.org
主题: [Pce] WG Last Call for draft-ietf-pce-iana-update

Hi all,

Since we have consensus, let's move forward with this simple fix to [1], as 
agreed with the IESG. This message starts a 2-week WG last call for
draft-ietf-pce-iana-update-01 [2]. Please share your support or comments on the 
PCE mailing list by Friday September 20.

Thank you,

Julien


[1] https://www.rfc-editor.org/cluster_info.php?cid=C519
[2] https://datatracker.ietf.org/doc/html/draft-ietf-pce-iana-update-01


___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

[Cheng Li]

Hi Dhruv,



-Original Message-
From: Dhruv Dhody  
Sent: Wednesday, September 11, 2024 5:26 PM
To: xiong.q...@zte.com.cn
Cc: Cheng Li ; draft-ietf-pce-sr-path-segm...@ietf.org; 
pce@ietf.org
Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

Hi Quan, Cheng

For this text ->

The ASSOCIATION object should also be carried in PCInitiate message to indicate 
the SR policy association parameters as per 
[I-D.ietf-pce-segment-routing-policy-cp], if this path segment identifies an SR 
policy.

Note that currently we do not have a way to signal if the path segment 
identifies a CP or a SR-Policy.
(1) Is it required to be explicitly signalled?
(2) Or should you simply state that the SR policy association needs to be 
included if the SR path belongs to an SR Policy?
(3) Consider using normative keywords here MUST(?)

[Cheng]I think they are independent. A Path Segment is used for identifying an 
LSP/Path. Then a Path may be associated with others in a Candidate path or a SR 
policy in the end, I think they are independent, if I am understanding correct. 
So it should be option 2.

==

Consider adding this text in the Introduction ->

Although [RFC9050] defines the PCE as the central controller (PCECC) model, 
where the PCE can instruct each hop (including the egress) on the end-to-end 
path, PCE (as per [RFC5040], [RFC8231], and [RFC8281]) typically only 
communicates with the ingress node. However, since the path segment identifies 
the SR path on the egress node, the PCE must also communicate with the egress 
node. This document outlines a mechanism to use the existing stateful message 
exchange with the egress node to signal both the SR path and the path segment.

[Cheng]I am ok with this proposal.
==

Thanks!
Dhruv (as a WG participant)


On Wed, Sep 11, 2024 at 12:17 PM  wrote:

>
> Hi Cheng and Co-authors,
>
>
> I have updated the draft as discussed and the diff file is attached.
>
> Please review and comment and I will submit it before this weekend! Thanks!
>
>
> Best Regards,
>
> Quan
>
>
> Original
> *From: *ChengLi 
> *To: *熊泉00091065;d...@dhruvdhody.com ;
> *Cc: *pce@ietf.org 
> ;draft-ietf-pce-sr-path-segm...@ietf.org
> ;
> *Date: *2024年09月09日 17:42
> *Subject: **RE: [Pce] Re: I-D Action:
> draft-ietf-pce-sr-path-segment-10.txt*
>
> Hi Quan,
>
>
>
> Do you mind to lead this update? If yes, please update the xml(You can 
> download it from the datatracker) and share the diff file for authors 
> to review.
>
>
>
> I am crazy busy on updating 10+ drafts recently. If you can help on 
> this, I will be very appreciated!
>
>
>
> Thanks,
>
> Cheng
>
>
>
>
>
> *From:* xiong.q...@zte.com.cn 
> *Sent:* Monday, September 9, 2024 11:23 AM
> *To:* d...@dhruvdhody.com
> *Cc:* jmh.dir...@joelhalpern.com; gregimir...@gmail.com; pce@ietf.org; 
> draft-ietf-pce-sr-path-segm...@ietf.org
> *Subject:* Re: [Pce] Re: I-D Action: 
> draft-ietf-pce-sr-path-segment-10.txt
>
>
>
>
>
> Hi Dhruv and Joel,
>
>
>
> Thanks for your suggestion!
>
>
>
> The adding texts in my last email mainly clarify the path segment 
> related parameters (e.g association) within an SR policy.  I think the 
> PCE communicates with the tail instead of a notification, for example, 
> as figure 3 shown, it send PCInitiate message to the egress PCC for 
> PCE tail notification, for example, as figure 3 shown.
>
>
>
> I agree that the path segment is the first function that requires 
> communication with both tail and head end cause the the path segment 
> should be inserted at the ingress PCC and should be recognized at the egress 
> PCC
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

[Cheng Li]

The update looks good to me. Thank you for your work!

Respect,
Cheng


From: xiong.q...@zte.com.cn 
Sent: Wednesday, September 11, 2024 8:47 AM
To: Cheng Li ; draft-ietf-pce-sr-path-segm...@ietf.org
Cc: d...@dhruvdhody.com; pce@ietf.org
Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt




Hi Cheng and Co-authors,



I have updated the draft as discussed and the diff file is attached.

Please review and comment and I will submit it before this weekend! Thanks!



Best Regards,

Quan


Original
From: ChengLi mailto:c...@huawei.com>>
To: 熊泉00091065;d...@dhruvdhody.com 
mailto:d...@dhruvdhody.com>>;
Cc: pce@ietf.org<mailto:pce@ietf.org> 
mailto:pce@ietf.org>>;draft-ietf-pce-sr-path-segm...@ietf.org 
mailto:draft-ietf-pce-sr-path-segm...@ietf.org>>;
Date: 2024年09月09日 17:42
Subject: RE: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt
Hi Quan,

Do you mind to lead this update? If yes, please update the xml(You can download 
it from the datatracker) and share the diff file for authors to review.

I am crazy busy on updating 10+ drafts recently. If you can help on this, I 
will be very appreciated!

Thanks,
Cheng


From: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> 
mailto:xiong.q...@zte.com.cn>>
Sent: Monday, September 9, 2024 11:23 AM
To: d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>
Cc: jmh.dir...@joelhalpern.com<mailto:jmh.dir...@joelhalpern.com>; 
gregimir...@gmail.com<mailto:gregimir...@gmail.com>; 
pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-sr-path-segm...@ietf.org<mailto:draft-ietf-pce-sr-path-segm...@ietf.org>
Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt




Hi Dhruv and Joel,



Thanks for your suggestion!



The adding texts in my last email mainly clarify the path segment related 
parameters (e.g association) within an SR policy.  I think the PCE communicates 
with the tail instead of a notification, for example, as figure 3 shown, it 
send PCInitiate message to the egress PCC for PCE tail notification, for 
example, as figure 3 shown.



I agree that the path segment is the first function that requires communication 
with both tail and head end cause the the path segment should be inserted at 
the ingress PCC and should be recognized at the egress PCC.

From my understanding, the section 3 has described the operations, as per 
https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-10.html#name-overview-of-path-segment-ex,
 the path segment can be allocated by egress PCC or PCE.

A, If it is allocated by the egress PCC as per section 5.1, the PCE (or ingress 
PCC first sends requests to the PCE) should request a path segment from egress 
PCC and notify the ingress PCC.

B, If it is allocated by the PCE as per section 5.2, the PCE should allocate a 
path segment and notify both ingress and egress PCC.



Would it be better to clarify it clearly in section 3 like following shown?

"There are various modes of operations, such as

• The Path Segment can be allocated by Egress PCC. The PCE should 
request the Path Segment from egress PCC by PCInitiate messge and notify the 
ingress PCC bu PCUpd messge as per section 5.1.2.

• The PCE (or the ingress PCC requests the path segment to PCE) can 
allocate a Path Segment on its own accord and inform the ingress/egress PCC by 
PCInitiate or PCUpd messge as per section 5.2.2.

• Ingress PCC can also request PCE to allocate the Path Segment, in 
this case, the PCE would either allocate and inform the assigned Path Segment 
to the ingress/egress PCC using PCInitiate or PCUpd  message, or first request 
egress PCC for Path Segment and then inform it to the ingress PCC as per 5.1.1.

"

What is your thoughts?



Best,

Quan


Original
From: DhruvDhody mailto:d...@dhruvdhody.com>>
To: Joel Halpern 
mailto:jmh.dir...@joelhalpern.com>>;
Cc: 熊泉00091065;gregimir...@gmail.com 
mailto:gregimir...@gmail.com>>;pce@ietf.org 
mailto:pce@ietf.org>>;draft-ietf-pce-sr-path-segm...@ietf.org 
mailto:draft-ietf-pce-sr-path-segm...@ietf.org>>;
Date: 2024年09月09日 12:43
Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt
Hi Joel,

On Fri, Sep 6, 2024 at 7:22 PM Joel Halpern 
mailto:jmh.dir...@joelhalpern..com>>
wrote:

> These references appear useful.  There is however one aspect that I am
> missing.  It may well be my own mistake, rather than a problem in the
> draft.  The usage of the sr path segment relies on the tail of the path
> being able to recognize the path segment label.  I am not familiar with any
> usage of PCE that communicates path information to the LSP tail end, rather
> than the head end.  Looking at the drat you point to in these changes, I do
> not see any addition of tail notification.  Is there already a PCE tail
> notification that I have forgotten about?
>

There is a PCECC model RFC 905

[Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

[Cheng Li]

Hi Quan,

Do you mind to lead this update? If yes, please update the xml(You can download 
it from the datatracker) and share the diff file for authors to review.

I am crazy busy on updating 10+ drafts recently. If you can help on this, I 
will be very appreciated!

Thanks,
Cheng


From: xiong.q...@zte.com.cn 
Sent: Monday, September 9, 2024 11:23 AM
To: d...@dhruvdhody.com
Cc: jmh.dir...@joelhalpern.com; gregimir...@gmail.com; pce@ietf.org; 
draft-ietf-pce-sr-path-segm...@ietf.org
Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt




Hi Dhruv and Joel,



Thanks for your suggestion!



The adding texts in my last email mainly clarify the path segment related 
parameters (e.g association) within an SR policy.  I think the PCE communicates 
with the tail instead of a notification, for example, as figure 3 shown, it 
send PCInitiate message to the egress PCC for PCE tail notification, for 
example, as figure 3 shown.



I agree that the path segment is the first function that requires communication 
with both tail and head end cause the the path segment should be inserted at 
the ingress PCC and should be recognized at the egress PCC.

From my understanding, the section 3 has described the operations, as per 
https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-10.html#name-overview-of-path-segment-ex,
 the path segment can be allocated by egress PCC or PCE.

A, If it is allocated by the egress PCC as per section 5.1, the PCE (or ingress 
PCC first sends requests to the PCE) should request a path segment from egress 
PCC and notify the ingress PCC.

B, If it is allocated by the PCE as per section 5.2, the PCE should allocate a 
path segment and notify both ingress and egress PCC.



Would it be better to clarify it clearly in section 3 like following shown?

"There are various modes of operations, such as

· The Path Segment can be allocated by Egress PCC. The PCE should 
request the Path Segment from egress PCC by PCInitiate messge and notify the 
ingress PCC bu PCUpd messge as per section 5.1.2.

· The PCE (or the ingress PCC requests the path segment to PCE) can 
allocate a Path Segment on its own accord and inform the ingress/egress PCC by 
PCInitiate or PCUpd messge as per section 5.2.2.

· Ingress PCC can also request PCE to allocate the Path Segment, in 
this case, the PCE would either allocate and inform the assigned Path Segment 
to the ingress/egress PCC using PCInitiate or PCUpd  message, or first request 
egress PCC for Path Segment and then inform it to the ingress PCC as per 5.1.1.

"

What is your thoughts?



Best,

Quan


Original
From: DhruvDhody mailto:d...@dhruvdhody.com>>
To: Joel Halpern 
mailto:jmh.dir...@joelhalpern.com>>;
Cc: 熊泉00091065;gregimir...@gmail.com 
mailto:gregimir...@gmail.com>>;pce@ietf.org 
mailto:pce@ietf.org>>;draft-ietf-pce-sr-path-segm...@ietf.org 
mailto:draft-ietf-pce-sr-path-segm...@ietf.org>>;
Date: 2024年09月09日 12:43
Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt
Hi Joel,

On Fri, Sep 6, 2024 at 7:22 PM Joel Halpern 
mailto:jmh.dir...@joelhalpern..com>>
wrote:

> These references appear useful.  There is however one aspect that I am
> missing.  It may well be my own mistake, rather than a problem in the
> draft.  The usage of the sr path segment relies on the tail of the path
> being able to recognize the path segment label.  I am not familiar with any
> usage of PCE that communicates path information to the LSP tail end, rather
> than the head end.  Looking at the drat you point to in these changes, I do
> not see any addition of tail notification.  Is there already a PCE tail
> notification that I have forgotten about?
>

There is a PCECC model RFC 9050 that communicates with all nodes (including
the tail) along the path, so there is some precedence.

But the path segment draft is the first one that requires communication
with the tail end (
https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-10.html#figure-3)
outside of the PCECC model.

Authors, I suggest that your draft should highlight this explicitly rather
than it being buried in a subsection.

Thanks!
Dhruv



> Thank you,
>
> Joel
> On 9/6/2024 5:20 AM, xiong.q...@zte.com.cn 
> wrote:
>
>
> Hi Greg, Joel and all,
>
>
> Thanks for your discussion on the MPLS mailing list as following link
> shown~
>
> https://mailarchive.ietf.org/arch/msg/mpls/e3CI8xeDN1OTu5FgAIB6tI_yRaY/
>
>
> Allow me to take the discussion to PCE. As per RFC9545 and
> draft-ietf-spring-srv6-path-segment, a path segment can identify a SR path,
> a SR policy,  a candidate-path or a SID-List in a SR policy. But this
> document did not mention the path segment processing within SR policy PCEP
> instantiation. It may cause some misunderstandings about PCEP processes and
> parameters for path segment within a SR policy.  So I suggest to add
> some texts for next version of this draft.  Please see inline with
> .
>
>
>

[Pce] Re: Where the Controlled ID info shuold be carried/encoded?

[Cheng Li]

Yes, I also think this combination is better.
Option 1 Open msg can be used for initial report, and the rest update can be 
reported by the Notification msg.

Already recorded this in the slide.

Cheng


From: Dhruv Dhody 
Sent: Tuesday, July 9, 2024 11:34 AM
To: Cheng Li 
Cc: pce@ietf.org; pce-chairs ; Samuel Sidor (ssidor) 

Subject: Re: [Pce] Where the Controlled ID info shuold be carried/encoded?

Hi,

Samuel made a suggestion to combine the options of using Open and Notification 
together, I have now captured that in the notes page - 
https://notes.ietf.org/draft-ietf-pce-controlled-id-space?view

Feel free to add to the discussion here or on the notes page.

Thanks!
Dhruv

On Sat, Jul 6, 2024 at 2:53 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi Cheng,

To facilitate this discussion I have created a notes page - 
https://notes.ietf.org/draft-ietf-pce-controlled-id-space?view that documents 
the various options.

WG,

Feel free to add things there but add your name for easy tracking.
You can also add your preference for a solution and with reasoning at the 
bottom or simply reply on this thread and I can keep the notes page updated.

Hope the WG finds this useful and it helps in converging on a way forward...

Thanks!
Dhruv

On Thu, Jun 20, 2024 at 10:46 AM Cheng Li 
mailto:40huawei@dmarc.ietf.org>> wrote:
Hi Guys，

Thank you so much for your helpful review and comments of our draft 
draft-ietf-pce-controlled-id-space.
In the WG adoption, I can summarize our discussion into the below bullets, hope 
they are correct,

  1.  The draft is useful, and the mechanism defined in the draft is needed, we 
should work on it. (Thanks!)
  2.  We need to discuss the where the info should be carried in the PCEP. Open 
Object seems not so good ☹
  3.  TLV encoding should be updated to be more generic or let's avoid the 
generic description and define specific sub-TLVs as needed.

I see the reasons why we decided to carry the info in PCEP Open Object, because 
it is a device-wide configuration info, which should not be modified in the 
running state. We may face a lot of trouble of removing some IDs and then 
modify the range in a running network. However, we may also need to handle the 
negotiation between PCC and PCE?  Therefore, I am also concerning about this.

I like to hear your voice on this, which object/msg is appropriate to carry the 
info? I am open with other options.

Possible options could be

•  Open message

•  Use PCEP-LS encoding and make this a node attribute

•  New type of notification

•  New message/object

Once we get the conclusion of this, we can go to the bullet 3, which is much 
easier that bullet 2. IMHO, I will prefer to define sub-TLVs one by one, this 
can decouple the relations between IDs, though we may need to delete the 
'generic' words.

Thoughts?
Cheng

___
Pce mailing list -- pce@ietf.org<mailto:pce@ietf.org>
To unsubscribe send an email to pce-le...@ietf.org<mailto:pce-le...@ietf.org>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Where the Controlled ID info shuold be carried/encoded?

[Cheng Li]

Thank you so much! This is definitely a good way to facilitate a discussion in 
a WG.

I will prepare a slide of this, and share in IETF 120, so guys please, share 
your comments 😊

Respect,
Cheng


From: Dhruv Dhody 
Sent: Saturday, July 6, 2024 3:53 PM
To: Cheng Li 
Cc: pce@ietf.org; pce-chairs 
Subject: [Pce] Re: Where the Controlled ID info shuold be carried/encoded?

Hi Cheng,

To facilitate this discussion I have created a notes page - 
https://notes.ietf.org/draft-ietf-pce-controlled-id-space?view that documents 
the various options.

WG,

Feel free to add things there but add your name for easy tracking.
You can also add your preference for a solution and with reasoning at the 
bottom or simply reply on this thread and I can keep the notes page updated.

Hope the WG finds this useful and it helps in converging on a way forward...

Thanks!
Dhruv

On Thu, Jun 20, 2024 at 10:46 AM Cheng Li 
mailto:40huawei@dmarc.ietf.org>> wrote:
Hi Guys，

Thank you so much for your helpful review and comments of our draft 
draft-ietf-pce-controlled-id-space.
In the WG adoption, I can summarize our discussion into the below bullets, hope 
they are correct,

  1.  The draft is useful, and the mechanism defined in the draft is needed, we 
should work on it. (Thanks!)
  2.  We need to discuss the where the info should be carried in the PCEP. Open 
Object seems not so good ☹
  3.  TLV encoding should be updated to be more generic or let's avoid the 
generic description and define specific sub-TLVs as needed.

I see the reasons why we decided to carry the info in PCEP Open Object, because 
it is a device-wide configuration info, which should not be modified in the 
running state. We may face a lot of trouble of removing some IDs and then 
modify the range in a running network. However, we may also need to handle the 
negotiation between PCC and PCE?  Therefore, I am also concerning about this.

I like to hear your voice on this, which object/msg is appropriate to carry the 
info? I am open with other options.

Possible options could be

•  Open message

•  Use PCEP-LS encoding and make this a node attribute

•  New type of notification

•  New message/object

Once we get the conclusion of this, we can go to the bullet 3, which is much 
easier that bullet 2. IMHO, I will prefer to define sub-TLVs one by one, this 
can decouple the relations between IDs, though we may need to delete the 
'generic' words.

Thoughts?
Cheng

___
Pce mailing list -- pce@ietf.org<mailto:pce@ietf.org>
To unsubscribe send an email to pce-le...@ietf.org<mailto:pce-le...@ietf.org>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: IPR poll for draft-ietf-pce-stateful-pce-vendor

[Cheng Li]

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

Thanks,
Cheng


From: Andrew Stone (Nokia) 
Sent: Thursday, July 4, 2024 7:09 PM
To: Cheng Li ; Zhenghaomian ; 
msiva...@gmail.com; ssi...@cisco.com; z...@cisco.com; pce@ietf.org; 
pce-cha...@ietf.org
Subject: IPR poll for draft-ietf-pce-stateful-pce-vendor

Hi Authors,

In preparation for WGLC on this draft, we'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,
Andrew
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

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

[Cheng Li]

Support as a co-author. Comments are welcome, and we will address them ASAP.

Thanks,
Cheng



From: Dhruv Dhody 
Sent: Thursday, July 4, 2024 3:17 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: 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: Where the Controlled ID info shuold be carried/encoded?

[Cheng Li]

Hi Samuel,

Thank you so much for your suggestions. Good input.
Let’s wait for others’ POV.

I also requested for a slot to discuss this, if people do not have the time to 
write some emails.

Thanks,
Cheng


From: Samuel Sidor (ssidor) 
Sent: Friday, June 28, 2024 11:19 AM
To: Cheng Li ; pce@ietf.org
Subject: RE: Where the Controlled ID info shuold be carried/encoded?

Hi Cheng,

Sorry for delayed response.


  1.  PCOpen
I would personally prefer to decouple PCEP session from ID space advertisement 
as there is no logical connection between them, so to me this option seems to 
be least preferred one.

  1.  Use PCEP-LS encoding and make this a node attribute
I’m fine with using PCEP-LS encoding, but ideally without requiring full 
support of PCEP-LS draft as that dependency may be too big for vendors, which 
does not need to support it, but still want to exchange some specific ID space

  1.  New type of notification
  2.  New message/object
I’m fine with both options above, but completely new message type may be 
cleaner approach, ideally with some message type, which can be re-used in the 
future (not too specific for this usecase).

Thanks a lot,
Samuel

From: Cheng Li 
mailto:c.l=40huawei@dmarc.ietf.org>>
Sent: Thursday, June 27, 2024 5:09 PM
To: Cheng Li 
mailto:c.l=40huawei@dmarc.ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] Re: Where the Controlled ID info shuold be carried/encoded?

Echo request 😊

Hope to have your valuable suggestions!

Thanks,
Cheng


From: Cheng Li 
mailto:c.l=40huawei@dmarc.ietf.org>>
Sent: Thursday, June 20, 2024 11:46 AM
To: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] Where the Controlled ID info shuold be carried/encoded?

Hi Guys，

Thank you so much for your helpful review and comments of our draft 
draft-ietf-pce-controlled-id-space.
In the WG adoption, I can summarize our discussion into the below bullets, hope 
they are correct,

  1.  The draft is useful, and the mechanism defined in the draft is needed, we 
should work on it. (Thanks!)
  2.  We need to discuss the where the info should be carried in the PCEP. Open 
Object seems not so good ☹
  3.  TLV encoding should be updated to be more generic or let's avoid the 
generic description and define specific sub-TLVs as needed.

I see the reasons why we decided to carry the info in PCEP Open Object, because 
it is a device-wide configuration info, which should not be modified in the 
running state. We may face a lot of trouble of removing some IDs and then 
modify the range in a running network. However, we may also need to handle the 
negotiation between PCC and PCE?  Therefore, I am also concerning about this.

I like to hear your voice on this, which object/msg is appropriate to carry the 
info? I am open with other options.

Possible options could be

l  Open message

l  Use PCEP-LS encoding and make this a node attribute

l  New type of notification

l  New message/object

Once we get the conclusion of this, we can go to the bullet 3, which is much 
easier that bullet 2. IMHO, I will prefer to define sub-TLVs one by one, this 
can decouple the relations between IDs, though we may need to delete the 
'generic' words.

Thoughts?
Cheng

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Request for 15-20 min of draft-ietf-pce-controlled-id-space-00

[Cheng Li]

Hi WG,

I would like to request for 15-20 mins of slot to present the draft of 
Controlled ID draft.
We need to discuss where is appropriate to carry the info in PCEP. We need a 
slot to track more attention, and hear from the WG before moving forward.

Thanks,
Cheng


___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Where the Controlled ID info shuold be carried/encoded?

[Cheng Li]

Echo request 😊

Hope to have your valuable suggestions!

Thanks,
Cheng


From: Cheng Li 
Sent: Thursday, June 20, 2024 11:46 AM
To: pce@ietf.org
Subject: [Pce] Where the Controlled ID info shuold be carried/encoded?

Hi Guys，

Thank you so much for your helpful review and comments of our draft 
draft-ietf-pce-controlled-id-space.
In the WG adoption, I can summarize our discussion into the below bullets, hope 
they are correct,

  1.  The draft is useful, and the mechanism defined in the draft is needed, we 
should work on it. (Thanks!)
  2.  We need to discuss the where the info should be carried in the PCEP. Open 
Object seems not so good ☹
  3.  TLV encoding should be updated to be more generic or let's avoid the 
generic description and define specific sub-TLVs as needed.

I see the reasons why we decided to carry the info in PCEP Open Object, because 
it is a device-wide configuration info, which should not be modified in the 
running state. We may face a lot of trouble of removing some IDs and then 
modify the range in a running network. However, we may also need to handle the 
negotiation between PCC and PCE?  Therefore, I am also concerning about this.

I like to hear your voice on this, which object/msg is appropriate to carry the 
info? I am open with other options.

Possible options could be

l  Open message

l  Use PCEP-LS encoding and make this a node attribute

l  New type of notification

l  New message/object

Once we get the conclusion of this, we can go to the bullet 3, which is much 
easier that bullet 2. IMHO, I will prefer to define sub-TLVs one by one, this 
can decouple the relations between IDs, though we may need to delete the 
'generic' words.

Thoughts?
Cheng

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Where the Controlled ID info shuold be carried/encoded?

[Cheng Li]

Hi Guys，

Thank you so much for your helpful review and comments of our draft 
draft-ietf-pce-controlled-id-space.
In the WG adoption, I can summarize our discussion into the below bullets, hope 
they are correct,

  1.  The draft is useful, and the mechanism defined in the draft is needed, we 
should work on it. (Thanks!)
  2.  We need to discuss the where the info should be carried in the PCEP. Open 
Object seems not so good ☹
  3.  TLV encoding should be updated to be more generic or let's avoid the 
generic description and define specific sub-TLVs as needed.

I see the reasons why we decided to carry the info in PCEP Open Object, because 
it is a device-wide configuration info, which should not be modified in the 
running state. We may face a lot of trouble of removing some IDs and then 
modify the range in a running network. However, we may also need to handle the 
negotiation between PCC and PCE?  Therefore, I am also concerning about this.

I like to hear your voice on this, which object/msg is appropriate to carry the 
info? I am open with other options.

Possible options could be

l  Open message

l  Use PCEP-LS encoding and make this a node attribute

l  New type of notification

l  New message/object

Once we get the conclusion of this, we can go to the bullet 3, which is much 
easier that bullet 2. IMHO, I will prefer to define sub-TLVs one by one, this 
can decouple the relations between IDs, though we may need to delete the 
'generic' words.

Thoughts?
Cheng

___
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

[Cheng Li]

Thank you Dhruv, yes, we have updated the 00 revision, and been working on the 
comments received in the WG adoption call.
Will send the response to the list accordingly ASAP.

Thanks,
Cheng


From: Dhruv Dhody 
Sent: Tuesday, June 4, 2024 5:43 AM
To: pce@ietf.org
Cc: pce-chairs ; draft-li-pce-controlled-id-sp...@ietf.org
Subject: Re: WG Adoption of draft-li-pce-controlled-id-space-16

Hi WG,

The adoption call is concluded and we have a new WG I-D. Thanks to those who 
provided feedback and comments.

Authors,

Please post a -00 version with no content change. Please handle comments 
received in -01 after discussion on the mailing list.

Thanks!
Dhruv & Julien

On Fri, May 17, 2024 at 12:09 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
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

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

[Cheng Li]

Thank you Samuel for your support and comments, we are working on the replies 
to address the comments received in the WG adoption call.
Will need some time, so please expect some delay.  The reply will be sent to 
our mail list next week 😊

Thanks,
Cheng


From: Samuel Sidor (ssidor) 
Sent: Friday, May 31, 2024 2:16 PM
To: draft-li-pce-controlled-id-sp...@ietf.org
Cc: pce-chairs ; Dhruv Dhody ; 
pce@ietf.org
Subject: RE: [Pce] WG Adoption of draft-li-pce-controlled-id-space-16

Hi authors,

I support adoption of this document.

A few comments/questions:

  *   Is there reason to limit applicability of that draft to SR-MPLS/SRv6 
(e.g. in Section 3.2)? I can imagine that for example BSID allocation may be 
applicable to RSVP-TE LSPs as well
  *   Is it really good idea to use TLVs in Open message to exchange ID space?
 *   There is no capability advertised before that TLV is included (and 
there is no way to do it since Open message is 1st message sent in that PCEP 
session), so when PCC is including it, it does not know whether PCE can support 
it or not. If PCE is responding with Keepalive message, it can mean 2 things 
with no simple way to figure out which of them occurred:
*   ID space control procedure was successful
*   PCE does not support that TLV and ignored it completely
 *   If any of those ranges has changed, then PCEP session flap will be 
required (I assume that those are changing often, so this may be acceptable). 
If any other PCEP message is used, which can be sent on already established 
PCEP session, then it can be modified without requiring PCEP session flap. 
Maybe consider using PCNtf or some completely new PCEP message and in such case 
you can even use explicit capability to indicate whether PCEP extensions from 
this draft are supported or not
  *   Does it make sense to define some sub-type of delegated space? For 
example, if PCC included 3 ranges in “LABEL-CONTROL-SPACE TLV”, then there can 
be some registry of types to specify that 1st range is for BSID, 2nd one for 
SRGB or SRLB,… How PCE should know which range is supposed to be used for what 
purpose? (I can imagine that for SRGB, SRLB, it can be derived from complete 
SRGB/SRLB range learned from IGP, but such approach probably cannot be used for 
all ranges).
  *   Maybe consider renaming “Block” field in “LABEL-CONTROL-SPACE TLV” to 
something like “Number of blocks” (see for example PST capability TLV in 
https://www.rfc-editor.org/rfc/rfc8408.html#section-3) or even potentially drop 
that field completely as number of ranges can be derived from TLV length
  *   In section 6, you pointed out that synchronization mechanism should be 
used if same label ranges were allocated for multiple PCEs, but it would be 
good to specify details how state-sync will solve synchronization issue (if PCC 
is connected to both PCEs, then both PCEs should see already allocated labels 
from PCRpt messages directly from PCC)
  *   One small type in section 1 “This documnet adds t…””

Thanks,
Samuel

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Friday, May 17, 2024 1:10 PM
To: pce@ietf.org
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
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

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

[Cheng Li]

Hi PCE,

I support the adoption as an author. This is a straightforward and useful 
extension for PCE-initiated scenarios.
I will work on the draft after the draft is adopted for sure 😊

Thanks,
Cheng


From: Dhruv Dhody 
Sent: Friday, May 17, 2024 1:10 PM
To: pce@ietf.org
Cc: pce-chairs ; draft-li-pce-controlled-id-sp...@ietf.org
Subject: 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

[Pce] Re: IPR poll for draft-li-pce-controlled-id-space

[Cheng Li]

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

Thanks,
Cheng


From: Andrew Stone (Nokia) 
Sent: Friday, May 17, 2024 9:19 PM
To: Dhruv Dhody ; Mach Chen ; 
Lizhenbin ; Dongjie (Jimmy) ; Cheng 
Li ; Shihang(Vincent) ; 
wang...@chinatelecom.cn; chengweiqi...@chinamobile.com; chaozhou...@yahoo.com; 
pce@ietf.org; pce-cha...@ietf.org
Subject: IPR poll for draft-li-pce-controlled-id-space

Hi Authors,

In preparation for WG adoption on this draft, we'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,
Andrew
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

Re: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-optional

[Cheng Li]

Thank you Dhruv, the update looks good to me. We have updated the draft already!



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



There is also an HTMLized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-optional-09



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-optional-09

Respect,
Cheng


From: Dhruv Dhody 
Sent: Tuesday, April 9, 2024 7:22 PM
To: Cheng Li 
Cc: draft-ietf-pce-stateful-pce-optio...@ietf.org; pce@ietf.org; pce-chairs 

Subject: Shepherd review of draft-ietf-pce-stateful-pce-optional

Hi Authors,

I have completed my shepherd review. I have gone ahead and made some minor 
edits directly in the XML source. Please verify them and if acceptable, go 
ahead and post a new version. Once the new version is posted, we will ship it 
to the IESG.

I have also made RFC 8253 and RFC 8281 as Normative references.

Diff: 
https://author-tools.ietf.org/diff?doc_1=draft-ietf-pce-stateful-pce-optional-08&url_2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-pce-optional-09.txt
XML for -09: 
https://github.com/dhruvdhody/ietf/blob/master/draft-ietf-pce-stateful-pce-optional-09.xml
Shepherd Report: https://notes.ietf.org/iL9ZlJF-TaGgYVYU0mXrwg?view

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

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li]

Hi Shaofu,

Sorry for my delay. Yes, you are correct! We have updated the draft to fix this 
typo.

Thank you so much!
Cheng



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



There is also an HTMLized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-optional-09



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-optional-09


From: peng.sha...@zte.com.cn 
Sent: Friday, March 22, 2024 9:16 AM
To: Cheng Li 
Cc: pce@ietf.org; pce-cha...@ietf.org; 
draft-ietf-pce-stateful-pce-optio...@ietf.org; d...@dhruvdhody.com
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07




Hi Cheng,



Thanks for your response.



For the objects of intended-attribute-list and actual-attribute-list, I didn't 
treat them as mandatory ones. But just think that the document should also give 
some guidance text on those non mandatory objects. However, I don't insist on 
this point. Perhaps without this guidance, developers can handle it correctly.



BTW, I notice the updated version(08) section "3.2.2.  The PCUpd Message and 
the PCInitiate Message" may have a spelling mistake:

... ... ignored by the PCE or the object itself conveys informational ... ...

should PCE => PCC ?



Regards,

PSF








Original
From: ChengLi mailto:c...@huawei.com>>
To: 彭少富10053815;
Cc: pce@ietf.org<mailto:pce@ietf.org> 
mailto:pce@ietf.org>>;pce-cha...@ietf.org 
mailto:pce-cha...@ietf.org>>;draft-ietf-pce-stateful-pce-optio...@ietf.org
 
mailto:draft-ietf-pce-stateful-pce-optio...@ietf.org>>;Dhruv
 Dhody mailto:d...@dhruvdhody.com>>;
Date: 2024年03月13日 11:35
Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07
Hi Shaofu,

Many thanks for your supports and comments.

Please see our reply below.

Thanks,
Cheng



On Fri, Mar 1, 2024 at 12:25 PM 
mailto:peng.sha...@zte.com.cn>> wrote:



Hi Chairs, WG,



I have read this document and find it is useful and support its forwarding.

Please see some comments as below:



[1]

In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that



"When the PCEP session is established, a PCC sends an Open message with an OPEN 
object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]."



This mislead us to understand it is after the session established. May change to



"During the PCEP initialization phase, ..."



[Cheng]Thanks! This is a good suggestion!



or change to

"When the TCP connection is established, ..."



[2]

In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that



"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that 
the PCEP Speaker is willing to send and receive PCEP objects with the P and I 
flags in the PCEP common object header for the stateful PCE messages."



This sentence is not clear because the P and I flags fields are already 
included in the PCEP objects. May change to



"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that 
the PCEP Speaker is willing to handle the P and I flags in the PCEP common 
object header for the stateful PCE messages."



[Cheng]Another good suggestion.



[3]

For seciton 3.2.1. The PCRpt Message, it emphasizes that the P flag of 
mandatory object must be set. It may be more meaningful to provide guidance on 
the setting of the P flag for each object in intended-attribute-list and 
actual-attribute-list, that actually contain the constraints (e.g, bandwidth, 
metric) used for path computation .



[Cheng] Note that all the objects in both the intended-attribute-list and 
actual-attribute-list are optional as per the RBNF and thus would be incorrect 
to club them with mandatory objects.
Overall I don't think we can add any specifics. We can add an example but I am 
unsure how useful that is.



[4]

In 3.3.1. The PCUpd Message, it said that



"Note that when a PCE is unable to find the path that meets all the constraints 
as per the PCEP Object that cannot be ignored (i.e. P flag is set), the PCUpd 
message MAY optionally include the PCEP Objects that caused the path 
computation to fail along with the with the empty ERO."



"with the" in this paragraph is repeated.

[Cheng]Thanks!



Do you think that this paragraph should be moved to section 3.2.1 The PCRpt 
Message ? It seems actually to describe the procesing of P flag in PCRpt. If 
so, may changed to



[Cheng] No, we are following the format as set by RFC 5440 where this is 
described under the handling of I flag. Thus I would leave this unchanged.



"Note that when a PCE is unable to find the path that meets all the constraints 
as per the PCEP Object (carried in PCRpt message) that cannot be ignored (i.e. 
P flag is set), the subsequent PCUpd message MAY optionally include the PCEP 
Objects that caused the path c

Re: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls

[Cheng Li]

This is an important extension, and the content is well written, I support the 
adoption. Hope more people can work on it more critical when it becomes an WG 
draft.

Thanks,
Cheng


-Original Message-
From: Pce  On Behalf Of Pengshuping (Peng Shuping)
Sent: Friday, April 12, 2024 9:23 AM
To: julien.meu...@orange.com; pce@ietf.org
Subject: Re: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls

Hi Julien, 

I support the WG adoption of this work. It has been a long time since this work 
was started. It is an useful experiment. It would be good if the WG adopts it 
and progresses it further, especially helps with the IANA issues as Adrian 
pointed out. 

Thank you! 

Best Regards,
Shuping 


-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Friday, April 5, 2024 12:19 AM
To: pce@ietf.org
Subject: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls

Hi all,

We have a long history around PCEP-LS. The rough consensus has been to progress 
it as experimental within the PCE WG, which makes more sense than an 
independent submission.
As a result, do you support draft-dhodylee-pce-pcep-ls-27 [1] to become a PCE 
WG document? Please share your feedback using the PCE mailing list, including 
your comments and especially your rationales in case you're opposed.

Thank you,

Julien

---
[1] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/

___
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 for draft-dhodylee-pce-pcep-ls

[Cheng Li]

Hi Andrew,

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

Thanks,
Cheng


From: Pengshuping (Peng Shuping) 
Sent: Monday, April 8, 2024 9:35 AM
To: Daniele Ceccarelli ; Andrew Stone (Nokia) 

Cc: Dhruv Dhody ; younglee...@gmail.com; Aijun Wang 
; gyan.s.mis...@verizon.com; ssiva...@ciena.com; 
udayasreere...@gmail.com; Sergio Belotti (Nokia) ; 
satish karunanithi ; Cheng Li ; 
pce@ietf.org; pce-cha...@ietf.org
Subject: RE: IPR poll for draft-dhodylee-pce-pcep-ls

Hi Andrew,

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

BR,
Shuping

From: Daniele Ceccarelli [mailto:daniele.i...@gmail.com]
Sent: Monday, April 8, 2024 3:33 PM
To: Andrew Stone (Nokia) mailto:andrew.st...@nokia.com>>
Cc: Dhruv Dhody mailto:dhruv.i...@gmail.com>>; 
Pengshuping (Peng Shuping) 
mailto:pengshup...@huawei.com>>; 
younglee...@gmail.com<mailto:younglee...@gmail.com>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; 
gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>; 
ssiva...@ciena.com<mailto:ssiva...@ciena.com>; 
udayasreere...@gmail.com<mailto:udayasreere...@gmail.com>; Sergio Belotti 
(Nokia) mailto:sergio.belo...@nokia.com>>; satish 
karunanithi 
mailto:satish.karunani...@gmail.com>>; Cheng Li 
mailto:c...@huawei.com>>; pce@ietf.org<mailto:pce@ietf.org>; 
pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
Subject: Re: IPR poll for draft-dhodylee-pce-pcep-ls

Hi Andrew,

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

Thanks
Daniele

Il Ven 5 Apr 2024, 17:14 Andrew Stone (Nokia) 
mailto:andrew.st...@nokia.com>> ha scritto:
Hi Authors,
In preparation for WG adoption on this draft, we'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,
Andrew
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)

[Cheng Li]

Thank you Eric for your reply!

Respect,
Cheng


From: Eric Vyncke (evyncke) 
Sent: Friday, April 5, 2024 11:21 AM
To: Cheng Li ; Dhruv Dhody 
Cc: The IESG ; draft-ietf-pce-segment-routing-i...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; hariharan.i...@gmail.com; rthal...@gmail.com
Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)

Hello Cheng and Dhruv,

Thanks a lot for all the explanations and the revised I-D.

I sincerely think that the document has been improved with those changes.

Regards

-éric

From: Cheng Li mailto:c...@huawei.com>>
Date: Thursday, 4 April 2024 at 17:45
To: Dhruv Dhody mailto:d...@dhruvdhody.com>>, Eric Vyncke 
(evyncke) mailto:evyn...@cisco.com>>
Cc: The IESG mailto:i...@ietf.org>>, 
draft-ietf-pce-segment-routing-i...@ietf.org<mailto:draft-ietf-pce-segment-routing-i...@ietf.org>
 
mailto:draft-ietf-pce-segment-routing-i...@ietf.org>>,
 pce-cha...@ietf.org<mailto:pce-cha...@ietf.org> 
mailto:pce-cha...@ietf.org>>, 
pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>, 
hariharan.i...@gmail.com<mailto:hariharan.i...@gmail.com> 
mailto:hariharan.i...@gmail.com>>, 
rthal...@gmail.com<mailto:rthal...@gmail.com> 
mailto:rthal...@gmail.com>>
Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)
Thanks Eric and Dhruv for your comments.

Please see my reply inline.
We also updated the drat accordingly to address your comments, please check,


HTML: 
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-25.html

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6

Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-25

Thanks,
Cheng


From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Thursday, April 4, 2024 8:14 AM
To: Éric Vyncke mailto:evyn...@cisco.com>>
Cc: The IESG mailto:i...@ietf.org>>; 
draft-ietf-pce-segment-routing-i...@ietf.org<mailto:draft-ietf-pce-segment-routing-i...@ietf.org>;
 pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>; 
pce@ietf.org<mailto:pce@ietf.org>; 
hariharan.i...@gmail.com<mailto:hariharan.i...@gmail.com>; 
rthal...@gmail.com<mailto:rthal...@gmail.com>
Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)

Hi Éric,

On Thu, Apr 4, 2024 at 12:53 AM Éric Vyncke via Datatracker 
mailto:nore...@ietf.org>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-pce-segment-routing-ipv6-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/



--
COMMENT:
--


# Éric Vyncke, INT AD, comments for draft-ietf-pce-segment-routing-ipv6-23

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Hariharan Ananthakrishnan for the shepherd's write-up
including the WG consensus and the justification of the intended status.

Other thanks to Bob Halley, the Internet directorate reviewer (at my request):
https://datatracker.ietf.org/doc/review-ietf-pce-segment-routing-ipv6-22-intdir-telechat-halley-2024-02-24/
(Bob found no issue)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Title

The title is rather long, should it rather use "IPv6 Segment Routing"
[Cheng]Ack
## Abstract

Like other IESG members, I find the abstract convoluted, i.e., please be
straight to the point and focus on SRv6 and PCEP, e.g., no need to mention LDP
in the abstract.
[Cheng]Ack.

## Section 1

The second paragraph is rather useless, with another mention of SR-MPLS in a
SRv6 document. The 3rd paragraph is not that useful either.

4th and 5th paragraphs could be used during the WG call for adoption, but have
little to do in a SRv6-related document. Please really consider to change this
section.

Dhruv: I see your point for the 2nd and 3rd paragraph. For 4th and 5th, it is 
important to highlight what is the base set of specifications over which this 
extension is built.
[Cheng]I am ok with deleting the 2nd and 3rd paragraph, though I think they may 
be helpful for some readers who are not familiar with SR. But it i

Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)

[Cheng Li]

Thanks Eric and Dhruv for your comments.

Please see my reply inline.
We also updated the drat accordingly to address your comments, please check,


HTML: 
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-25.html

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6

Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-25

Thanks,
Cheng


From: Dhruv Dhody 
Sent: Thursday, April 4, 2024 8:14 AM
To: Éric Vyncke 
Cc: The IESG ; draft-ietf-pce-segment-routing-i...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; hariharan.i...@gmail.com; rthal...@gmail.com
Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)

Hi Éric,

On Thu, Apr 4, 2024 at 12:53 AM Éric Vyncke via Datatracker 
mailto:nore...@ietf.org>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-pce-segment-routing-ipv6-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/



--
COMMENT:
--


# Éric Vyncke, INT AD, comments for draft-ietf-pce-segment-routing-ipv6-23

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Hariharan Ananthakrishnan for the shepherd's write-up
including the WG consensus and the justification of the intended status.

Other thanks to Bob Halley, the Internet directorate reviewer (at my request):
https://datatracker.ietf.org/doc/review-ietf-pce-segment-routing-ipv6-22-intdir-telechat-halley-2024-02-24/
(Bob found no issue)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Title

The title is rather long, should it rather use "IPv6 Segment Routing"
[Cheng]Ack
## Abstract

Like other IESG members, I find the abstract convoluted, i.e., please be
straight to the point and focus on SRv6 and PCEP, e.g., no need to mention LDP
in the abstract.
[Cheng]Ack.

## Section 1

The second paragraph is rather useless, with another mention of SR-MPLS in a
SRv6 document. The 3rd paragraph is not that useful either.

4th and 5th paragraphs could be used during the WG call for adoption, but have
little to do in a SRv6-related document. Please really consider to change this
section.

Dhruv: I see your point for the 2nd and 3rd paragraph. For 4th and 5th, it is 
important to highlight what is the base set of specifications over which this 
extension is built.
[Cheng]I am ok with deleting the 2nd and 3rd paragraph, though I think they may 
be helpful for some readers who are not familiar with SR. But it is ok to 
delete.
I am not really sure of the long history in PCE WG, but for most of the RFCs in 
the WG, they explains the dependent RFCs/Tech in a detailed way, which can help 
readers to understand the logic and the base of this RFC. I will suggest to 
keep them.


## Section 2

Consider adding a reference to the SRH RFC.

## Section 3

Is `subobject` term well-defined ? Honestly, I never read this term before and
even if I can *guess* the meaning, it may be worth adding it to the terminology
section.

Dhruv: They go back to the base specification of PCEP in RFC 5440 as well as 
RSVP-TE in RFC 3209 and thus are well known and understood.  One can add this 
sentence to make it clear - "In PCEP messages,route information is carried in 
the Explicit Route Object (ERO), which consists of a sequence of subobjects."
[Cheng]agree with the modification.


## Section 3.1

I have *very hard* time to understand what is meant by `When SR-MPLS is used
with an IPv6 network` to be honest. I was about to ballot a blocking DISCUSS on
this point, but I assume that I simply lack the PCEP context. May I
***REQUEST*** some explanations here ?

Dhruv: I suggested that text based on Jim's comment. Maybe you can help with 
wordsmithing this :)
In an IPv6-only network that uses SR-MPLS, the SR related information in the 
IGP/BGP will use an IPv6 address and the data-plane would use MPLS. In this 
case, for PCEP the RFC 8664 (SR-MPLS extension) is sufficient and there is no 
role of SRv6 here.

Would the term "IPv6-enabled networks (IPv6-only or Dual-stack networks)" be 
better?
[Cheng]Though I know what you are saying here, but I will rather remove this 
paragraph, because it is not so needed at all. Regarding using SR-MPLS in an 
IPv6 netw

Re: [Pce] Gunter Van de Velde's No Objection on draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT)

[Cheng Li]

Hi Gunter,

Please review the update, hope it can address your comments.

HTML: 
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-24.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-24


Thanks,
Cheng

Also, pasted the cut email of the reply from Dhruv below, please see my further 
reply inline.
==
 
143[RFC8231] specifies extensions to PCEP that allow a stateful PCE to
144compute and recommend network paths in compliance with [RFC4657] and
145defines objects and TLVs for MPLS-TE LSPs.  Stateful PCEP extensions

I am unclear what 'recommend' means in this context? Can this be better
explained and clarified? In RFC8231 there is no mentioning of recommended paths.

Dhruv: In RFC 8231 you will note "LSP Update Request" i.e. PCE is requesting 
the PCC to update and PCC can report that the update is rejected. Also RFC 8664 
uses similar framing. This could be updated to "compute and update" but it then 
loses the point that the PCC is free to reject. I will let this be...  
[Cheng]I am ok with let it be now. Gunter please see if this is ok for you.
 

157account various constraints and objective functions.  Once a path is
158chosen, the stateful PCE can initiate an SR-TE path on a PCC using
159PCEP extensions specified in [RFC8281] and the SR-specific PCEP

“Once a path is chosen” seems to imply that there are multiple paths calculated
and the best one is selected or chosen. Is this what is implied with this?

Dhruv: Yes, 'computed' is better than 'chosen'! 
[Cheng]Done, see modifications.
 
161extensions for supporting a SR-TE LSP for the MPLS data plane.  This
162document extends [RFC8664] to support SR for the IPv6 data plane.
163Additionally, using procedures described in this document, a PCC can
164request an SRv6 path from either a stateful or stateless PCE.  This
165specification relies on the PATH-SETUP-TYPE TLV and procedures
166specified in [RFC8408].

This section is explaining what this draft is standardizing. It is a bit hidden
and tucked all the way in the back of the introduction, a bit less trivial for
the reader to discover.

Dhruv: This can be put in its own paragraph.
[Cheng]no comment here
 
168This specification provides a mechanism for a network controller
169(acting as a PCE) to instantiate candidate paths for an SR Policy
170onto a head-end node (acting as a PCC) using PCEP.  For more

Before there was mentioning of a “network planning tool”. Maybe instead the
term network controller can be used?

Dhruv: agree
[Cheng]Agree

 
212Basic operations for PCEP speakers are as per [RFC8664].  SRv6 Paths
213computed by a PCE can be represented as an ordered list of SRv6
214segments

Reading this gives wrong indication that RFC8664 computes SRv6 paths. In the
RFC8664 is explicitly written that “This document is relevant to the MPLS
forwarding plane only.”

Dhruv: maybe "built on" instead of "as per". 
[Cheng]No problem

 
250In SR networks, an SR source node encodes all packets being steered
251onto an SR path with a list of segments.

“SR source node”. I am unsure what this refers towards. Would this be the
segment routing ingress node? In Segment Routing (SR), the ingress node is
known by the fact that it is the node where the packet enters the Segment
Routing domain. When a packet enters a network that employs Segment Routing, it
is typically tagged with a Segment List at the ingress node.

Dhruv: RFC 8754 and RFC 8986 use the term. Maybe we can reframe this as - 

"In SR networks, an SR source node [RFC8754] steers a packet into an SR Policy 
resulting in a segment list."

 
 363   order to indicate that the path is for SRv6, any RP or SRP object

These acronyms are not specified in the terminology section: Request Parameters
(RP) [RFC5440] and the Stateful PCE Request Parameters (SRP)

Dhruv: They are expanded on first use in section 3.2
[Cheng] Gunter's proposal looks good to me.

 
398The 'L' Flag: Indicates whether the subobject represents a loose-hop
399(see [RFC3209]).  If this flag is set to zero, a PCC MUST NOT
400overwrite the SID value present in the SRv6-ERO subobject.
401Otherwise, a PCC MAY expand or replace one or more SID values in the
402received SRv6-ERO based on its local policy.

The exact meaning of L-flag is confusing for SRv6. When looking at RFC3209 it
reflects upon nodes, however with SRv6 this may be an adj-SID or some other
instruction. Maybe the L-flag can be enhanced to described what this means in
the context of SRv6 SID.

Dhruv: The text is the same as RFC 8664 (SR-MPLS) and within the context of 
PCEP it means that PCC should use the SID as it is v/s PCC being able to apply 
suitable 

Re: [Pce] Gunter Van de Velde's No Objection on draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT)

[Cheng Li]

Seems the email is cut due to some reasons ☹

I will update the draft to address Gunter's email. Please check @Gunter Van de 
Velde

Thanks,
Cheng



-Original Message-
From: Cheng Li  
Sent: Wednesday, April 3, 2024 12:00 PM
To: Dhruv Dhody ; Gunter Van de Velde 

Cc: The IESG ; draft-ietf-pce-segment-routing-i...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; hariharan.i...@gmail.com
Subject: RE: Gunter Van de Velde's No Objection on 
draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT)

Hi Dhruv, and Gunter, 

Thank you for your comments. Please see my reply inline, will update the draft 
accordingly soon.

Thanks,
Cheng


-Original Message-
From: Dhruv Dhody 
Sent: Wednesday, April 3, 2024 11:41 AM
To: Gunter Van de Velde 
Cc: The IESG ; draft-ietf-pce-segment-routing-i...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; hariharan.i...@gmail.com
Subject: Re: Gunter Van de Velde's No Objection on 
draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT)

Hi Gunter,

Thanks for a detailed review.

On Tue, Apr 2, 2024 at 10:49 PM Gunter Van de Velde via Datatracker < 
nore...@ietf.org> wrote:

> Gunter Van de Velde has entered the following ballot position for
> draft-ietf-pce-segment-routing-ipv6-22: No Objection
>
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-posi
> tions/ for more information about how to handle DISCUSS and COMMENT 
> positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/
>
>
>
> --
> COMMENT:
> --
>
> Please find this review using a fresh pair of eyes upon the draft. 
> feel free to use or ignore these comments. Comments are ordered with 
> some first set of idnit typo's, followed with observations when 
> reading the document.
>
> **Idnits:**
>
> 349Endpoint node as well as the tailend node also need to be
> considered
>
> I believe that the grammatically correct form is "tail-end," which 
> refers to the final part of something, such as a process, activity, or 
> physical object.
> Using a hyphen clarifies that the two words function together as a 
> single concept. Not sure if there is earlier art that uses the term 
> with the proposed spelling in the document?
>
>
Dhruv: I checked; authors - please change to tail-end!
[Cheng]Ack, no problem.


> 659PCE.  As such,the flags MUST be set to zero and a (MSD-Type,MSD-
>
> s/such,the/such, the/
>
> 635mechanisms, e.g routing protocols [RFC9352], then it ignores the
>
> s/e.g/e.g./
>
> 653SRv6 MSD capabilties, the PCC MUST send a PCErr message with
> Error-
>
> s/capabilties/capabilities/
>
>
Dhruv: Ack for above!
[Cheng]Ack.



> **Observations when reading through the document:**
>
> 20 Segment Routing (SR) can be used to steer packets through an
> IPv6 or
> 21 MPLS network using the source routing paradigm.  SR enables any
> head-
> 22 end node to select any path without relying on a hop-by-hop
> signaling
> 23 technique (e.g., LDP or RSVP-TE).
>
> Proposed rewrite
> Segment Routing (SR) can be used to steer packets through a network 
> using the
> IPv6 or MPLS data plane, employing the source routing paradigm. SR 
> enables any head-end node to select any path without relying on 
> hop-by-hop signaling techniques (e.g., LDP or RSVP-TE).
>
>
Dhruv: Thanks for the rewrite, it reads better!
[Cheng] No problem


> 29 Since SR can be applied to both MPLS and IPv6 forwarding
> planes, a
> 30 PCE should be able to compute an SR Path for both MPLS and IPv6
> 31 forwarding planes.
>
> I suspect we are talking dataplane instead of forwarding plane? I see 
> the terms "forwarding plane" and "data plane" often used 
> interchangeably, but they do seem to have nuanced differences. The 
> forwarding plane deals with the logical decision-making process of 
> packet forwarding, the data plane deals with the physical 
> implementation of forwarding those packets based on those decisions.
> In addition the term dataplane is used later in this same abstract. 
> Maybe best to use single terminology (maybe dataplane) through the 
> document?
>
>
Dhruv: Looking at spring RFCs I see a mix of terms but when talking about SR 
instantiation as SR-MPLS and SRv6, the term data-plane

Re: [Pce] Gunter Van de Velde's No Objection on draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT)

[Cheng Li]

Hi Dhruv, and Gunter, 

Thank you for your comments. Please see my reply inline, will update the draft 
accordingly soon.

Thanks,
Cheng


-Original Message-
From: Dhruv Dhody  
Sent: Wednesday, April 3, 2024 11:41 AM
To: Gunter Van de Velde 
Cc: The IESG ; draft-ietf-pce-segment-routing-i...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; hariharan.i...@gmail.com
Subject: Re: Gunter Van de Velde's No Objection on 
draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT)

Hi Gunter,

Thanks for a detailed review.

On Tue, Apr 2, 2024 at 10:49 PM Gunter Van de Velde via Datatracker < 
nore...@ietf.org> wrote:

> Gunter Van de Velde has entered the following ballot position for
> draft-ietf-pce-segment-routing-ipv6-22: No Objection
>
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-posi
> tions/ for more information about how to handle DISCUSS and COMMENT 
> positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/
>
>
>
> --
> COMMENT:
> --
>
> Please find this review using a fresh pair of eyes upon the draft. 
> feel free to use or ignore these comments. Comments are ordered with 
> some first set of idnit typo's, followed with observations when 
> reading the document.
>
> **Idnits:**
>
> 349Endpoint node as well as the tailend node also need to be
> considered
>
> I believe that the grammatically correct form is "tail-end," which 
> refers to the final part of something, such as a process, activity, or 
> physical object.
> Using a hyphen clarifies that the two words function together as a 
> single concept. Not sure if there is earlier art that uses the term 
> with the proposed spelling in the document?
>
>
Dhruv: I checked; authors - please change to tail-end!
[Cheng]Ack, no problem.


> 659PCE.  As such,the flags MUST be set to zero and a (MSD-Type,MSD-
>
> s/such,the/such, the/
>
> 635mechanisms, e.g routing protocols [RFC9352], then it ignores the
>
> s/e.g/e.g./
>
> 653SRv6 MSD capabilties, the PCC MUST send a PCErr message with
> Error-
>
> s/capabilties/capabilities/
>
>
Dhruv: Ack for above!
[Cheng]Ack.



> **Observations when reading through the document:**
>
> 20 Segment Routing (SR) can be used to steer packets through an
> IPv6 or
> 21 MPLS network using the source routing paradigm.  SR enables any
> head-
> 22 end node to select any path without relying on a hop-by-hop
> signaling
> 23 technique (e.g., LDP or RSVP-TE).
>
> Proposed rewrite
> Segment Routing (SR) can be used to steer packets through a network 
> using the
> IPv6 or MPLS data plane, employing the source routing paradigm. SR 
> enables any head-end node to select any path without relying on 
> hop-by-hop signaling techniques (e.g., LDP or RSVP-TE).
>
>
Dhruv: Thanks for the rewrite, it reads better!
[Cheng] No problem


> 29 Since SR can be applied to both MPLS and IPv6 forwarding
> planes, a
> 30 PCE should be able to compute an SR Path for both MPLS and IPv6
> 31 forwarding planes.
>
> I suspect we are talking dataplane instead of forwarding plane? I see 
> the terms "forwarding plane" and "data plane" often used 
> interchangeably, but they do seem to have nuanced differences. The 
> forwarding plane deals with the logical decision-making process of 
> packet forwarding, the data plane deals with the physical 
> implementation of forwarding those packets based on those decisions.
> In addition the term dataplane is used later in this same abstract. 
> Maybe best to use single terminology (maybe dataplane) through the 
> document?
>
>
Dhruv: Looking at spring RFCs I see a mix of terms but when talking about SR 
instantiation as SR-MPLS and SRv6, the term data-plane is used and thus we 
should also use the same.
[Cheng]Ack



> 31 forwarding planes.  The PCEP extension and mechanisms to
> support SR-
> 32 MPLS have been defined.
>
> What about adding the reference to RFC5440?
>

Dhruv: I would avoid adding references in the abstract.
[Cheng]I agree with Dhruv of this


>
> 32 MPLS have been defined.  This document describes the extensions
> 33 required for SR support for the IPv6 data plane in the Path
> 34 Computation Element communication Protocol (PCEP).
>
> This text reads a bit odd. What about a readability rewrite:
> “This document outlines the necessary extensions to support Segment 
> Routing
> (SR) for the IPv6 data plane within the Path Computation Element 
> Communication Protocol (PCEP).”
>
>
Dhruv: Ack, with slight modification as

Re: [Pce] Jim Guichard's No Objection on draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT)

[Cheng Li]

Thank you Dhruv for proposing the text, and Jim for your comments.

We have updated the draft accordingly, please see the update below.

Thanks,
Cheng



From: James Guichard 
Sent: Tuesday, April 2, 2024 1:41 PM
To: Dhruv Dhody 
Cc: The IESG ; draft-ietf-pce-segment-routing-i...@ietf.org; 
h...@netflix.com; pce@ietf.org; pce-cha...@ietf.org
Subject: Re: [Pce] Jim Guichard's No Objection on 
draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT)

Thanks Dhruv that certainly reads better.

Jim

Get Outlook for iOS

From: Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Sent: Tuesday, April 2, 2024 2:51:54 AM
To: James Guichard 
mailto:james.n.guich...@futurewei.com>>
Cc: The IESG mailto:i...@ietf.org>>; 
draft-ietf-pce-segment-routing-i...@ietf.org
 
mailto:draft-ietf-pce-segment-routing-i...@ietf.org>>;
 h...@netflix.com 
mailto:h...@netflix.com>>; pce@ietf.org 
mailto:pce@ietf.org>>; 
pce-cha...@ietf.org 
mailto:pce-cha...@ietf.org>>
Subject: Re: [Pce] Jim Guichard's No Objection on 
draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT)

Hi Jim,

On Mon, Apr 1, 2024 at 6:06 PM Jim Guichard via Datatracker 
mailto:nore...@ietf.org>> wrote:
Jim Guichard has entered the following ballot position for
draft-ietf-pce-segment-routing-ipv6-22: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/



--
COMMENT:
--

Thank you for a well written document. Minor nit:

Section 3.1 - 2nd Paragraph. Please review this paragraph as it seems to say
that the MPLS mechanisms remain unchanged, but the text is difficult to parse.
Please make the meaning clear.

Yes, I can see that. The text aimed to clarify that in the case IPv6 is used 
(instead of IPv4) for SR-MPLS, the PCEP procedures are as per RFC 8664 and not 
this document.

How is this change ->

OLD:

   For the use of an IPv6 control plane but an MPLS data plane,

   mechanism remains the same as specified in [RFC8664].



   This document describes the extension to support SRv6 in PCEP.

NEW:

   When SR-MPLS is used with an IPv6 network, the PCEP procedures and

   mechanisms are as specified in [RFC8664].

   When SR leverages the IPv6 forwarding plane (i.e. SRv6), the PCEP

   procedures and mechanisms are extended in this document.
END

Thanks!
Dhruv




___
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] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li]

Thank you Chairs! We will update the draft according to the discussion in the 
Mailing list and post it when the window is reopen.

Best Regards,
Cheng


From: Dhruv Dhody 
Sent: Saturday, March 16, 2024 10:22 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: Re: WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

The WGLC is closed. Thanks for everyone's comments and feedback. The I-D is on 
agenda for IETF 119 to discuss the resolution for comments received.

The authors should update the draft based on the comment received and we will 
take the draft forward.

Thanks!
Dhruv & Julien

On Thu, Mar 7, 2024 at 8:21 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

Considering this is a busy time just before the IETF meeting, we are extending 
the WGLC for a week. Please respond by Thursday March 14th. It is important to 
be explicitly vocal during the last call and we request you to please respond 
to this thread.

Thanks!
Dhruv

On Wed, Feb 21, 2024 at 3:02 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li]

Hi Samuel,

Many thanks for your quick review and support,.
Please see our reply below.

BTW, we post the proposed update to address your comments and Shaofu’s comments 
in Github:  https://github.com/muzixing/draft-ietf-pce-stateful-pce-optional

Thanks,
Cheng


From: Samuel Sidor (ssidor) 
Sent: Tuesday, March 12, 2024 11:00 PM
To: draft-ietf-pce-stateful-pce-optio...@ietf.org
Cc: pce-chairs ; pce@ietf.org; Dhruv Dhody 

Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi authors of this draft,

I support this draft, but I still have a few minor comments:

1.Introduction section:

  *   “Generalzied MPLS (GMPLS) tunnels.” -> typo
[Cheng]Ack.

  *   “…allow a PCC to specify in a Path Computation Request (PCReq) message 
(sent to a PCE) whether the object must be taken into account by the PCE during 
path computation or is optional” -> do we even need to specify that PCReq is 
sent to PCE?
[Cheng] I don’t see any harm .


2.1 Usage Example section:

  *   Is really “Disjoint Association” good example as that constraint itself 
has T flag defined in 
https://www.rfc-editor.org/rfc/rfc8800.html#name-disjoint-tlvs, which is 
allowing relaxing disjointness constraint completely as well (so P=0 for 
association object is not really required for that specific case) Maybe 
consider using some other constraint as an example, why we need this.
[Cheng] A good point! I think we can remove the association example itself for 
simplicity's sake.


3.1 STATEFUL-PCE-CAPABILITY TLV section

  *   “In case the bit is unset, it indicates that the PCEP Speaker would not 
handle the P and I flags in the PCEP common object header for stateful PCE 
messages” – At least “Introduction” section is saying that behavior was not 
defined before this draft was written for older PCEP objects in Stateful 
messages, so isn’t it actually required to fallback to original “undefined” 
behavior if flag is not set instead of doing fallback to “PCEP peer is not 
using them”? We should probably have some “backward compatibility” section as 
we don’t have simple way to figure out whether flag is explicitly cleared or 
just not supported.

[Cheng]  No, the introduction says -
   Stateful PCE
   [RFC8231] specified that the P and I flags of the PCEP objects
   defined in [RFC8231] is to be set to zero on transmission and ignored
   on receipt, since they are exclusively related to path computation
   requests.

Maybe the word 'clarify' later on is misleading and I have changed that 
everywhere!

Since the behavior is not undefined any legacy implementation will always 
ignore it and with the help of this flag in capability exchange we can be sure 
that there is no backward compatibility issue.



3.2.2 The PCUpd Message and the PCInitiate Message

  *   Is it really required to assume P flag set to all PCEP objects in 
PCUpd/PCinit messages? Consider PCE including for example accumulated metric or 
constraints used in the path-computation for policies configured on PCC – why 
PCC would need to support all of those objects even if really just 
“SRP/LSP/ERO” is really required in most of the cases? I would say that even 
“SHOULD” may be too strong here.

[Cheng]  I can soften this to say - "On a PCEP session on which R bit was set 
by both peers, the PCE SHOULD set the P flag by default, unless a local 
configuration/policy indicates that some constraints (corresponding PCEP 
objects) can be marked as optional and could be ignored by the PCE or the 
object itself conveys informational parameters that can be safely ignored."


3.4 Delegation

  *   “Note that for the delegated LSPs, the PCE can update and mark some 
objects as ignored even when the PCC had set the P flag during delegation. 
Similarly, the PCE can update…” – Is there valid use-case for this behavior? At 
least to me it seems that it actually opening doors for bugs/misinterpretation 
rather than really adding any value.
[Cheng] There was feedback for this to keep it aligned with the definition of 
delegation in RFC 8231 where PCE ought to have control over all parameters 
including this relaxation.


7.1 Control of Function and Policy

  *   “An operator MUST be allowed to configure the capability to support 
relaxation of constraints in the stateful PCEP message exchange.” – So any 
implementation which would decide to enable it by default in that PCEP session 
is not RFC complaint? Isn’t that too strict?
[Cheng] This can be changed to SHOULD -> "An implementation supporting this 
document SHOULD allow configuration of the capability..."


Thanks a lot,
Samuel

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Wednesday, February 21, 2024 10:33 AM
To: pce@ietf.org
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

This email starts a 3-weeks working group las

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li]

Hi Shaofu,

Many thanks for your supports and comments.

Please see our reply below.

Thanks,
Cheng



On Fri, Mar 1, 2024 at 12:25 PM 
mailto:peng.sha...@zte.com.cn>> wrote:



Hi Chairs, WG,



I have read this document and find it is useful and support its forwarding.

Please see some comments as below:



[1]

In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that



"When the PCEP session is established, a PCC sends an Open message with an OPEN 
object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]."



This mislead us to understand it is after the session established. May change to



"During the PCEP initialization phase, ..."



[Cheng]Thanks! This is a good suggestion!



or change to

"When the TCP connection is established, ..."



[2]

In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that



"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that 
the PCEP Speaker is willing to send and receive PCEP objects with the P and I 
flags in the PCEP common object header for the stateful PCE messages."



This sentence is not clear because the P and I flags fields are already 
included in the PCEP objects. May change to



"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that 
the PCEP Speaker is willing to handle the P and I flags in the PCEP common 
object header for the stateful PCE messages."



[Cheng]Another good suggestion.



[3]

For seciton 3.2.1. The PCRpt Message, it emphasizes that the P flag of 
mandatory object must be set. It may be more meaningful to provide guidance on 
the setting of the P flag for each object in intended-attribute-list and 
actual-attribute-list, that actually contain the constraints (e.g, bandwidth, 
metric) used for path computation .



[Cheng] Note that all the objects in both the intended-attribute-list and 
actual-attribute-list are optional as per the RBNF and thus would be incorrect 
to club them with mandatory objects.
Overall I don't think we can add any specifics. We can add an example but I am 
unsure how useful that is.



[4]

In 3.3.1. The PCUpd Message, it said that



"Note that when a PCE is unable to find the path that meets all the constraints 
as per the PCEP Object that cannot be ignored (i.e. P flag is set), the PCUpd 
message MAY optionally include the PCEP Objects that caused the path 
computation to fail along with the with the empty ERO."



"with the" in this paragraph is repeated.

[Cheng]Thanks!



Do you think that this paragraph should be moved to section 3.2.1 The PCRpt 
Message ? It seems actually to describe the procesing of P flag in PCRpt. If 
so, may changed to



[Cheng] No, we are following the format as set by RFC 5440 where this is 
described under the handling of I flag. Thus I would leave this unchanged.



"Note that when a PCE is unable to find the path that meets all the constraints 
as per the PCEP Object (carried in PCRpt message) that cannot be ignored (i.e. 
P flag is set), the subsequent PCUpd message MAY optionally include the PCEP 
Objects that caused the path computation to fail along with the with the empty 
ERO."





[5]

In 3.3.2. The PCRpt Message, it said that



"Note that when a PCC is unable to setup the path that meets all the parameters 
as per the PCEP Object that cannot be ignored (i.e. P flag is set), the PCRpt 
message MAY optionally include the PCEP Objects that caused the path setup to 
fail along with the LSP-ERROR-CODE TLV [RFC8231] indicating the reason for the 
failure."



Dos this paragraph also be moved to section 3.2.2. The PCUpd Message and the 
PCInitiate Message ? It seems actually to describe the procesing of P flag in 
PCUpd. If so, may changed to


[Cheng] Lets leave this unchanged for the same reason as above!



"Note that when a PCC is unable to setup the path that meets all the parameters 
as per the PCEP Object (carried in PCUpd message) that cannot be ignored (i.e. 
P flag is set), the subsequent PCRpt message MAY optionally include the PCEP 
Objects that caused the path setup to fail along with the LSP-ERROR-CODE TLV 
[RFC8231] indicating the reason for the failure."



[6]

In section 3.4. Delegation, it said that



"Note that for the delegated LSPs, the PCE can update and mark some objects as 
ignored even when the PCC had set the P flag during delegation. Similarly, the 
PCE can update and mark some object as a must to process even when the PCC had 
not set the P flag during delegation."



I think this statement conflicts with the previous section 3.2 (which gives the 
impression that it is actually an active state of PCE mode, which naturally 
includes delegation). But this paragraph makes P flag no longer obeyed by PCE, 
which is confusing. Maybe I misunderstood.



[Cheng] I can see how this could be confusing. I propose moving section 3.4 
under 3.2.1 and doing some rewording. And change MUST to SHOULD in section 3.2.

Thanks!





Regards,

PSF




Original
From: DhruvDhody mailto:d...

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li]

Oh no! It seems like this email is missing over the email sea.
Crazy busy weeks before IETF Meeting.

Yes, I support the publication of this draft as one of the author. Will 
response to the comments ASAP after the IETF119 meeting.;

Thanks,
Cheng


From: Dhruv Dhody 
Sent: Wednesday, February 21, 2024 5:33 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR poll for draft-ietf-pce-stateful-pce-optional

[Cheng Li]

HI PCE,

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

Thanks,
Cheng

From: Andrew Stone (Nokia) 
Sent: Wednesday, February 21, 2024 6:56 PM
To: pce@ietf.org; pce-cha...@ietf.org; Cheng Li ; Zhenghaomian 
; slitkows.i...@gmail.com
Subject: IPR poll for draft-ietf-pce-stateful-pce-optional

Hi Authors,

In preparation for WGLC on this draft, we'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,
Andrew
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-vendor-02.txt

[Cheng Li]

Hi PCE,

We have refreshed the draft. We believe the draft is quite simple and stable 
for WGLC, so we would like to apply for WGLC.
Comments are welcome in anytime.

Thanks,
Cheng



-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Monday, February 5, 2024 11:16 AM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-vendor-02.txt

Internet-Draft draft-ietf-pce-stateful-pce-vendor-02.txt is now available. It 
is a work item of the Path Computation Element (PCE) WG of the IETF.

   Title:   Conveying Vendor-Specific Information in the Path Computation 
Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE.
   Authors: Cheng Li
Haomian Zheng
Siva Sivabalan
Samuel Sidor
Zafar Ali
   Name:draft-ietf-pce-stateful-pce-vendor-02.txt
   Pages:   12
   Dates:   2024-02-05

Abstract:

   A Stateful Path Computation Element (PCE) maintains information on
   the current network state, including computed Label Switched Path
   (LSPs), reserved resources within the network, and the pending path
   computation requests.  This information may then be considered when
   computing new traffic engineered LSPs, and for the associated and the
   dependent LSPs, received from a Path Computation Client (PCC).

   RFC 7470 defines a facility to carry vendor-specific information in
   stateless Path Computation Element Communication Protocol (PCEP).

   This document extends this capability for the Stateful PCEP messages.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-vendor/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-vendor-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

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

Re: [Pce] AD review of draft-ietf-pce-segment-routing-ipv6-20

[Cheng Li]

Hi John and Dhruv,

We have updated the draft according to your comments.
Thank you so much for your help!


The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-21.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-21



Respect,
Cheng


-Original Message-
From: John Scudder  
Sent: Thursday, February 1, 2024 12:48 AM
To: Cheng Li 
Cc: draft-ietf-pce-segment-routing-i...@ietf.org; pce@ietf.org
Subject: Re: AD review of draft-ietf-pce-segment-routing-ipv6-20

Looks good. I see Dhruv already pointed out that the new registry needs an 
allocation policy. That was my only note. Please go ahead and publish, 
including the change Dhruv requested.

Thanks,

—John

> On Jan 31, 2024, at 12:02 PM, Cheng Li  wrote:
> 
> 
> Hi John,
> 
> Thank you so much for your comments, we think they are very helpful.
> We have modified the draft to address your comments accordingly, please 
> review it again.
> If they can address your comments, we will update the draft very soon.
> 
> Thanks,
> Cheng
> 
> 
> 
> -Original Message-
> From: John Scudder 
> Sent: Thursday, January 25, 2024 12:49 AM
> To: draft-ietf-pce-segment-routing-i...@ietf.org
> Cc: pce@ietf.org
> Subject: AD review of draft-ietf-pce-segment-routing-ipv6-20
> 
> Hi Authors, WG,
> 
> Thanks for this document.
> 
> I’ve supplied my questions and comments in the form of an edited copy of the 
> draft. Minor editorial suggestions I’ve made in place without further 
> comment, more substantive questions and comments are done in-line and 
> prefixed with “jgs:”. You can use your favorite diff tool to review them; 
> I’ve attached the iddiff output for your convenience if you’d like to use it. 
> I’ve also pasted a traditional diff below in case you want to use it for 
> in-line reply.
> 
> One further point regarding “minor editorial suggestions”. While I did make a 
> few, I didn’t do exhaustive copy-editing of this draft, and of course, the 
> RFC Editor will do their usual comprehensive job. However, I did notice a 
> pervasive need for a few particular kinds of changes (for example definite 
> articles, agreement in number) that mar what’s otherwise a high-quality 
> document and are likely to bother some reviewers. It’s optional, but it 
> wouldn’t be a bad idea for you to pass the document through a grammar checker 
> before we send it for IETF Review. Your call.
> 
> Thanks,
> 
> —John
> 
> --- draft-ietf-pce-segment-routing-ipv6-20.txt  2024-01-24 
> 14:39:13.0 -0500
> +++ draft-ietf-pce-segment-routing-ipv6-20-jgs-comments.txt 2024-01-24 
> 18:40:57.0 -0500
> @@ -29,12 +29,15 @@
>A Segment Routed Path can be derived from a variety of mechanisms,
>including an IGP Shortest Path Tree (SPT), explicit configuration, or
>a PCE.
> +--
> +jgs: I think it would be appropriate to expand PCE.
> +--
> 
>Since SR can be applied to both MPLS and IPv6 forwarding planes, a
> -   PCE should be able to compute SR-Path for both MPLS and IPv6
> +   PCE should be able to compute an SR path for both MPLS and IPv6
>forwarding planes.  The PCEP extension and mechanisms to support SR-
>MPLS have been defined.  This document describes the extensions
> -   required for SR support for IPv6 data plane in the Path Computation
> +   required for SR support for the IPv6 data plane in the Path 
> + Computation
>Element communication Protocol (PCEP).
> 
> Status of This Memo
> @@ -151,7 +154,7 @@
>[RFC8754].
> 
>An SR path can be derived from an IGP Shortest Path Tree (SPT), but
> -   SR-TE (Segment Routing Traffic Engineering) paths may not follow IGP
> +   SR-TE (Segment Routing Traffic Engineering) paths might not follow 
> + IGP
>SPT.  Such paths may be chosen by a suitable network planning tool,
>or a PCE and provisioned on the ingress node.
> 
> @@ -186,7 +189,7 @@
>stateful PCE for computing one or more SR-TE paths taking into
>account various constraints and objective functions.  Once a path is
>chosen, the stateful PCE can initiate an SR-TE path on a PCC using
> -   PCEP extensions specified in [RFC8281] using the SR specific PCEP
> +   PCEP extensions specified in [RFC8281] and the SR-specific PCEP
>extensions specified in [RFC8664].  [RFC8664] specifies PCEP
>extensions for supporting a SR-TE LSP for the MPLS data plane.  This
>document extends [RFC8664] to support SR for the IPv6 data plane.
> @@ -228,6 +231,16 @@
> 
>The message 

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Cheng Li]

Hi Mike,

Thanks for the quick reply. I think my comments are almost addressed. Please 
see my reply inline.

Thanks,
Cheng


From: Mike Koldychev (mkoldych) 
Sent: Tuesday, January 16, 2024 6:05 PM
To: Cheng Li ; Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org; mkold...@proton.me
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Cheng,

Thanks for your review! Comments inline with .

Thanks,
Mike.


From: Cheng Li 
mailto:c.l=40huawei@dmarc.ietf.org>>
Sent: Tuesday, January 16, 2024 11:09 AM
To: Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

I read the document and support the WGLC.
However, I also have some minor comments below.


1.
Abstract

A Segment Routing (SR) Policy 
[RFC9256<https://www.rfc-editor.org/info/rfc9256>] is a non-empty set of SR 
Candidate Paths, that share the same  tuple.
1.Nits: s/that/which.

Sure.


2.share the same <> tuple?

Sorry, not clear what your comment is here? The text is referring to the 
3-tuple that identifies the SR Policy, from here: 
https://www.rfc-editor.org/rfc/rfc9256.html#name-identification-of-an-sr-pol

well， I see your point. But recommend to rephrase the text. But this is not 
a big deal, you can ignore it.

3.This document extends [RFC8664<https://www.rfc-editor.org/info/rfc8664>] to 
fully support the SR Policy construct.
fully? suggest to remove this world. The SR policy is developing, so it can not 
be fully supported now I guess.

Sure, I will remove the “fully”.



4.
Introduction

PCEP Extensions for Segment Routing 
[RFC8664<https://www.rfc-editor.org/info/rfc8664>] specifies extensions that 
allow PCEP to work with basic SR-TE 
paths.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-1-1>
s/specifies/specify

Sure, I can just use the RFC Number, instead of the full name.

it works to me.

PCEP Extensions for Establishing Relationships Between Sets of LSPs 
[RFC8697<https://www.rfc-editor.org/info/rfc8697>] introduces
s/introduces/introduce because of extensions?  or you only wanto to list the 
name of the RFC here? anyway, all are nits. Normally, we use RFC as the 
subject directly.

Sure, I can just use the RFC Number, instead of the full name.

great

5. again. Suggest to delete 'fully' in the last paragraph of Introduction.

Will do.


6.
SR Policy Association. PCEP ASSOCATION that describes the SR Policy. Can refer 
to the PCEP object or to the group of LSPs that belong to the Association. This 
should be clear from the 
context.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-2-2.4>

suggest to rephrase this description to be more formal? , too casual to me.

Sure, will rephrase. There was a prior comment about this as well.


7.When these rules are not satisfied, the PCE MUST send a PCErr message with 
Error-Type = 26 "Association Error", Error Value = TBD8

Only the PCE sends? do we have any case that a PCC may send this error?

True, it should be “PCEP speaker”, not “PCE”. Thanks.

nice
8.

This Association Type is dynamic in nature, thus operator-configured 
Association Range MUST NOT be set for this Association type and MUST be 
ignored.¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-4-2>

Sorry I do not understand this paragraph. What do you mean this association 
type is dynamic in nature?

It’s referring to this: https://www.rfc-editor.org/rfc/rfc8697.html#section-3.4 
. The text is basically saying that this Association Type is fully dynamic. I’m 
not sure if this is necessary to say, or if we can rephase it to be clearer? 
Any suggestions?

 All right, I see your point. If you decided to use 6, then the text works 
to me. But I will suggest to add a reference to explain that, and also, it is 
not dynamic in nature. Some of them can be configured so it is dynamic. We 
chosen 6, so it is not dynamic anymore, isn’t it?
9.
·Association ID (16-bit): set to 
"1".¶<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-12#section-4.1-3.3>
why the ID must be set as 1? do you mean a association is identified by 
association source, color, and endpoint in extended association ID TLV? so we 
do not need Association ID?
or you like to use This ID 1 to avoid the race case between multiple PCE?

Yes, the association is identified by , so this 16-bit 
field is not useful. We set it to “1” to avoid using “0”, which is a reserved 
value for that field. I can put a sentence to clarify this in the text.

All right

10.

   0 

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Cheng Li]

Hi WG,

I read the document and support the WGLC.
However, I also have some minor comments below.


1.
Abstract

A Segment Routing (SR) Policy 
[RFC9256] is a non-empty set of SR 
Candidate Paths, that share the same  tuple.
1.Nits: s/that/which.
2.share the same <> tuple?
3.This document extends [RFC8664] to 
fully support the SR Policy construct.
fully? suggest to remove this world. The SR policy is developing, so it can not 
be fully supported now I guess.

4.
Introduction

PCEP Extensions for Segment Routing 
[RFC8664] specifies extensions that 
allow PCEP to work with basic SR-TE 
paths.¶
s/specifies/specify

PCEP Extensions for Establishing Relationships Between Sets of LSPs 
[RFC8697] introduces
s/introduces/introduce because of extensions?  or you only wanto to list the 
name of the RFC here? anyway, all are nits. Normally, we use RFC as the 
subject directly.

5. again. Suggest to delete 'fully' in the last paragraph of Introduction.

6.
SR Policy Association. PCEP ASSOCATION that describes the SR Policy. Can refer 
to the PCEP object or to the group of LSPs that belong to the Association. This 
should be clear from the 
context.¶

suggest to rephrase this description to be more formal? , too casual to me.

7.When these rules are not satisfied, the PCE MUST send a PCErr message with 
Error-Type = 26 "Association Error", Error Value = TBD8

Only the PCE sends? do we have any case that a PCC may send this error?

8.

This Association Type is dynamic in nature, thus operator-configured 
Association Range MUST NOT be set for this Association type and MUST be 
ignored.¶

Sorry I do not understand this paragraph. What do you mean this association 
type is dynamic in nature?

9.
·Association ID (16-bit): set to 
"1".¶
why the ID must be set as 1? do you mean a association is identified by 
association source, color, and endpoint in extended association ID TLV? so we 
do not need Association ID?
or you like to use This ID 1 to avoid the race case between multiple PCE?

10.

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   |
  ~   SR Policy Name  ~
  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 
2:
 The SRPOLICY-POL-NAME TLV 
format

Though I can not image what may be added to this TLV now. But I think reserving 
0 bits for a new TLV is not a good decision.
same for "SRPOLICY-CPATH-NAME" TLV

11. section 8

This document defines one new type for association, which do not add any new 
security concerns beyond those discussed
s/association/ASSOCIATION Object
s/do/does

Thanks,
Cheng



From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, January 8, 2024 11:29 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-segment-routing-policy-cp-12.

https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

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 Monday 22nd January 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR poll for draft-ietf-pce-segment-routing-policy-cp

[Cheng Li]

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

Cheng Li

From: Andrew Stone (Nokia) 
Sent: Monday, January 8, 2024 7:28 PM
To: pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Mike 
Koldychev (mkoldych) ; Sivabalan, Siva 
; cba...@juniper.net; Pengshuping (Peng Shuping) 
; Hooman Bidgoli (Nokia) ; 
Dhruv Dhody ; Cheng Li ; Samuel Sidor 
(ssidor) 
Cc: pce-cha...@ietf.org
Subject: IPR poll for draft-ietf-pce-segment-routing-policy-cp

Hi Authors,

In preparation for WGLC on this draft, we'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,
Andrew
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] I-D Action: draft-ietf-pce-state-sync-06.txt

[Cheng Li]

Hi PCE WG,

This update mainly includes:

* editorial modifications of some text, and references.
* changed some 'SHOULD' to 'MUST' according to the context, e.g. the PCE with 
highest priority MUST be response instead of SHOULD be response.
* added more detailed text in manageability considerations sub-section.

Comments are welcome. IMHO, this draft may be ready for WGLC already 😊

Thanks,
Cheng

 

-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, January 2, 2024 4:17 PM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-state-sync-06.txt

Internet-Draft draft-ietf-pce-state-sync-06.txt is now available. It is a work 
item of the Path Computation Element (PCE) WG of the IETF.

   Title:   Inter Stateful Path Computation Element (PCE) Communication 
Procedures.
   Authors: Stephane Litkowski
Siva Sivabalan
Cheng Li
Haomian Zheng
   Name:draft-ietf-pce-state-sync-06.txt
   Pages:   35
   Dates:   2024-01-02

Abstract:

   The Path Computation Element (PCE) Communication Protocol (PCEP)
   provides mechanisms for PCEs to perform path computation in response
   to a Path Computation Client (PCC) request.  The Stateful PCE
   extensions allow stateful control of Multi-Protocol Label Switching
   (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using
   PCEP.

   A Path Computation Client (PCC) can synchronize an LSP state
   information to a Stateful Path Computation Element (PCE).  A PCC can
   have multiple PCEP sessions towards multiple PCEs.  There are some
   use cases, where an inter-PCE stateful communication can bring
   additional resiliency in the design, for instance when some PCC-PCE
   session fails.

   This document describes the procedures to allow a stateful
   communication between PCEs for various use-cases and also the
   procedures to prevent computations loops.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-state-sync/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pce-state-sync-06.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-state-sync-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [Pce] Early Code Point Allocation for draft-ietf-pce-sr-bidir-path

[Cheng Li]

Many thanks to Dhruv and Julien!

Respect,
Cheng


-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Thursday, November 9, 2023 5:11 PM
To: pce@ietf.org
Subject: Re: [Pce] Early Code Point Allocation for draft-ietf-pce-sr-bidir-path

Hi all,

No concerns have been expressed about this early allocation. We'll thus proceed 
to the next step.

Thanks,

Dhruv & Julien


On 28/07/2023 15:58, Julien Meuric wrote:
> Hi WG,
>
> We have received a request from the authors of 
> draft-ietf-pce-sr-bidir-path for an early code point allocation on the 
> association type referred to in 
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-11#
> name-iana-considerations
>
> 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 August 21st, we will kick 
> off the early allocation request.
>
> Thanks!
>
> Dhruv & Julien
>

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

Re: [Pce] WGLC for draft-ietf-pce-pceps-tls13-01

[Cheng Li]

Hi PCE,

I support the WGLC. The draft is simple but useful, we should move it to RFC 
very fast.

Some editorial comments:

0. Title of this draft is unclear, what is update of PCEPS. Good to explain 
more clear.

1. Abstract:
This document updates RFC 8253 to address support requirements for TLS 1.2 and 
TLS 1.3 and the use of TLS 1.3's early data.

Address? To many meanings for this word, we may change it by another? Describe? 
Same for the one in introduction.

2. Section 4.
I think the name of this section is not clear. This section describes the 
requirements in implementation. Should change to Requirements?
However, section use Early Data as a title, then we should add a section called 
requirements and move section 3 and 4 into this section?

3.Section 4
Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to support the 
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite [RFC9325].

__NEW__
Implementations MUST support TLS 1.2 [RFC5246] and the 
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite [RFC9325].

4. 
Implementations SHOULD support TLS 1.3 [I-D.ietf-tls-rfc8446bis] and, if 
implemented, MUST prefer to negotiate TLS 1.3 over earlier versions of TLS.

If a SHOULD is used here, then I do not see the value of this draft. I suggest 
to use MUST here. Unless some features in the draft is not in the scope of 
TLS1.3.
So we don’t need to assume the case of supporting TLS1.3.

5. Section 5

The Security Considerations of PCEP [RFC5440], [RFC8231], [RFC8281], and 
[RFC8283]; TLS 1.2 [RFC5246]; TLS 1.3 [I-D.ietf-tls-rfc8446bis], and; [RFC9325] 
apply here as well.

__NEW__
The Security Considerations of PCEP [RFC5440], [RFC8231], [RFC8281], and 
[RFC8283]; TLS 1.2 [RFC5246]; TLS 1.3 [I-D.ietf-tls-rfc8446bis], and; [RFC9325] 
apply to this document as well.

I am not sure that the second paragraph should be added or it will be better to 
add into the introduction?

The rest looks good to me. 

Many thanks,
Cheng




-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Tuesday, September 5, 2023 11:10 AM
To: pce@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-pceps-tls13-01

Dear PCE WG,

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

This WGLC will end on Wednesday 20th September 2023.

Thanks,

Julien

--
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/

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

Re: [Pce] I-D Action: draft-ietf-pce-pcep-srv6-yang-04.txt

[Cheng Li]

Hi PCE,

We updated the draft to sync up with the modification in PCEP SRv6 extension 
draft: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/
* Delete the MSD limitation info: X-flag.
* editorial modifications.

Comments are welcome.

Thanks,
Li Cheng





-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Monday, September 11, 2023 2:20 PM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-pcep-srv6-yang-04.txt

Internet-Draft draft-ietf-pce-pcep-srv6-yang-04.txt is now available. It is a 
work item of the Path Computation Element (PCE) WG of the IETF.

   Title:   A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 
(SRv6) support in Path Computation Element Communications Protocol (PCEP)
   Authors: Cheng Li
Siva Sivabalan
Shuping Peng
Mike Koldychev
Luc-Fabrice Ndifor
   Name:draft-ietf-pce-pcep-srv6-yang-04.txt
   Pages:   23
   Dates:   2023-09-11

Abstract:

   This document augments a YANG data model for the management of Path
   Computation Element Communications Protocol (PCEP) for communications
   between a Path Computation Client (PCC) and a Path Computation
   Element (PCE), or between two PCEs in support for Segment Routing in
   IPv6 (SRv6) and SR Policy.  The data model includes configuration
   data and state data (status information and counters for the
   collection of statistics).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-srv6-yang/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-srv6-yang-04

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-srv6-yang-04

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

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

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

[Cheng Li]

Hi PCE,

We have updated the draft to add one more implementation from Huawei. Other 
implementations are welcome.
Also, we have received the confirmation from Yingzhen that her comments have 
been addressed.

Chairs, please help to move the draft forward, thank you very much!

Respect,
Cheng



-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Friday, September 8, 2023 10:16 AM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-20.txt

Internet-Draft draft-ietf-pce-segment-routing-ipv6-20.txt is now available. It 
is a work item of the Path Computation Element (PCE) WG of the IETF.

   Title:   Path Computation Element Communication Protocol (PCEP) Extensions 
for Segment Routing leveraging the IPv6 dataplane
   Authors: Cheng Li(Editor)
Prejeeth Kaladharan
Siva Sivabalan
Mike Koldychev
Yongqing Zhu
   Name:draft-ietf-pce-segment-routing-ipv6-20.txt
   Pages:   27
   Dates:   2023-09-08

Abstract:

   Segment Routing (SR) can be used to steer packets through an IPv6 or
   MPLS network using the source routing paradigm.  SR enables any head-
   end node to select any path without relying on a hop-by-hop signaling
   technique (e.g., LDP or RSVP-TE).

   A Segment Routed Path can be derived from a variety of mechanisms,
   including an IGP Shortest Path Tree (SPT), explicit configuration, or
   a PCE.

   Since SR can be applied to both MPLS and IPv6 forwarding planes, a
   PCE should be able to compute SR-Path for both MPLS and IPv6
   forwarding planes.  The PCEP extension and mechanisms to support SR-
   MPLS have been defined.  This document describes the extensions
   required for SR support for IPv6 data plane in the Path Computation
   Element communication Protocol (PCEP).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-20.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-20

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

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

Re: [Pce] Please share the implementation status of draft-ietf-pce-segment-routing-ipv6

[Cheng Li]

Reminder, we only have one implementation info in the draft, I guess the info 
is out of date.

Sharing info of implementation status is welcome. Please feel free to reach to 
us,  and we can update it in the next revision.

Thanks,
Cheng


From: Pce  On Behalf Of Cheng Li
Sent: Thursday, August 3, 2023 11:31 AM
To: pce@ietf.org; draft-ietf-pce-segment-routing-i...@ietf.org
Cc: pce-chairs 
Subject: [Pce] Please share the implementation status of 
draft-ietf-pce-segment-routing-ipv6

Hi PCEers,

As discussed in last PCE WG meeting, we heard that there are some 
implementations out there and should be recorded in the draft, so please free 
feel to share it to the list or to authors directly. We will add them ASAP in 
the next revision.

Many thanks,
Li Cheng



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

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

[Cheng Li]

Hi PCE,

Many thanks for your long-term support and contribution.

Finally, we addressed all the comments received by now, and updated the draft 
as below.
Please review the draft, and again, comments are welcome. 

Hope we can publish this document as RFC ASAP.

Respect,
Li Cheng



-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, September 6, 2023 9:56 AM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-19.txt

Internet-Draft draft-ietf-pce-segment-routing-ipv6-19.txt is now available. It 
is a work item of the Path Computation Element (PCE) WG of the IETF.

   Title:   Path Computation Element Communication Protocol (PCEP) Extensions 
for Segment Routing leveraging the IPv6 dataplane
   Authors: Cheng Li(Editor)
Mahendra Singh Negi
Siva Sivabalan
Mike Koldychev
Yongqing Zhu
   Name:draft-ietf-pce-segment-routing-ipv6-19.txt
   Pages:   26
   Dates:   2023-09-06

Abstract:

   Segment Routing (SR) can be used to steer packets through an IPv6 or
   MPLS network using the source routing paradigm.  SR enables any head-
   end node to select any path without relying on a hop-by-hop signaling
   technique (e.g., LDP or RSVP-TE).

   A Segment Routed Path can be derived from a variety of mechanisms,
   including an IGP Shortest Path Tree (SPT), explicit configuration, or
   a PCE.

   Since SR can be applied to both MPLS and IPv6 forwarding planes, a
   PCE should be able to compute SR-Path for both MPLS and IPv6
   forwarding planes.  The PCEP extension and mechanisms to support SR-
   MPLS have been defined.  This document describes the extensions
   required for SR support for IPv6 data plane in the Path Computation
   Element communication Protocol (PCEP).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-19.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-19

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

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

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

[Cheng Li]

Hi WG，

We have updated the draft to address the MSD comments from Ketan and Martin, 
and they have confirmed the update works to them.

The only one left functional comment is the X-flag. Please let us know your 
thoughts if you have any POV. For details, you can read the previous email sent 
by Chair Dhruv.

Thanks,
Cheng



-Original Message-
From: internet-dra...@ietf.org  
Sent: Monday, August 28, 2023 10:35 AM
To: Cheng Li ; Cheng Li ; Mahendra Negi 
; Mahendra Singh Negi ; Mike 
Koldychev ; Prejeeth Kaladharan ; 
Siva Sivabalan ; Yongqing Zhu 
Subject: New Version Notification for draft-ietf-pce-segment-routing-ipv6-18.txt

A new version of Internet-Draft draft-ietf-pce-segment-routing-ipv6-18.txt has 
been successfully submitted by Cheng Li(Editor) and posted to the IETF 
repository.

Name: draft-ietf-pce-segment-routing-ipv6
Revision: 18
Title:Path Computation Element Communication Protocol (PCEP) Extensions for 
Segment Routing leveraging the IPv6 dataplane
Date: 2023-08-28
Group:pce
Pages:27
URL:  
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-18.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/
HTML: 
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-18.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-18

Abstract:

   Segment Routing (SR) can be used to steer packets through an IPv6 or
   MPLS network using the source routing paradigm.  SR enables any head-
   end node to select any path without relying on a hop-by-hop signaling
   technique (e.g., LDP or RSVP-TE).

   A Segment Routed Path can be derived from a variety of mechanisms,
   including an IGP Shortest Path Tree (SPT), explicit configuration, or
   a PCE.

   Since SR can be applied to both MPLS and IPv6 forwarding planes, a
   PCE should be able to compute SR-Path for both MPLS and IPv6
   forwarding planes.  The PCEP extension and mechanisms to support SR-
   MPLS have been defined.  This document describes the extensions
   required for SR support for IPv6 data plane in the Path Computation
   Element communication Protocol (PCEP).



The IETF Secretariat



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

Re: [Pce] New Version Notification for draft-ietf-pce-stateful-pce-vendor-01.txt

[Cheng Li]

Hi Andrew and Aijun,

The draft has been updated to address your comments received in the WG adoption 
call.
Please check if it works for you.

Thanks,
Li Cheng


-Original Message-
From: internet-dra...@ietf.org  
Sent: Tuesday, August 8, 2023 2:49 PM
To: Cheng Li ; Zhenghaomian ; Samuel 
Sidor ; Siva Sivabalan ; Zafar Ali 

Subject: New Version Notification for draft-ietf-pce-stateful-pce-vendor-01.txt


A new version of I-D, draft-ietf-pce-stateful-pce-vendor-01.txt
has been successfully submitted by Cheng Li and posted to the IETF repository.

Name:   draft-ietf-pce-stateful-pce-vendor
Revision:   01
Title:  Conveying Vendor-Specific Information in the Path Computation 
Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE.
Document date:  2023-08-07
Group:  pce
Pages:  12
URL:
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-vendor/
Html:   
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-01.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-vendor
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-vendor-01

Abstract:
   A Stateful Path Computation Element (PCE) maintains information on
   the current network state, including computed Label Switched Path
   (LSPs), reserved resources within the network, and the pending path
   computation requests.  This information may then be considered when
   computing new traffic engineered LSPs, and for the associated and the
   dependent LSPs, received from a Path Computation Client (PCC).

   RFC 7470 defines a facility to carry vendor-specific information in
   stateless Path Computation Element Communication Protocol (PCEP).

   This document extends this capability for the Stateful PCEP messages.


  


The IETF Secretariat



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

Re: [Pce] Mail regarding draft-ietf-pce-pcep

[Cheng Li]

Hi Marcel,

Thanks for the discussion. It seems that we do not need to update the 
draft-ietf-pce-stateful-pce-vendor if I do not understand wrongly.

If you have any thoughts, please feel free to share further.

Thanks,
Li Cheng


From: Marcel Reuter (External) 
Sent: Friday, August 4, 2023 4:03 PM
To: Samuel Sidor (ssidor) ; Vishnu Pavan Beeram 

Cc: Dhruv Dhody ; Dhruv Dhody ; 
pce@ietf.org; draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep

Hi Samuel!

Many thanks for your detailed answer!

Many thanks to Dhruv and Pavan for all input and discussion.



From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Date: Thursday, 3. August 2023 at 19:30
To: Vishnu Pavan Beeram mailto:vishnupa...@gmail.com>>
Cc: Dhruv Dhody mailto:d...@dhruvdhody.com>>, Dhruv Dhody 
mailto:dhruv.i...@gmail.com>>, Marcel Reuter (External) 
mailto:marcel.reuter.exter...@telefonica.com>>,
 pce@ietf.org mailto:pce@ietf.org>>, 
draft-ietf-pce-stateful-pce-ven...@ietf.org
 
mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org>>
Subject: RE: [Pce] Mail regarding draft-ietf-pce-pcep
Hi Pavan,

Please see inline .

Regards,
Samuel

From: Vishnu Pavan Beeram mailto:vishnupa...@gmail.com>>
Sent: Thursday, August 3, 2023 4:40 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: Dhruv Dhody mailto:d...@dhruvdhody.com>>; Dhruv Dhody 
mailto:dhruv.i...@gmail.com>>; Marcel Reuter (External) 
mailto:marcel.reuter.exter...@telefonica.com>>;
 pce@ietf.org; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep

Samuel, Hi!

The requirement is to be able to carry "vendor specific information" in the 
OPEN message. Some of this information may be relevant for deciding whether the 
session should be established or not while some other information may become 
relevant only later when processing LSPs (and has no bearing on "opening" the 
session). An implementation should be able to use the VENDOR_INFO TLV in the 
OPEN object for the former and the VENDOR_INFO Object (marked optional like in 
any other message) for the latter. I don't understand why this 
usage/flexibility needs to be prohibited.

 I don’t think it was explicitly prohibited for vendor info object. It is 
inheriting default rules, which are applied for all PCEP objects. RC5440 
clearly stated that content of PCEP message is described in BNF – so all 
mandatory and optional objects, which can be included are explicitly listed. 
Each RFC, which is defining new PCEP object is explicitly specifying where that 
PCEP object can be included (PCEP message, ordering,…).



I assume that when RFC7470 introduced vendor info object, there was no valid 
use-case for including that PCEP object in Open message, so it was not 
explicitly added – same way like it was not added to other PCEP messages. If we 
want to allow it now, then logical questions are:

  *   What has changed since RFC7470? Is there really new use-case which cannot 
be covered with existing vendor TLV? If we will allow use only in Open message, 
how we will make sure that in 5 months somebody else will not need it in any 
other PCEP message?
  *   How to handle backward compatibility? E.g. what will happen if you will 
start including Vendor Info object in Open message, but existing 
implementations, which are complaint with all existing RFCs will reject those 
Open messages (you need to consider those with support for RFC7470, but also 
those without support)? If extension required is for other PCEP messages, then 
you we can have capability advertised in Open message to figure out, whether 
extension is supported, but since you need to extend PCEP Open message, you 
don’t have simple way to figure it out.
  *   Where such extension should be included? As Dhruv mentioned, logically it 
does not belong into stateful vendor info draft, so we have 2 options:

 *   New draft
 *   Re-working stateful draft to include this change, rename it,…

That said, if the WG concludes that the "vendor specific information" should 
ONLY exist in TLV form in the OPEN message, I would like it to be explicitly 
specified somewhere.

 As described above – for PCEP objects, it is always explicitly specified 
which PCEP object is allowed in which PCEP message. For TLV, RFC7470 is already 
saying:

https://www.rfc-editor.org/rfc/rfc7470.html#section-1

   This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV
   that can be used to carry arbitrary information within any existing
   or future PCEP object that supports TLVs.
…

   -  Clarification that the TLV is available for use in any PCEP object

  (existing or future) that supports TLVs.

But maybe other WG members knows about some other statements, which can still 
block it for Open message.

Regards,
-Pavan

On Thu, Aug 3, 2023 at 1:45 

[Pce] Please share the implementation status of draft-ietf-pce-segment-routing-ipv6

[Cheng Li]

Hi PCEers,

As discussed in last PCE WG meeting, we heard that there are some 
implementations out there and should be recorded in the draft, so please free 
feel to share it to the list or to authors directly. We will add them ASAP in 
the next revision.

Many thanks,
Li Cheng



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

Re: [Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor

[Cheng Li]

Hi Julien & Dhruv,

Many thanks for your work, we have uploaded the 00 revision draft.
Will address the comments in 01 very soon, and I think we may not receive too 
many comments. The proposed update will be shared in Github, and send to the ML 
before submitting.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-vendor/


There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-00.html

Thanks,
Li Cheng



-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Monday, July 17, 2023 9:03 PM
To: pce@ietf.org
Subject: Re: [Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor

Hi PCE WG,

We have clear support to adopt this work as a WG item. Thank you, all.

@Authors: Please submit the I-D as draft-ietf-pce-stateful-pce-vendor-00
when the submission tool reopens (starting next Saturday).

Cheers,

Dhruv & Julien


On 20/06/2023 09:46, Julien Meuric wrote:
> Hi all,
>
> It has been a while since draft-dhody-pce-stateful-pce-vendor started 
> to document how to extend the scope of RFC 7470. It is now time to 
> consider its adoption by the WG.
> Do you think draft-dhody-pce-stateful-pce-vendor-16 [1] is ready to 
> become a PCE work item? Please express your support and/or concerns 
> using the mailing list.
>
> Thanks,
>
> Dhruv & Julien
>
>
> [1] 
> https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-vendor

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

Re: [Pce] 答复: Adoption Poll for draft-dhody-pce-stateful-pce-vendor

[Cheng Li]

Hi Aijun,

Thanks you for your supports. Great comments, we can add some words in the next 
revision in Introduction. Will let you know when we update the draft.

Thank you again,
Cheng




-Original Message-
From: Pce  On Behalf Of Aijun Wang
Sent: Friday, June 30, 2023 9:45 AM
To: julien.meu...@orange.com; pce@ietf.org
Subject: [Pce] 答复: Adoption Poll for draft-dhody-pce-stateful-pce-vendor

Hi, All:

Support its adoption.

Will it be more clear that points out RFC7470 defined the Vendor-Information 
Object and Vendor-Information-TLV for stateless PCE(PCReq/PCRep Message), then 
this document extends it to stateful PCE? Especially includes the vendor 
information in PCRpt/PCUpd/PCInitiate Message.
In the "Abstract" and "Introduction" parts, the corresponding sentences have 
all no such explicit statements. 


Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表
julien.meu...@orange.com
发送时间: 2023年6月20日 15:47
收件人: pce@ietf.org
主题: [Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor

Hi all,

It has been a while since draft-dhody-pce-stateful-pce-vendor started to 
document how to extend the scope of RFC 7470. It is now time to consider its 
adoption by the WG.
Do you think draft-dhody-pce-stateful-pce-vendor-16 [1] is ready to become a 
PCE work item? Please express your support and/or concerns using the mailing 
list.

Thanks,

Dhruv & Julien


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


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

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

[Cheng Li]

Hi PCE,
(The previous email was sent too fast, fixed some syntax errors and resend)

This update addressed the comments from Adrian, Ran Chen and Yingzhen. Many 
thanks to their valuable comments[1], please review and confirm, thanks!
This update also tries to address the comments from Ketan. We believe that we 
have addressed the editorial comments from Ketan[1]. 

Till now, we may have two reserved comments to be addressed:
1. IANA allocation of SRv6-ERO(From Adrian): Should we create a new registry 
for SR/SRv6?  or allocate them from the RSVP parameters registry? Comments are 
welcome.
2. X-flag(From Ketan): is the X-flag needed? If not, why? if we decide to 
delete it, we need to know from the WG that if anyone has implemented it, and 
how can we handle the compatibility problem.

Comments and feedbacks are appreciated.

Respect,
Cheng


[1]. https://github.com/muzixing/IETF-PCEP-SRV6/issues

-Original Message-
From: Pce  On Behalf Of Cheng Li
Sent: Wednesday, June 28, 2023 10:42 AM
To: pce@ietf.org; Mahendra Negi ; Mahendra Singh Negi 
; Mike Koldychev ; Prejeeth 
Kaladharan ; Siva Sivabalan ; 
Yongqing Zhu ; Ketan Talaulikar 
; adr...@olddog.co.uk; yingzhen.i...@gmail.com; 
chen@zte.com.cn
Subject: Re: [Pce] New Version Notification for 
draft-ietf-pce-segment-routing-ipv6-17.txt

Hi PCE,

This update addressed the comments from Adrian, Ran Chen and Yingzhen. Many 
thanks to their valuable comments[1], please review and confirm, thanks!
This update also try to address the comments from Ketan. We believe that we 
have addressed the editorial from Ketan[1]. 

Till now, we may have two reserved comments to be addressed:

1. IANA allocation of SRv6-ERO(From Adrian): Should we create a new registry 
for SR/SRv6 or allocate in from the RSVP parameters registry? Comments are 
welcome.
2. X-flag(From Ketan): is the X-flag needed? If not, why? if we decide to 
delete it, we need to know from the WG that if anyone has implemented it, and 
how can we handle the compatibility problem.

Comments and feedback are appreciated.

Respect,
Cheng


[1]. https://github.com/muzixing/IETF-PCEP-SRV6/issues


-Original Message-
From: internet-dra...@ietf.org  
Sent: Wednesday, June 28, 2023 10:29 AM
To: Cheng Li ; Cheng Li ; Mahendra Negi 
; Mahendra Singh Negi ; Mike 
Koldychev ; Prejeeth Kaladharan ; 
Siva Sivabalan ; Yongqing Zhu 
Subject: New Version Notification for draft-ietf-pce-segment-routing-ipv6-17.txt


A new version of I-D, draft-ietf-pce-segment-routing-ipv6-17.txt
has been successfully submitted by Cheng Li(Editor) and posted to the IETF 
repository.

Name:   draft-ietf-pce-segment-routing-ipv6
Revision:   17
Title:  Path Computation Element Communication Protocol (PCEP) 
Extensions for Segment Routing leveraging the IPv6 dataplane
Document date:  2023-06-28
Group:  pce
Pages:  26
URL:
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-17.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/
Html:   
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-17.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-17

Abstract:
   Segment Routing (SR) can be used to steer packets through an IPv6 or
   MPLS network using the source routing paradigm.  SR enables any head-
   end node to select any path without relying on a hop-by-hop signaling
   technique (e.g., LDP or RSVP-TE).

   A Segment Routed Path can be derived from a variety of mechanisms,
   including an IGP Shortest Path Tree (SPT), explicit configuration, or
   a PCE.

   Since SR can be applied to both MPLS and IPv6 forwarding planes, a
   PCE should be able to compute SR-Path for both MPLS and IPv6
   forwarding planes.  The PCEP extension and mechanisms to support SR-
   MPLS have been defined.  This document describes the extensions
   required for SR support for IPv6 data plane in the Path Computation
   Element communication Protocol(PCEP).


  


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

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

[Cheng Li]

Hi PCE,

This update addressed the comments from Adrian, Ran Chen and Yingzhen. Many 
thanks to their valuable comments[1], please review and confirm, thanks!
This update also try to address the comments from Ketan. We believe that we 
have addressed the editorial from Ketan[1]. 

Till now, we may have two reserved comments to be addressed:

1. IANA allocation of SRv6-ERO(From Adrian): Should we create a new registry 
for SR/SRv6 or allocate in from the RSVP parameters registry? Comments are 
welcome.
2. X-flag(From Ketan): is the X-flag needed? If not, why? if we decide to 
delete it, we need to know from the WG that if anyone has implemented it, and 
how can we handle the compatibility problem.

Comments and feedback are appreciated.

Respect,
Cheng


[1]. https://github.com/muzixing/IETF-PCEP-SRV6/issues


-Original Message-
From: internet-dra...@ietf.org  
Sent: Wednesday, June 28, 2023 10:29 AM
To: Cheng Li ; Cheng Li ; Mahendra Negi 
; Mahendra Singh Negi ; Mike 
Koldychev ; Prejeeth Kaladharan ; 
Siva Sivabalan ; Yongqing Zhu 
Subject: New Version Notification for draft-ietf-pce-segment-routing-ipv6-17.txt


A new version of I-D, draft-ietf-pce-segment-routing-ipv6-17.txt
has been successfully submitted by Cheng Li(Editor) and posted to the IETF 
repository.

Name:   draft-ietf-pce-segment-routing-ipv6
Revision:   17
Title:  Path Computation Element Communication Protocol (PCEP) 
Extensions for Segment Routing leveraging the IPv6 dataplane
Document date:  2023-06-28
Group:  pce
Pages:  26
URL:
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-17.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/
Html:   
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-17.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-17

Abstract:
   Segment Routing (SR) can be used to steer packets through an IPv6 or
   MPLS network using the source routing paradigm.  SR enables any head-
   end node to select any path without relying on a hop-by-hop signaling
   technique (e.g., LDP or RSVP-TE).

   A Segment Routed Path can be derived from a variety of mechanisms,
   including an IGP Shortest Path Tree (SPT), explicit configuration, or
   a PCE.

   Since SR can be applied to both MPLS and IPv6 forwarding planes, a
   PCE should be able to compute SR-Path for both MPLS and IPv6
   forwarding planes.  The PCEP extension and mechanisms to support SR-
   MPLS have been defined.  This document describes the extensions
   required for SR support for IPv6 data plane in the Path Computation
   Element communication Protocol(PCEP).


  


The IETF Secretariat



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

Re: [Pce] Proposed PCE WG Charter update

[Cheng Li]

Hi Dhruv,

Agree with you, so all looks good to me.

Thanks,
Cheng


From: Dhruv Dhody 
Sent: Monday, June 26, 2023 4:58 PM
To: Cheng Li 
Cc: pce@ietf.org
Subject: Re: [Pce] Proposed PCE WG Charter update

Hi Cheng,

On Mon, Jun 26, 2023 at 12:24 PM Cheng Li 
mailto:c...@huawei.com>> wrote:
Hi Chairs,

It looks good to me. It is great to see SR/SRv6 is added into the charter. I am 
wondering that some new features may be mentioned as well if possible. We see 
some new WGs are formed in RTG area, such as TVR, CATS and SAVNET. I am not 
sure that they will have some related extensions or not, but I tend to believe 
that they will.

When that time comes, it would be good to do a quick recharter when some 
concrete work is proposed and garner support in the WG. It is better to keep 
the charter tight rather than open ended in this update.



BTW, happy to see that we set a deadline for SRv6 PCEP Extension draft, authors 
will work on this more, and try to address all comments shortly. Update can be 
made very soon.


Thanks Cheng!

- Dhruv


Thanks,
Cheng

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Wednesday, June 21, 2023 1:38 PM
To: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] Proposed PCE WG Charter update

Hi WG,

The PCE WG charter (-07) was last updated in 2014. Your chairs and AD discussed 
the need to bring the charter up to date. We have made a proposed small update 
(-08) and placed it in our WG's Github - https://github.com/ietf-wg-pce/charter

A diff of the changes can be seen at - 
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-07.txt&difftype=--html&url2=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-08.txt

We request the WG to review the proposed charter update. We suggest using the 
mailing list for discussion and proposing substantial changes. Minor edits may 
also be suggested via PR directly on the GitHub.

Please provide all your comments before 5th July. We would then forward the 
request to our AD.

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

Re: [Pce] Proposed PCE WG Charter update

[Cheng Li]

Hi Chairs,

It looks good to me. It is great to see SR/SRv6 is added into the charter. I am 
wondering that some new features may be mentioned as well if possible. We see 
some new WGs are formed in RTG area, such as TVR, CATS and SAVNET. I am not 
sure that they will have some related extensions or not, but I tend to believe 
that they will.

BTW, happy to see that we set a deadline for SRv6 PCEP Extension draft, authors 
will work on this more, and try to address all comments shortly. Update can be 
made very soon.

Thanks,
Cheng

From: Pce  On Behalf Of Dhruv Dhody
Sent: Wednesday, June 21, 2023 1:38 PM
To: pce@ietf.org
Subject: [Pce] Proposed PCE WG Charter update

Hi WG,

The PCE WG charter (-07) was last updated in 2014. Your chairs and AD discussed 
the need to bring the charter up to date. We have made a proposed small update 
(-08) and placed it in our WG's Github - https://github.com/ietf-wg-pce/charter

A diff of the changes can be seen at - 
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-07.txt&difftype=--html&url2=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-08.txt

We request the WG to review the proposed charter update. We suggest using the 
mailing list for discussion and proposing substantial changes. Minor edits may 
also be suggested via PR directly on the GitHub.

Please provide all your comments before 5th July. We would then forward the 
request to our AD.

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

Re: [Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor

[Cheng Li]

Thanks Julien!

Yes, it has been a long time. I support the adoption as an author. The feature 
is really useful and needed for stateful PCEP, and the text is ready for WG 
adoption.  I have a concern that we may need to move this draft faster 😊

Thanks,
Cheng



-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Tuesday, June 20, 2023 3:47 PM
To: pce@ietf.org
Subject: [Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor

Hi all,

It has been a while since draft-dhody-pce-stateful-pce-vendor started to 
document how to extend the scope of RFC 7470. It is now time to consider its 
adoption by the WG.
Do you think draft-dhody-pce-stateful-pce-vendor-16 [1] is ready to become a 
PCE work item? Please express your support and/or concerns using the mailing 
list.

Thanks,

Dhruv & Julien


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

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-dhody-pce-stateful-pce-vendor

[Cheng Li]

Hi Julien,

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

Thanks,
Cheng


From: julien.meu...@orange.com 
Sent: Tuesday, June 20, 2023 3:52 PM
To: draft-dhody-pce-stateful-pce-ven...@ietf.org
Cc: pce@ietf.org
Subject: IPR Poll on draft-dhody-pce-stateful-pce-vendor

Hi Authors,

In preparation for WG adoption on this draft, we'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,

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

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Cheng Li]

I support the WGLC. The draft has been adopted for a long time, it should move 
forward, and I do not have concerns of the draft.

Thanks,
Cheng


From: Pce  On Behalf Of Dhruv Dhody
Sent: Wednesday, May 17, 2023 6:16 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-pcep-extension-native...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-extension-native-ip-20 [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 Wednesday 31st May 2023. We will also notify the IDR WG 
about this WGLC.

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-pcep-extension-native-ip/
___
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

[Cheng Li]

Hi Adrian,

Sorry for my delay. Please see my reply inline.

You can find the modifications and diff here: 
https://github.com/muzixing/IETF-PCEP-SRV6/commit/56834cd1b09eacee0ef48e874b48956438ae1333?diff=split

Thanks,
Cheng



-Original Message-
From: Adrian Farrel  
Sent: Tuesday, March 7, 2023 3:39 AM
To: Cheng Li ; julien.meu...@orange.com; pce@ietf.org
Cc: Lizhenbin 
Subject: RE: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

> Many thanks for your comments, I have accepted most of the comments 
> from you, and would like to discuss with you about the rest. Please 
> see my reply inline.

Great. Thanks, Cheng. Continuing the discussion in line.
Snipped all of the resolved stuff.

> Because we have a lots of comments. It may be good to address them by 
> several updates. So we can close completed comments and work on the 
> remain ones.

Of course.
I'm sure you can be relied on to keep track of what you still have to address.

A

===

4.1.1

   If a PCEP speaker includes PST=3 (early allocated by
   IANA) in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it
   MUST also include the SRv6-PCE-CAPABILITY sub-TLV inside the PATH-
   SETUP-TYPE-CAPABILITY TLV.

Two questions:

   a. What happens if PST=3 is present but SRv6-PCE-CAPABILITY is
  missing?
[Cheng2] Please see 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6-16#section-5.1
 it will be treated as an error.
"
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list 
containing PST=3, but the SRv6-PCE-CAPABILITY sub-TLV is absent, then the PCEP 
speaker MUST send a PCErr message with Error-Type = 10 (Reception of an invalid 
object) and Error-Value = 34 (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST 
then close the PCEP session. If a PCEP speaker receives a 
PATH-SETUP-TYPE-CAPABILITY TLV with an SRv6-PCE-CAPABILITY sub-TLV, but the PST 
list does not contain PST=3, then the PCEP speaker MUST ignore the 
SRv6-PCE-CAPABILITY sub-TLV.
"


   b. What happens if SRv6-PCE-CAPABILITY is present, but PST=3 was not
  included? (You don't say that that is not allowed.)
[Cheng2] See above, the TLV will be ignored.


It's possible that a forward pointer to Section 5 is enough (I didn't 
cross-check this).

[CL] It seems like we need to specify the details of error handling.

[AF] Right! 3% of the function, 30% of the text ;-)

---

4.3.1  Flags

A pointer to Section 9.2 would be useful.
[CL] May not need to do so. Too many pointers I think.

[AF] Well, OK. I won't insist.

---

4.3.1

What is the interaction between the L flag in the subobject header and the S 
bit in the Flags field?
[CL] L flag is for loose path. S flag is saying that the SID value is absent. 
The PCC may allocate a value according to the NAI.

[AF] I see...

   The 'L' Flag: Indicates whether the subobject represents a loose-hop
   (see [RFC3209]).  If this flag is set to zero, a PCC MUST NOT
   overwrite the SID value present in the SRv6-ERO subobject.
   Otherwise, a PCC MAY expand or replace one or more SID values in the
   received SRv6-ERO based on its local policy.

...and...

   *  S: When this bit is set to 1, the SRv6-SID value in the subobject
  body is absent.  In this case, the PCC is responsible for choosing
  the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI
  which, in this case, MUST be present in the subobject.  If the S
  bit is set to 1 then F bit MUST be set to zero.

How can you overwrite the SID value in the SRv6-ERO subobject if it is absent?
[Cheng2]If the ERO subobject is absent, we can not overwrite it. We can 
overwrite it(Actually, it is not overwrite, because the value is not provided) 
only when the ERO subobject presents. The PCC will allocate a SID value for 
this ERO subobject according to the NAI or other info.

---

4.3.1 / 4.3.1.1

Figure 2 shows the "SID Structure" field as 32 bits, but Figure 3 is pretty 
clear that it is 64 bits. I think Figure 2 is broken.

[AF] You didn't comment, but I think it is an easy fix.
[Cheng2]Fixed, 64 bits.
---

4.4.1

Is the SRv6-SID field optional in the RRO subobject? The figure implies it must 
be present, and that would seem pretty reasonable for an RRO.
But the text says all the fields are exactly as in the ERO, and the S flag 
seems to still have meaning.

There is the same problem with the length of the SID structure field.
[Cheng] I think you are right, it must be present. So we will not need S-flag 
any more. Let's see how to handle this.

[AF] OK. Awaiting dsicussions.
[Cheng2] It is optional. Though when the SID value is absent, it looks weird. 
But we can keep it as the same as ERO, which means we can unset S-bit if SRv6 
SID value is required all the time.
We can add "optional" in the figure to sync up with ERO.   
---


5.1

   If a PCE
   receives an SRv6-PCE-CAPABILITY sub-TLV with the X fl

[Pce] Github Repo of PCEP SRv6 draft

[Cheng Li]

Hi PCEers and authors,

I have created a repository of PCEP SRv6 extension draft for future discussion 
and collaboration: https://github.com/muzixing/IETF-PCEP-SRV6

Also, unresolved comments from Adrian, Ketan, and Yinzhen are recorded in 
issues. Will work on the issues with authors ASAP. I recommend us to use this 
for collaboration. 😊

Thanks,
Cheng



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

Re: [Pce] Rtgdir early review of draft-ietf-pce-segment-routing-ipv6-16

[Cheng Li]

Hi Yinzhen,

Thanks for your review and comments. We will discuss with authors and come back 
to you ASAP.

Respect!
Cheng



-Original Message-
From: Yingzhen Qu via Datatracker  
Sent: Tuesday, April 11, 2023 7:46 AM
To: rtg-...@ietf.org
Cc: draft-ietf-pce-segment-routing-ipv6@ietf.org; pce@ietf.org
Subject: Rtgdir early review of draft-ietf-pce-segment-routing-ipv6-16

Reviewer: Yingzhen Qu
Review result: Has Issues

Hello
I have been selected to do a routing directorate “early” review of this draft.
 draft-ietf-pce-segment-routing-ipv6-16 - Path Computation Element  
Communication Protocol (PCEP) Extensions for Segment Routing leveraging the
 IPv6 dataplane

For more information about the Routing Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-pce-segment-routing-ipv6-16
Reviewer: Yingzhen
Review Date: 2023-04-10

Summary:
I have some minor concerns about this document that I think should be resolved 
before it is submitted to the IESG. Comments: The line numbers are from idnits.

The following warning generated by idnits should be fixed:

  ** The abstract seems to contain references ([RFC8664]), which it
 shouldn't.  Please replace those with straight textual mentions of the
 documents in question.

  Checking references for intended status: Proposed Standard
  

 (See RFCs 3967 and 4897 for information about using normative references
 to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC7855' is defined on line 1090, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC8354' is defined on line 1101, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC8666' is defined on line 1112, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC8667' is defined on line 1116, but no explicit
 reference was found in the text

  == Outdated reference: draft-ietf-lsr-isis-srv6-extensions has been
 published as RFC 9352

  == Outdated reference: A later version (-21) exists of
 draft-ietf-pce-pcep-yang-20

# Detailed questions and nits:

120As defined in [RFC8402], Segment Routing (SR) architecture allows
121that the source node to steer a packet through a path indicated by an
Nits:
allows that the source node to

127is called SR-MPLS.  When SR architecture is applied to the IPv6 data
Nits:
When the SR architecture

131A SR path can be derived from an IGP Shortest Path Tree(SPT), but SR-
s/A SR path/An SR path

207SR Path:  IPv6 Segment List (List of IPv6 SIDs representing a path in
208   IPv6 SR domain in the context of this document)
Should this be SRv6 Path?

228LSP State Report (PCRpt) messages defined in defined in [RFC8231].
Nits: extra words

[RFC8664] also defines a new Record Route Object(RR0) called SR-RRO s/RR0/RRO 
(cap “O” not number ”0”)

233This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in the
s/define/defines

296capability.  If a PCEP speaker includes PST=3 in the PST List of the
297PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the SRv6-
298PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV.

324SRv6-PCE-CAPABILITY sub-TLV and the presence of the sub-TLV indicates
325the support for the SRv6 paths in PCEP.
Question:
A bit confusion here: If the presence of the SRv6-PCE-CAPABILITY sub-tlv 
indicates the support of the SRv6 paths, does it mean this SRv6-PCE-CAPABILITY 
sub-tlv can exist without PST=3?

353 4.2.  The RP/SRP Object

355In order to indicate that the path is for SRv6, any RP or SRP object
356MUST include the PATH-SETUP-TYPE TLV specified in [RFC8408].  This
357document defines a new Path Setup Type (PST=3) for SRv6.
Suggested text:
This document defines a new Path Setup Type (PST=3) for SRv6. In order to 
indicate that the path is for SRv6, any RP or SRP object MUST include the 
PATH-SETUP-TYPE TLV as specified in [RFC8408], where PST is set to 3.

362inclusion in the in ERO.
Nits

462associated with the SRv6 SIDs.  This information is optional.  This
463information is optional.
Nits: Duplicate sentences

467SRv6 SID: SRv6 Identifier is an 128-bit IPv6 addresses representing
s/addresses/address

473At least one of the SRv6-SID or the NAI MUST be included in the
s/one of the/one

533PCE could also be used for verification and the automation for
534securing the SRv6 domain by provisioning filtering rules at SR domain
535boundaries as described in Section 5 of [RFC8754].
Suggested text:
PCE can also be utilized to verify and automate the security of the SRv6 domain 
by provisioning filtering rules at the domain boundaries as described in 
Section 5 of [RFC8754].

545To allow for future compa

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

[Cheng Li]

Hi Chongfeng,

We have addressed your comments in the latest version, please review the draft, 
thank you for your supports!

BR,
Cheng




The IETF datatracker status page for this Internet-Draft is:

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



There is also an HTML version available at:

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-16.html



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-16


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Cheng Li
Sent: Monday, February 20, 2023 9:41 AM
To: Chongfeng Xie ; julien.meu...@orange.com; pce 

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

Thank you Chongfeng, will fix it next revision.

BR,
Cheng


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Chongfeng Xie
Sent: Friday, February 17, 2023 9:05 PM
To: julien.meu...@orange.com<mailto:julien.meu...@orange.com>; pce 
mailto:pce@ietf.org>>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15


Hi folks,

This draft provides the extension of PCEP to support SRv6,  I support its 
publication. Thanks for the authors' work.

In addtion, there is one nit that should be fixed in section one.

s/IPV6/IPv6

Best regards
Chongfeng




xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>

From: julien.meu...@orange.com<mailto:julien.meu...@orange.com>
Date: 2023-02-14 01:38
To: pce@ietf.org<mailto: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 Last Call for draft-ietf-pce-segment-routing-ipv6-15

[Cheng Li]

Hi Quan,

We have addressed your comments in the latest version, please check it.

Thanks,
Cheng




The IETF datatracker status page for this Internet-Draft is:

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



There is also an HTML version available at:

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-16.html



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-16


From: xiong.q...@zte.com.cn [mailto:xiong.q...@zte.com.cn]
Sent: Tuesday, February 28, 2023 3:25 PM
To: d...@dhruvdhody.com
Cc: Cheng Li ; pce@ietf.org; 
draft-chen-pce-sr-mpls-sid-verificat...@ietf.org; Zhangka 
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15




Hi Dhruv,



Thanks for your reply!

I agree with you and it is much better to align with SR-MPLS using 
LSP-ERROR-CODE TLV.



Best Regards,

Quan
Original
From: DhruvDhody mailto:d...@dhruvdhody.com>>
To: 熊泉00091065;
Cc: c...@huawei.com<mailto:c...@huawei.com> 
mailto:c...@huawei.com>>;pce@ietf.org 
mailto:pce@ietf.org>>;draft-chen-pce-sr-mpls-sid-verificat...@ietf.org
 
mailto:draft-chen-pce-sr-mpls-sid-verificat...@ietf.org>>;zhan...@huawei.com
 mailto:zhan...@huawei.com>>;
Date: 2023年02月27日 13:06
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15
Hi Quan, Cheng,

I think it is best if this is aligned with SR-MPLS i.e this draft- 
https://datatracker.ietf.org/doc/draft-chen-pce-sr-mpls-sid-verification/

That draft suggests using LSP-ERROR-CODE TLV.
We can move the IANA allocation to this document as it is nearing WGLC and the 
SR-MPLS draft can simply reuse it! Thoughts?

Thanks!
Dhruv




On Tue, Feb 21, 2023 at 9:16 AM 
mailto:xiong.q...@zte.com.cn>> wrote:

Hi Cheng,



Thanks for your reply!

The suggested text maybe like this following shown.

"  *  V: When this bit is set to 1, the PCC should perform the SID verification 
in validity of an Explicit Candidate Path as described in as per Section 5.1 of 
 [RFC9256]. When a segment list of an explicit candidate path be invalid, a 
PCErr message should be sent. "

I am not sure about the last PCEP error part. Maybe the PCC should notify the 
PCE when the candidate path is invalid.



Best Regards,

Quan








Original
From: ChengLi mailto:c...@huawei.com>>
To: 
熊泉00091065;julien.meu...@orange.com<mailto:00091065%3bjulien.meu...@orange.com> 
mailto:julien.meu...@orange.com>>;
Cc: pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>;
Date: 2023年02月20日 15:14
Subject: RE: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15
Hi Quan,

The usage is the same as defined in RFC9256. Do you have any suggested text?

Thanks,
Cheng


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>] On Behalf 
Of xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn>
Sent: Thursday, February 16, 2023 5:16 PM
To: julien.meu...@orange.com<mailto:julien.meu...@orange.com>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

Dear PCE WG,

I support the WG LC of this draft. I reviewed this document in details and I 
think it is useful and reasonable for SRv6 networks with PCEP extension.
Thanks the authors for the well-written draft and I have a suggestion for 
section 4.3.1 with text "V: The "SID verification" bit usage is as per Section 
5.1 of  [RFC9256]." Maybe it is better to add more description on how to 
use the V bit for SID verification.

Best Regards,
Quan






<<[Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15
<mailto:julien.meu...@orange.com> Mon, 13 February 
2023 17:38 UTCShow header <https://datatracker.ietf.org/doc/draft-<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce


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


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

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

[Cheng Li]

Hi Adrian, 

Many thanks for your comments, I have accepted most of the comments from you, 
and would like to discuss with you about the rest. Please see my reply inline.

Because we have a lots of comments. It may be good to address them by several 
updates. So we can close completed comments and work on the remain ones.

Thanks
Cheng




The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-16.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-16




-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, February 21, 2023 5:14 AM
To: julien.meu...@orange.com; pce@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

Hi,

Here is my WG last call review of this document. Thanks to the authors for all 
of the work that has gone in.

[A note for the chairs: Was this last call shared with SPRING?]

Cheers,
Adrian

===

Abstract

   The Source Packet Routing in Networking (SPRING) architecture

In fact, although RFCs 7855, 8354, and 8355 talk about "Source Packet Routing 
in Networking (SPRING)", the architecture document (RFC 8402) is the "Segment 
Routing Architecture."

[CL]done

---

Abstract

   It depends only on "segments"

As it is a new paragraph, you need to clarify what "it" is. Or maybe move this 
sentence to the previous paragraph so that para 2 begins "A Segment Routed 
Path..."

[CL]done
---

Abstract

s/forwarding plane/forwarding planes/(twice)
s/support for IPv6 data plane in/support for the IPv6 data plane in the/
[CL]done
---

Abstract

OLD
   The PCEP extension and mechanism to support SR-MPLS
   is described in RFC 8664.
NEW
   The PCEP extensions and mechanisms to support SR-MPLS
   are described in RFC 8664.
END
[CL]done
---

Abstract

I think the final sentence is superfluous (or confusing).
Probably this is a repeat of "This document describes the extensions required 
for SR support for IPv6 data plane in Path Computation Element communication 
Protocol (PCEP)."
[CL]done, deleted.
---

1.

s/Locater/Locator/
s/The list of segment/The list of segments/

---
[CL]done
1.

   Upon completion of a segment, a pointer in the new
   routing header is incremented and indicates the next segment.

Not so new anymore!
Try...

   Upon completion of a segment, a pointer in the SRH
   is incremented and indicates the next segment.
[CL]done
---

1.

   Segment Routing use cases are described in [RFC7855] and [RFC8354].
   Segment Routing protocol extensions are defined in [RFC8667], and
   [RFC8666].

There is nothing untrue in this paragraph. But what does it add? The use cases 
aren't mentioned anywhere in the document, and the protocol elements aren't 
used.

I'd just remove the paragraph.
[CL]done. Agree.
---

1.

   As per [RFC8754], an SRv6 Segment identifier is an 128-bit value.
   "SRv6 SID" or simply "SID" are often used as a shorter reference for
   "SRv6 Segment".  Further details are in an illustration provided in
   [RFC8986].

This duplicates and somewhat modifies where the first paragraph says...

   An ordered list of segments
   is encoded as an ordered list of IPv6 addresses in the routing
   header.

I suggest you try to fold this short paragraph into the first paragraph and 
clarify the difference between "an 128-bit value" and "IPv6 address"

[CL]done. I made a modification of the intro part, it was not clear in the 
current revision(15).
---

1.

   The SR is applied to IPV6 forwarding
   plane using Source Routing Header (SRH) [RFC8754].

You've already said this in the first paragraph
[CL]done
---

1.

   A SR path can be
   derived from an IGP Shortest Path Tree (SPT), but SR-TE paths may not
   follow IGP SPT.

a. You have just introduced "SR-TE". You need to expand it as "Segment
   Routing Traffic-Engineering".

b. Is there actually any difference between an SR path and an SR-TE 
   path? If so, you might add it to Section 2 after the definition of
   "SR Path".

c. Notwithstanding RFC 8664, s/may/might/ to avoid confusion with the
   normal English "you may not do it!"

[CL]done

---

1.

s/SR-TE LSP for MPLS data plane/SR-TE LSP for the MPLS data plane/ s/support SR 
for IPv6 data plane/support SR for the IPv6 data plane/ s/either stateful or a 
stateless PCE/either a stateful or stateless PCE/
[CL]done
---

2.

s/equivalent to a SRv6 Path/equivalent to an SRv6 Path/
[CL]done
---

3.

s/operations for PCEP speakers is/operations for PCEP speakers are/
[CL]done
---

3.

   SR-capable PCEP speakers should be able to generate and/or process
   such an ERO subobject.

"should be able to" ??

Maybe...

   SR-capable PCEP speakers can generate or process
   such an ERO subobject.
[CL]done
---

3.

   This document define 

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

[Cheng Li]

- the draft(s) you want to discuss: draft-ietf-pce-segment-routing-ipv6
- the expected presenter name: Cheng Li
- will you be attending in-person or remote: In-person
- the requested duration, including question time as part of the slot:10-15 mins
- the reason why you want to be on the agenda; What do you want to achieve? Why 
is a presentation necessary to achieve it : Summary of WGLC and tell people 
that we should move forward to RFC



发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Dhruv Dhody
发送时间: 2023年2月27日 13:27
收件人: pce@ietf.org
抄送: pce-chairs 
主题: [Pce] Call for slot in the PCE WG at IETF 116

Hi,

The PCE WG would be meeting during the IETF 116 
[1<https://datatracker.ietf.org/meeting/116/agenda.html>] week. If you need 
agenda time to progress some work, please send a slot request directly to the 
chairs/secretary mailto:pce-cha...@ietf.org>> by Monday, 
March 13th by including:

- the draft(s) you want to discuss,
- the expected presenter name,
- will you be attending in-person or 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 on the mailing list. The last date to submit drafts is Monday, March 
13th [2<https://datatracker.ietf.org/meeting/important-dates/>]. Also, let us 
know if you have requested agenda time in a different session for the same 
topic.

Thanks!
PCE Chairs & Secretary

[1] https://datatracker.ietf.org/meeting/116/agenda.html
[2] https://datatracker.ietf.org/meeting/important-dates/
___
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

[Cheng Li]

Hello Adrian,

Many thanks for your comments, brilliant!

I am preparing a update to address your comments and other guys' comments 
together, please wait for few days.

Cheers,
Cheng



-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, February 21, 2023 5:14 AM
To: julien.meu...@orange.com; pce@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

Hi,

Here is my WG last call review of this document. Thanks to the authors for all 
of the work that has gone in.

[A note for the chairs: Was this last call shared with SPRING?]

Cheers,
Adrian

===

Abstract

   The Source Packet Routing in Networking (SPRING) architecture

In fact, although RFCs 7855, 8354, and 8355 talk about "Source Packet Routing 
in Networking (SPRING)", the architecture document (RFC 8402) is the "Segment 
Routing Architecture."

---

Abstract

   It depends only on "segments"

As it is a new paragraph, you need to clarify what "it" is. Or maybe move this 
sentence to the previous paragraph so that para 2 begins "A Segment Routed 
Path..."

---

Abstract

s/forwarding plane/forwarding planes/(twice)
s/support for IPv6 data plane in/support for the IPv6 data plane in the/

---

Abstract

OLD
   The PCEP extension and mechanism to support SR-MPLS
   is described in RFC 8664.
NEW
   The PCEP extensions and mechanisms to support SR-MPLS
   are described in RFC 8664.
END

---

Abstract

I think the final sentence is superfluous (or confusing).
Probably this is a repeat of "This document describes the extensions required 
for SR support for IPv6 data plane in Path Computation Element communication 
Protocol (PCEP)."

---

1.

s/Locater/Locator/
s/The list of segment/The list of segments/

---

1.

   Upon completion of a segment, a pointer in the new
   routing header is incremented and indicates the next segment.

Not so new anymore!
Try...

   Upon completion of a segment, a pointer in the SRH
   is incremented and indicates the next segment.

---

1.

   Segment Routing use cases are described in [RFC7855] and [RFC8354].
   Segment Routing protocol extensions are defined in [RFC8667], and
   [RFC8666].

There is nothing untrue in this paragraph. But what does it add? The use cases 
aren't mentioned anywhere in the document, and the protocol elements aren't 
used.

I'd just remove the paragraph.

---

1.

   As per [RFC8754], an SRv6 Segment identifier is an 128-bit value.
   "SRv6 SID" or simply "SID" are often used as a shorter reference for
   "SRv6 Segment".  Further details are in an illustration provided in
   [RFC8986].

This duplicates and somewhat modifies where the first paragraph says...

   An ordered list of segments
   is encoded as an ordered list of IPv6 addresses in the routing
   header.

I suggest you try to fold this short paragraph into the first paragraph and 
clarify the difference between "an 128-bit value" and "IPv6 address"

---

1.

   The SR is applied to IPV6 forwarding
   plane using Source Routing Header (SRH) [RFC8754].

You've already said this in the first paragraph

---

1.

   A SR path can be
   derived from an IGP Shortest Path Tree (SPT), but SR-TE paths may not
   follow IGP SPT.

a. You have just introduced "SR-TE". You need to expand it as "Segment
   Routing Traffic-Engineering".

b. Is there actually any difference between an SR path and an SR-TE 
   path? If so, you might add it to Section 2 after the definition of
   "SR Path".

c. Notwithstanding RFC 8664, s/may/might/ to avoid confusion with the
   normal English "you may not do it!"

---

1.

s/SR-TE LSP for MPLS data plane/SR-TE LSP for the MPLS data plane/ s/support SR 
for IPv6 data plane/support SR for the IPv6 data plane/ s/either stateful or a 
stateless PCE/either a stateful or stateless PCE/

---

2.

s/equivalent to a SRv6 Path/equivalent to an SRv6 Path/

---

3.

s/operations for PCEP speakers is/operations for PCEP speakers are/

---

3.

   SR-capable PCEP speakers should be able to generate and/or process
   such an ERO subobject.

"should be able to" ??

Maybe...

   SR-capable PCEP speakers can generate or process
   such an ERO subobject.

---

3.

   This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in the
   ERO and the RRO respectively to carry the SRv6 SID (IPv6 Address).

Should the previous paragraph have talked about the RRO?

---

3.1

   In SR networks, an ingress node of an SR path appends all outgoing
   packets with an SR header consisting of a list of SIDs (IPv6 Prefix
   in case of SRv6).

a. s/SR header/SRH/

b. The SRH is only used for SRv6, so this text is a bit mixed-up

c. Isn't there technically a case where only one SID is present so the
   SRH is not needed (the SID is put in the DA field of the 
   encapsulating IPv6 header)?

---

3.1

OLD
   For the use of IPv6 in control plane only with MPLS data plane,
   mechanism remains the same as specified in [RFC8664].
NEW
   For the use of an IPv6 control

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

[Cheng Li]

OK, good, I will work on it to prepare a update ASAP.

Cheng


From: xiong.q...@zte.com.cn [mailto:xiong.q...@zte.com.cn]
Sent: Tuesday, February 28, 2023 3:25 PM
To: d...@dhruvdhody.com
Cc: Cheng Li ; pce@ietf.org; 
draft-chen-pce-sr-mpls-sid-verificat...@ietf.org; Zhangka 
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15




Hi Dhruv,



Thanks for your reply!

I agree with you and it is much better to align with SR-MPLS using 
LSP-ERROR-CODE TLV.



Best Regards,

Quan
Original
From: DhruvDhody mailto:d...@dhruvdhody.com>>
To: 熊泉00091065;
Cc: c...@huawei.com<mailto:c...@huawei.com> 
mailto:c...@huawei.com>>;pce@ietf.org 
mailto:pce@ietf.org>>;draft-chen-pce-sr-mpls-sid-verificat...@ietf.org
 
mailto:draft-chen-pce-sr-mpls-sid-verificat...@ietf.org>>;zhan...@huawei.com
 mailto:zhan...@huawei.com>>;
Date: 2023年02月27日 13:06
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15
Hi Quan, Cheng,

I think it is best if this is aligned with SR-MPLS i.e this draft- 
https://datatracker.ietf.org/doc/draft-chen-pce-sr-mpls-sid-verification/

That draft suggests using LSP-ERROR-CODE TLV.
We can move the IANA allocation to this document as it is nearing WGLC and the 
SR-MPLS draft can simply reuse it! Thoughts?

Thanks!
Dhruv




On Tue, Feb 21, 2023 at 9:16 AM 
mailto:xiong.q...@zte.com.cn>> wrote:

Hi Cheng,



Thanks for your reply!

The suggested text maybe like this following shown.

"  *  V: When this bit is set to 1, the PCC should perform the SID verification 
in validity of an Explicit Candidate Path as described in as per Section 5.1 of 
 [RFC9256]. When a segment list of an explicit candidate path be invalid, a 
PCErr message should be sent. "

I am not sure about the last PCEP error part. Maybe the PCC should notify the 
PCE when the candidate path is invalid.



Best Regards,

Quan








Original
From: ChengLi mailto:c...@huawei.com>>
To: 
熊泉00091065;julien.meu...@orange.com<mailto:00091065%3bjulien.meu...@orange.com> 
mailto:julien.meu...@orange.com>>;
Cc: pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>;
Date: 2023年02月20日 15:14
Subject: RE: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15
Hi Quan,

The usage is the same as defined in RFC9256. Do you have any suggested text?

Thanks,
Cheng


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>] On Behalf 
Of xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn>
Sent: Thursday, February 16, 2023 5:16 PM
To: julien.meu...@orange.com<mailto:julien.meu...@orange.com>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

Dear PCE WG,

I support the WG LC of this draft. I reviewed this document in details and I 
think it is useful and reasonable for SRv6 networks with PCEP extension.
Thanks the authors for the well-written draft and I have a suggestion for 
section 4.3.1 with text "V: The "SID verification" bit usage is as per Section 
5.1 of  [RFC9256]." Maybe it is better to add more description on how to 
use the V bit for SID verification.

Best Regards,
Quan






<<[Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15
<mailto:julien.meu...@orange.com> Mon, 13 February 
2023 17:38 UTCShow header <https://datatracker.ietf.org/doc/draft-<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce


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


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

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

[Cheng Li]

Hi Quan,

The usage is the same as defined in RFC9256. Do you have any suggested text?

Thanks,
Cheng


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of xiong.q...@zte.com.cn
Sent: Thursday, February 16, 2023 5:16 PM
To: julien.meu...@orange.com
Cc: pce@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

Dear PCE WG,

I support the WG LC of this draft. I reviewed this document in details and I 
think it is useful and reasonable for SRv6 networks with PCEP extension.
Thanks the authors for the well-written draft and I have a suggestion for 
section 4.3.1 with text "V: The "SID verification" bit usage is as per Section 
5.1 of  [RFC9256]." Maybe it is better to add more description on how to 
use the V bit for SID verification.

Best Regards,
Quan






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

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

[Cheng Li]

Thank you Chongfeng, will fix it next revision.

BR,
Cheng


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Chongfeng Xie
Sent: Friday, February 17, 2023 9:05 PM
To: julien.meu...@orange.com; pce 
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15


Hi folks,

This draft provides the extension of PCEP to support SRv6,  I support its 
publication. Thanks for the authors' work.

In addtion, there is one nit that should be fixed in section one.

s/IPV6/IPv6

Best regards
Chongfeng




xie...@chinatelecom.cn

From: julien.meu...@orange.com
Date: 2023-02-14 01:38
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] IPR Poll on draft-ietf-pce-segment-routing-ipv6-15

[Cheng Li]

Hi Hari,

Thank you for your notification.

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

Thanks,
Cheng


From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Tuesday, February 14, 2023 11:21 AM
To: preje...@rtbrick.com; msiva...@gmail.com; Cheng Li ; Mike 
Koldychev (mkoldych) ; Mahend Negi ; 
zhu...@chinatelecom.cn
Cc: pce@ietf.org
Subject: IPR Poll on draft-ietf-pce-segment-routing-ipv6-15


Hi Authors,

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

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

with IETF IPR rules.

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

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

in accordance with IETF IPR rules.



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

disclosed to the IETF.



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

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

timely manner.



Thanks,

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

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

[Cheng Li]

Finally! Thank you Julien!  LOL.

I support the WGLC as an author and editor.  Any comments are welcome, will try 
to address them ASAP.

Thanks,
Cheng



-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] IPR Poll for draft-li-pce-pcep-pmtu-05

[Chengli (Cheng Li)]

Sorry for my delay due to Holiday cut-off.



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

in accordance with IETF IPR rules.


Cheng


From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Tuesday, March 29, 2022 5:32 AM
To: Pengshuping (Peng Shuping) ; 
luc-fabrice.ndi...@mtn.com; Chengli (Cheng Li) ; 
hanliu...@chinamobile.com
Cc: pce@ietf.org
Subject: IPR Poll for draft-li-pce-pcep-pmtu-05


Hi Authors,

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

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

with IETF IPR rules.

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

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

in accordance with IETF IPR rules.



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

disclosed to the IETF.



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

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

timely manner.



Thanks,

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

Re: [Pce] 答复: Martin Vigoureux's Discuss on draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT)

[Chengli (Cheng Li)]

Thanks Martin!

Respect,
Cheng

-Original Message-
From: Martin Vigoureux [mailto:martin.vigour...@nokia.com] 
Sent: Tuesday, March 15, 2022 5:32 PM
To: Chengli (Cheng Li) ; Dhruv Dhody 
Cc: The IESG ; draft-ietf-pce-binding-label-...@ietf.org; 
pce-chairs ; pce@ietf.org; Julien Meuric 

Subject: Re: 答复: Martin Vigoureux's Discuss on 
draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT)

Cheng, Druv,

sorry for the belated response.
I have reviewed the changes and I'm fine with them.
I'll clear my DISCUSS.

-m

Le 2022-02-10 à 14:44, Chengli (Cheng Li) a écrit :
> Hi Martin and Dhruv,
> 
> Sorry for my delay due to the Lunar tiger new year, and many thanks to Dhruv 
> for your help!
> 
> I have updated the draft according to the recent discussion in the mailing 
> list.
> 
> Hope it can address your comments:
> 
> Respect,
> Cheng
> 
> 
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid
> -13
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-13
> 
> 
> 
> 
> -邮件原件-
> 发件人: Dhruv Dhody [mailto:d...@dhruvdhody.com]
> 发送时间: 2022年2月1日 21:09
> 收件人: Martin Vigoureux 
> 抄送: The IESG ; 
> draft-ietf-pce-binding-label-...@ietf.org; pce-chairs 
> ; pce@ietf.org; Julien Meuric 
> 
> 主题: Re: Martin Vigoureux's Discuss on 
> draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT)
> 
> Hi Martin,
> 
> Considering Cheng would be busy celebrating the Lunar new year (and the year 
> of the tiger), let me take a stab at your comments.
> 
> On Tue, Feb 1, 2022 at 4:06 PM Martin Vigoureux via Datatracker 
>  wrote:
>>
>> Martin Vigoureux has entered the following ballot position for
>> draft-ietf-pce-binding-label-sid-12: Discuss
>>
>> When responding, please keep the subject line intact and reply to all 
>> email addresses included in the To and CC lines. (Feel free to cut 
>> this introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/blog/handling-iesg-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/
>>
>>
>>
>> -
>> -
>> DISCUSS:
>> -
>> -
>>
>> Hi,
>>
>> thank you for this document.
>> I have few points I'd like to discuss. Some might simply arise from 
>> my limited knowledge/expertise in pce. Thank you for your understanding.
>>
>> Section 5 is confusing to me. In my understanding, from a PCE 
>> perspective, an LSP can be in three different situations: state 
>> synched with PCE, delegated to PCE, or initiated by PCE. However, 
>> maybe not all the text applies to the three cases. So, I wonder 
>> whether organizing this section along the lines of what can be done 
>> and not done depending on the situations would help. At least, one 
>> key aspect which is not clear to me is whether the binding value is an 
>> attribute over which control (change/remove) is given to pce in case of 
>> delegation.
>>
> 
> Dhruv: Regarding the formating of section 5, it is common practice in PCE 
> documents to list text based on PCEP messages. The use of messages is 
> dependent on the "situation" i.e. PCRpt for passive; PCRpt & PCUpd for 
> active; PCRpt, PCUpd, & PCInitiate for PCE-initiated. Since the same message 
> can be used for all, it makes sense to list the operations in terms of 
> messages.
> 
> Regarding delegation - Yes, if the LSP is delegated to PCE, PCE can 
> change/remove the binding using the PCUpd message. Note that as described in 
> RFC 8231, PCUpd is still a request from PCE to update and the PCC can always 
> reject it. The same holds true for binding value.
> 
>> Also, I have the impression that there are "error" conditions which 
>> are not
>> described:
>>
>> * how should PCC react (regardless of whether it already has a 
>> binding
>> value) if it receives from PCE an empty TLV with R=1?
>>
>> * how should PCC react if it receives from PCE a TLV with a binding 
>> value (different from the one it has) with R=1?
>>
> 
> Dhruv: Thanks for noticing these, I suggest adding -
> 
> If a PCC receives a PCUpd message with TE-PATH-BINDING TLV where th

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

[Chengli (Cheng Li)]

I have read the latest version of the draft and support the WGLC.

Cheng



发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Dhruv Dhody
发送时间: 2022年2月22日 20:18
收件人: pce@ietf.org
抄送: draft-ietf-pce-vn-associat...@ietf.org; pce-chairs 
主题: [Pce] WGLC for draft-ietf-pce-vn-association-05

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

Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT)

[Chengli (Cheng Li)]

Hi Benjamin,

Thank you for your comments and sorry for my delay. We have updated the draft 
based on the discussion between you and Dhruv.

Regarding the TE-PATH-BINDING TLVs, we think it will be better to keep it and 
add a rationale for how PCE could use. That is Option B in the discussion.
We have added the following text to describe the motivation of needing this TLV.

   The SRv6 SID Structure could be used by the PCE for ease of
   operations and monitoring.  For example, this information could be
   used for validation of SRv6 SIDs being instantiated in the network
   and checked for conformance to the SRv6 SID allocation scheme chosen
   by the operator as described in Section 3.2 of [RFC8986].  In the
   future, PCE could also be used for verification and the automation
   for securing the SRv6 domain by provisioning filtering rules at SR
   domain boundaries as described in Section 5 of [RFC8754].  The
   details of these potential applications are outside the scope of this
   document.

Is it OK for you?

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-13.txt

Thank you again for the help!
Cheng





-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu] 
Sent: Thursday, February 3, 2022 8:19 AM
To: Dhruv Dhody 
Cc: The IESG ; draft-ietf-pce-binding-label-...@ietf.org; 
pce-chairs ; pce@ietf.org; Julien Meuric 

Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-pce-binding-label-sid-12: 
(with DISCUSS and COMMENT)

Hi Dhruv,

On Wed, Feb 02, 2022 at 01:54:46PM +0530, Dhruv Dhody wrote:
>  Hi Ben,
> 
> Thanks for your comprehensive review and comments.
> 
> On Wed, Feb 2, 2022 at 1:14 AM Benjamin Kaduk via Datatracker 
>  wrote:
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/
> >
> >
> >
> > 
> > --
> > DISCUSS:
> > 
> > --
> >
> > (1) I don't think we're currently entirely accurate in our depection 
> > of the properties of BT=3 TE-PATH-BINDING TLVs.  In particular, in 
> > Section 5 we write:
> >
> >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.  This enables the sender to
> >have control of the SRv6 Endpoint Behavior and SID Structure.  A
> >sender MAY choose to set the BT to 2, in which case the receiving
> >implementation chooses how to interpret the SRv6 Endpoint Behavior
> >and SID Structure according to local policy.
> >
> > But this TLV can be sent in several different circumstances -- when 
> > the PCC has allocated the BSID and is reporting it to the PCE, when 
> > the PCE is requesting the PCC to allocate a specific value, when the 
> > PCE has already allocated a specific value from a range controlled 
> > by the PCE, and when the PCE is requesting the PCC to allocate some 
> > value of its own choosing (at least).  I think that only in the "PCE is 
> > requesting a specific value"
> > and "PCE has already allocated a specific value" cases do these 
> > claimed properties hold -- if the PCC is allocating the value then 
> > the interpretation of its internal structure is local to the PCC and 
> > the PCE does not need to know how to interpret the structure in 
> > order for the path to function.
> >
> 
> Dhruv: The idea of PCC reporting the structure could be useful if we 
> want PCE to do some sanity checks over the SID allocation scheme. But 
> the main motivation was to have a single recommended format for SRv6 
> (note that it is not MUST in any case). I see the following way
> forward:
> 
> A: RECOMMENDED used only for PCE allocated value and use MAY for PCC
> B: Keep the current wording but add a rationale for how PCE could use 
> the reported structure
> C: Do nothing
> 
> What makes sense to you? Authors/WG please chime in!

I think both A or B could be workable, depending on the specifics; I'd prefer 
to avoid C, obviously :) Of those three I'd probably pick A myself, but the 
authors+WG are better place to make an informed decision.

> > This also brings up a related topic (and gives me unease about 
> > specifically recommending use of BT=3 as the quoted text does), 
> > which may be familiar to those who participated in the processing of 
> > draft-ietf-lsr-isis-srv6-extensions.
> >
> > In particular, the relationship of SRv6 SIDs to the IPv6 addressing 
> > architecture (RFC 4291) was quite controversial during the 
> > processing of what since became RFC 8986.  I was able to reconcile 
> > the two at the time by virtue of noting that the substructure of the 
> > SID can be considered to be logically local to the node advertising 
> > the SID and therefore not an observable part of the protocol.  In 
> > that sense, the wire-visible us

Re: [Pce] Murray Kucherawy's No Objection on draft-ietf-pce-binding-label-sid-12: (with COMMENT)

[Chengli (Cheng Li)]

Hi Murray,

Sorry for my delay and thank you for your comments. Please review the updated 
draft to see if it works.

Thank you again!
Cheng

Link:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-13




-Original Message-
From: Murray Kucherawy via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, February 3, 2022 12:29 PM
To: The IESG 
Cc: draft-ietf-pce-binding-label-...@ietf.org; pce-cha...@ietf.org; 
pce@ietf.org; julien.meu...@orange.com
Subject: Murray Kucherawy's No Objection on 
draft-ietf-pce-binding-label-sid-12: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-pce-binding-label-sid-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/



--
COMMENT:
--

In Section 1:

   This document specifies an extension to PCEP to manage of binding
   label/SID for both SR and non-SR paths.

I can't parse this sentence.

The SHOULD in Section 8 seems strange; it offers the implementer a choice of 
not allocating the binding label/SID when the PCC has met the stated 
conditions.  Why the choice?  If the SHOULD is meant to cover the "unable to 
allocate" case, I would argue that the SHOULD is not necessary because there's 
no interoperability choice being exercised, and would instead suggest:

   *  To request that the PCE allocate the binding label/SID, a PCC MUST
  set P=1, D=1, and include an empty TE-PATH-BINDING TLV in PCRpt
  message.  The PCE will attempt to allocate it and respond to the PCC with
  PCUpd message including the allocated binding label/SID in the TE-
  PATH-BINDING TLV and P=1, D=1 in the LSP object.  If the PCE is
  unable to allocate, it MUST send a PCErr message with Error-Type =
  TBD2 ("Binding label/SID failure") and Error-Value = TBD5 ("Unable
  to allocate a new binding label/SID").

Thank you for including Section 9.



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

[Pce] 答复: Lars Eggert's No Objection on draft-ietf-pce-binding-label-sid-12: (with COMMENT)

[Chengli (Cheng Li)]

Hi Lars,

Many thanks for your comments and sorry for my delay due to the SPRING festival.

We have updated the draft to address your comments. Please review it.

Thanks,
Cheng

Link:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-13




-邮件原件-
发件人: Lars Eggert via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2022年2月3日 18:18
收件人: The IESG 
抄送: draft-ietf-pce-binding-label-...@ietf.org; pce-cha...@ietf.org; 
pce@ietf.org; julien.meu...@orange.com; julien.meu...@orange.com
主题: Lars Eggert's No Objection on draft-ietf-pce-binding-label-sid-12: (with 
COMMENT)

Lars Eggert has entered the following ballot position for
draft-ietf-pce-binding-label-sid-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/



--
COMMENT:
--

Thanks to Theresa Enghardt for their General Area Review Team (Gen-ART) review 
(https://mailarchive.ietf.org/arch/msg/gen-art/IyiRN3TEd1p_yEs0UviVwhgH04Q).

---
All comments below are about very minor potential issues that you may choose to 
address in some way - or ignore - as you see fit. Some were flagged by 
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there 
will likely be some false positives. There is no need to let me know what you 
did with these suggestions.

Section 1.2. , paragraph 4, nit:
-binding label/SID, and associted error handling.
+binding label/SID, and associated error handling.
+ +

Section 1.2. , paragraph 2, nit:
> and PCE can use this TLV, how they can can allocate a binding label/SID, and
>^^^
Possible typo: you repeated a word.

Document references draft-ietf-pce-pcep-yang-17, but -18 is the latest 
available revision.

Document references draft-ietf-spring-segment-routing-policy-14, but -16 is the 
latest available revision.



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

[Pce] 答复: Erik Kline's No Objection on draft-ietf-pce-binding-label-sid-12: (with COMMENT)

[Chengli (Cheng Li)]

Hi Erik,

Many thanks for your comments and question, the answer would be [b] {LB=48, 
LN=16, FUN=..., ARG=...}


For clarity, we have added the following text in the draft- 

[RFC8986] defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a locator 
(LOC) is encoded in the L most significant bits of the SID, followed by F bits 
of function (FUNCT) and A bits of arguments (ARG). A locator may be represented 
as B:N where B is the SRv6 SID locator block (IPv6 prefix allocated for SRv6 
SIDs by the operator) and N is the identifier of the parent node instantiating 
the SID called locator node.

Thanks,
Cheng


There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-13



-邮件原件-
发件人: Erik Kline via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2022年2月3日 9:18
收件人: The IESG 
抄送: draft-ietf-pce-binding-label-...@ietf.org; pce-cha...@ietf.org; 
pce@ietf.org; julien.meu...@orange.com; julien.meu...@orange.com
主题: Erik Kline's No Objection on draft-ietf-pce-binding-label-sid-12: (with 
COMMENT)

Erik Kline has entered the following ballot position for
draft-ietf-pce-binding-label-sid-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/



--
COMMENT:
--

[S4.1; question]

* For clarity, when the locator prefix is a /48 and the nodes are each
  allocated a /64, which of these is expected:

[a] {LB=48, LN=64, FUN=..., ARG=...}, or

[b] {LB=48, LN=16, FUN=..., ARG=...}

(where LB + LN = 64)?



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

[Pce] 答复: Martin Vigoureux's Discuss on draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT)

[Chengli (Cheng Li)]

Hi Martin and Dhruv, 

Sorry for my delay due to the Lunar tiger new year, and many thanks to Dhruv 
for your help!

I have updated the draft according to the recent discussion in the mailing 
list. 

Hope it can address your comments:

Respect,
Cheng



There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-13




-邮件原件-
发件人: Dhruv Dhody [mailto:d...@dhruvdhody.com] 
发送时间: 2022年2月1日 21:09
收件人: Martin Vigoureux 
抄送: The IESG ; draft-ietf-pce-binding-label-...@ietf.org; 
pce-chairs ; pce@ietf.org; Julien Meuric 

主题: Re: Martin Vigoureux's Discuss on draft-ietf-pce-binding-label-sid-12: 
(with DISCUSS and COMMENT)

Hi Martin,

Considering Cheng would be busy celebrating the Lunar new year (and the year of 
the tiger), let me take a stab at your comments.

On Tue, Feb 1, 2022 at 4:06 PM Martin Vigoureux via Datatracker 
 wrote:
>
> Martin Vigoureux has entered the following ballot position for
> draft-ietf-pce-binding-label-sid-12: Discuss
>
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to 
> https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/
>
>
>
> --
> DISCUSS:
> --
>
> Hi,
>
> thank you for this document.
> I have few points I'd like to discuss. Some might simply arise from my 
> limited knowledge/expertise in pce. Thank you for your understanding.
>
> Section 5 is confusing to me. In my understanding, from a PCE 
> perspective, an LSP can be in three different situations: state 
> synched with PCE, delegated to PCE, or initiated by PCE. However, 
> maybe not all the text applies to the three cases. So, I wonder 
> whether organizing this section along the lines of what can be done 
> and not done depending on the situations would help. At least, one key 
> aspect which is not clear to me is whether the binding value is an attribute 
> over which control (change/remove) is given to pce in case of delegation.
>

Dhruv: Regarding the formating of section 5, it is common practice in PCE 
documents to list text based on PCEP messages. The use of messages is dependent 
on the "situation" i.e. PCRpt for passive; PCRpt & PCUpd for active; PCRpt, 
PCUpd, & PCInitiate for PCE-initiated. Since the same message can be used for 
all, it makes sense to list the operations in terms of messages.

Regarding delegation - Yes, if the LSP is delegated to PCE, PCE can 
change/remove the binding using the PCUpd message. Note that as described in 
RFC 8231, PCUpd is still a request from PCE to update and the PCC can always 
reject it. The same holds true for binding value.

> Also, I have the impression that there are "error" conditions which 
> are not
> described:
>
> * how should PCC react (regardless of whether it already has a binding 
> value) if it receives from PCE an empty TLV with R=1?
>
> * how should PCC react if it receives from PCE a TLV with a binding 
> value (different from the one it has) with R=1?
>

Dhruv: Thanks for noticing these, I suggest adding -

If a PCC receives a PCUpd message with TE-PATH-BINDING TLV where the R flag is 
set to 1, but either the binding value is missing (empty TE-PATH-BINDING TLV) 
or the binding value is incorrect, it MUST send a PCErr message with Error-Type 
= TBD2 ("Binding label/SID failure") and Error Value = TBD6 ("Unable to remove 
the binding value").

> * how should PCC react if it receives from PCE a single TLV with a 
> binding value different from the one it has and with R=0?
>

Dhruv: The existing binding values which remain unchanged are optional to be 
included. The text uses MAY for them. So in this case, the PCC would try to 
allocate an additional binding value.

> The draft seems silent about how to deal with multiple identical 
> TE-PATH-BINDING TLVs. Use any? Throw an error?
>

Dhruv: I guess use any. Do you suggest adding text for this? I am not sure if I 
have seen such text in similar cases.

> The draft allows multiple TE-PATH-BINDING TLVs to be sent but in my 
> view falls short to describe the associated expectations. Ultimately 
> the binding value is something that will end-up programmed in the 
> data-plane (or at least reserved in the control plane) but maybe not 
> all systems have the same capabilities in these domains. Since PCE 
> doesn't know these capabilities, I think, how should be handled the 
> situation where PCE requests N values but the no

Re: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

[Chengli (Cheng Li)]

Support the last call. This work is valuable for sure, and the content is 
stable, so I support to move it forward.

10 years! Respect!

Thanks,
Cheng


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Tuesday, January 18, 2022 9:17 PM
To: pce@ietf.org
Cc: draft-ietf-pce-pcep-stateful-pce-gm...@ietf.org; pce-chairs 

Subject: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-stateful-pce-gmpls-16 [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 1st Feb 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-pcep-stateful-pce-gmpls/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Genart last call review of draft-ietf-pce-binding-label-sid-11

[Chengli (Cheng Li)]

Hi Theresa,

Many thanks for your reply! We have updated to address your comments. Please 
see my reply inline for more information. Hope it address your comments.

Thank you!
Cheng



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




-Original Message-
From: Theresa Enghardt via Datatracker [mailto:nore...@ietf.org] 
Sent: Saturday, January 22, 2022 7:25 AM
To: gen-...@ietf.org
Cc: draft-ietf-pce-binding-label-sid@ietf.org; last-c...@ietf.org; 
pce@ietf.org
Subject: Genart last call review of draft-ietf-pce-binding-label-sid-11

Reviewer: Theresa Enghardt
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-pce-binding-label-sid-11
Reviewer: Theresa Enghardt
Review Date: 2022-01-21
IETF LC End Date: 2022-01-24
IESG Telechat date: Not scheduled for a telechat

Summary: The specification itself looks alright to me, but the document has 
some clarity issues: From the abstract and introduction, it is difficult to 
understand what is actually being specified in the document, so these parts 
should be clarified before publication.

Major issues: None.

Minor issues:

Abstract:

"This document specifies the binding value as an MPLS label or Segment
   Identifier."
Please define the term "binding value" here or later in the document. Is this 
an existing term from prior work or is this a new term introduced in this 
document? Is the above sentence intended to say something like "This document 
specifies the concept of a binding value, which can be either an MPLS label or 
Segment Identifier"? If so, please rephrase. If not, please clarify in what way 
the document "specifies the binding value".

[Cheng] Updated as suggested.


"It further specifies an approach for reporting binding
   label/Segment Identifier (SID)"
Is "binding label/Segment Identifier" the same as "binding value" in the 
previous sentence, or is it the same as a BSID? Is "Segment Identifier (SID)"
the same as Segment Identifier in the previous sentence? Please unify terms 
when referring to the same concept.

[Cheng]Yes and updated.

As the document appears to specify an extension to PCEP, please mention this 
protocol in the abstract. (And/or, if the extension applies to other protocols 
as well, please say so in the abstract.)

[Cheng]Updated.


Introduction:

"As per [RFC8402] SR allows a head-end node to steer a packet flow
   along any path. The head-end node is said to steer a flow into a
   Segment Routing Policy (SR Policy). Further, as per
   [I-D.ietf-spring-segment-routing-policy], an SR Policy is a framework
   that enables the instantiation of an ordered list of segments on a
   node for implementing a source routing policy with a specific intent
   for traffic steering from that node."

As written, this sounds like the second sentence describes the same thing as 
the first sentence, i.e., as if a Segment Routing Policy is what happens when 
the end-end note can steer a packet flow along any path, and the "Further"
makes it sound like the third sentence introduces a separate and new concept.
To me, it seems more likely that the first sentence refers to a different 
concept than the second and third sentence, so the paragraph contrast steering 
along any path VS steering into an SR policy constraining the choice of paths.
If that is true, I think it would help to make explicit which 
sentences/concepts belongs together, e.g., to rephrase this part as: "As per 
[RFC8402] SR allows a head-end node to steer a packet flow
   along any path. To constrain the paths along with a packet flow can be
   steered,
  the head-end note can steer a flow into a
   Segment Routing Policy (SR Policy). As per
   [I-D.ietf-spring-segment-routing-policy], an SR Policy is a framework […]"

[Cheng] Thanks for suggestion, I updated it to - 

As per [RFC8402] SR allows a head-end node to steer a
packet flow along a given path via a Segment Routing 
Policy (SR Policy). As per 
[I-D.ietf-spring-segment-routing-policy], an SR Policy 
is a […]



"In this
   document, binding label/SID is used to generalize the allocation of
   binding value for both SR and non-SR paths."
Consider making it explicit that this sentence talks about terminology (if it 
indeed does): "In this document, the term 'binding label/SID' is used to 
generalize […]"

[Cheng]Sure!

Perhaps it would be good to add terms like 'binding label/SID' and 'binding 
value' to the Terminology section as well.

[Cheng] Added!

Reading the introduction, at times I found it difficult to understand what is 
existing technology, what is new

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

[Chengli (Cheng Li)]

Hi Julien,

Since the text already had WG consensus when it was part of the 
draft-ietf-pce-pcep-flowspec, I would like to support the adoption.

Thank you!
Cheng




-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] AD review of draft-ietf-pce-binding-label-sid-10

[Chengli (Cheng Li)]

Hi John,

Sorry for my delay due to the PTO, have updated the draft to address your 
comments, please take a look of if it works.

Thanks,
Cheng




URL:
https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-11.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-11

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of John Scudder
Sent: Friday, October 1, 2021 4:14 AM
To: Dhruv Dhody 
Cc: pce@ietf.org; draft-ietf-pce-binding-label-...@ietf.org; pce-chairs 

Subject: Re: [Pce] AD review of draft-ietf-pce-binding-label-sid-10

Hi Dhruv,

Thanks for your comments, and some replies in line:

> On Sep 29, 2021, at 4:49 AM, Dhruv Dhody  wrote:

(…snip...)

> ***
> *** 490,495 
> --- 512,546 
>  error, the PCC rejects the PCUpd or PCInitiate message in its
>  entirety and can include the offending TE-PATH-BINDING TLV in the
>  PCEP-ERROR object.
> +
> + Rejecting the message in its entirety makes sense, but it does imply 
> + that an implementation MUST be prepared to unwind any actions it has 
> + taken earlier on the basis of the message. It's a pretty common 
> + pattern for an implementation to take individual actions implied by 
> + a message immediately as they're encountered, which means this 
> + unwinding is potentially non-trivial. For example, suppose a PCE 
> + requires a PCC to allocate three specific binding values, so it 
> + sends a PCUpd containing three TE-PATH-BINDING TLVs. The first one 
> + is successfully allocated, and so is the second, but for some reason 
> + the third is unable to be allocated. Now the PCC must de-allocate 
> + the first two, in addition to sending a TBD2+TBD4 PCErr message and 
> + possibly includes the third TLV in the PCEP-ERROR object.
> + 
> + Also, I guess the PCE must infer that the first two bindings were 
> + not allocated, even though it has only received an error for the third.
> + This would be true even if the PCC implementation doesn't have to do 
> + any de-allocation -- suppose the PCC has a clever implementation 
> + that only commits the actions in the PCUpd once it knows they will 
> + all succeed, it's still the case that the PCE will get an error for 
> + one but must know that the error applies to the others that were 
> + carried in the PCUpd.
> + 
> + Is this analysis correct, or if not, why not? If it's correct, it 
> + seems to me as though it might well be worth devoting a few 
> + sentences to it, unless these issues are already well covered in one 
> + of the foundational RFCs (in which case, I'd appreciate a pointer, I 
> + haven't done a thorough enough review of the normative documents to 
> + catch all such things).
> 
> 
> [Dhruv]: It is a normal practice to reject the whole message in PCEP. Say a 
> PCE sends a PCUpd message for an LSP with multiple updated parameters, one 
> would apply the update only once it has verified all the parameters and send 
> an error in case any are found to be invalid. The PCErr message includes an 
> SRP object that identifies the full PCUpd message is being rejected with the 
> reason for the rejection optionally identified. 
> 
> This was discussed during the WGLC and the conclusion was to reject the whole 
> message in the case of multiple binding TLVs as well. The SRP in PCErr would 
> identify that the complete message is being rejected here as well. 

As long as this is a well-known pattern in the PCE world, that this spec is 
just continuing, I’m fine with letting the text stand without modification.

>  
>  If a PCE wishes to request the withdrawal of a previously reported
>  binding value, it MUST send a PCUpd message with the specific TE-
> ***
> *** 507,513 
> --- 558,573 
> 
> 
>  In some cases, a stateful PCE can request the PCC to allocate any
> +   ^^
>  binding value.  It instructs the PCC by sending a PCUpd message
> +^
> +I don't understand what that means. My *guess* is that you mean
> +the PCE is just saying "hey PCC, please allocate a binding value
> +and tell me what it is".  Is that right?  If so I think this 
> +could be worded even more clearly, perhaps "a stateful PCE may
> +want to request that the PCE allocate a binding value of the PCE's 
> +own choosing"?
> +
> 
> [Dhruv]: It should be PCC's own choosing.

Were you just correcting my comment (to say I should have written “PCC” the 
latter two times, I agree, my mistake), or was your point also to say that yes, 
my guess is correct? If the latter, then as I mentioned, I’d appreciate having 
the wording improved.

> 
> ***
> *** 655,660 
> --- 742,758 
> *  Send a PCErr 

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

[Chengli (Cheng Li)]

Yes, support as an coauthor. Any comments are welcome! 

Thanks Chairs,
Cheng



-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] IPR Poll for draft-dhody-pce-stateful-pce-optional

[Chengli (Cheng Li)]

Hi PCE,



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

in accordance with IETF IPR rules.



Cheng


From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Wednesday, September 22, 2021 12:09 AM
To: Zhenghaomian ; slitkows.i...@gmail.com; Chengli 
(Cheng Li) 
Cc: pce@ietf.org
Subject: IPR Poll for draft-dhody-pce-stateful-pce-optional


Hi Authors,

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

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

with IETF IPR rules.

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

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

in accordance with IETF IPR rules.



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

disclosed to the IETF.



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

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

timely manner.



Thanks,

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

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

[Chengli (Cheng Li)]

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
To: Chengli (Cheng Li) ; 
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 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&#x

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

[Chengli (Cheng Li)]

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

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

[Chengli (Cheng Li)]

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

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

[Chengli (Cheng Li)]

Support as an author, the document has been written for a long time, and I 
think it has  been mature for adoption.

Thanks,
Cheng



-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of julien.meu...@orange.com
Sent: Monday, May 17, 2021 9:41 PM
To: pce@ietf.org
Subject: [Pce] Adoption of draft-litkowski-pce-state-sync

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


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

Re: [Pce] IPR Poll on draft-litkowski-pce-state-sync

[Chengli (Cheng Li)]

Hi WG,



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



Thanks,

Cheng



From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Tuesday, May 18, 2021 12:08 AM
To: Zhenghaomian ; slitkows.i...@gmail.com; 
msiva...@gmail.com; Chengli (Cheng Li) 
Cc: pce@ietf.org
Subject: IPR Poll on draft-litkowski-pce-state-sync


Hi Authors,



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

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

with IETF IPR rules.

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

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

in accordance with IETF IPR rules.



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

disclosed to the IETF.



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

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

timely manner.



Thanks,

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

[Pce] Request for Implementation info of PCEP SRv6 extension

[Chengli (Cheng Li)]

Hi PCE,

We are going to update the PCEP SRv6 extension draft, and we would like to add 
the implementation information of it.

If you have any info, please reply to this email, we will add it the draft.

Many thanks,
Cheng

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

Re: [Pce] WG Adoption of draft-koldychev-pce-multipath-05

[Chengli (Cheng Li)]

Yes, support, the draft is useful for SR Policy.

Cheng


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Wednesday, April 14, 2021 10:52 PM
To: pce@ietf.org
Cc: draft-koldychev-pce-multip...@ietf.org
Subject: [Pce] WG Adoption of draft-koldychev-pce-multipath-05

Hi WG,

This email begins the WG adoption poll for draft-koldychev-pce-multipath-05.

https://datatracker.ietf.org/doc/html/draft-koldychev-pce-multipath-05

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 Wednesday 28th April.

Thanks!
Dhruv & Julien
___
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)

[Chengli (Cheng Li)]

Thanks again for your help!

Cheng



-Original Message-
From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com] 
Sent: Saturday, March 27, 2021 2:42 AM
To: Chengli (Cheng Li) ; julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)

Hi Cheng,

Thanks for clarifying the text in the document. Diff content looks good to me, 
much clearer. Consider my comments resolved.

Thanks!
Andrew

On 2021-03-25, 10:49 PM, "Pce on behalf of Chengli (Cheng Li)" 
 wrote:

Hi Andrew, 

Thanks for your comments, please see my reply inline.

Also, the diff is attached.

Respect,
Cheng




-Original Message-
From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com] 
Sent: Saturday, March 20, 2021 4:21 AM
To: julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 
(and Code Point Allocation)

Hi all,

Overall Support WGLC. It's an important document in the world of SRTE, and 
the document goes to good lengths to describe the various scenarios and 
combinations. 

Only one question I have for the authors and WG, for any further 
clarification on the following text (section 4):


  The absence of TE-PATH-BINDING TLV in PCUpd message
   means that the PCE does not specify a binding value in which case the
   binding value allocation is governed by the PCC's local policy.


I find the "governed by PCC local policy" a bit too vague and could lead to 
implementation interop differences. Assuming a PCInitiated LSP that been 
established with a BSID: If the PCE wants to withdraw the binding SID , I 
interpret the document as the PCE would send a PCUpdate without the TLV, but 
the behaviour is now up to PCC as per that text. if the PCC local 
policy/implementation is to do nothing, how can the PCE explicitly force-remove 
the BSID with a PCUpdate? In a similar manner, If the PCE does not want to 
change the value but PCC local policy is to treat missing TLV as remove, then 
PCE should always send the TLV in every PCUpdate (which I'm okay with) which is 
not stated, otherwise the local policy/implementation may interpret it as a 
removal compared to an implementation which may interpret it as being okay to 
not send the TLV on every PCUpdate since there was "no change". 

In summary: might need a bit of a wording to further detail "PCE wishes to 
withdraw" case. 

[Cheng] You are correct, there was some issues with multiple 
TE-PATH-BINDING TLV. This has been updated. See the diff.

The above text has been updated to - 

   The absence of TE-PATH-BINDING TLV in PCUpd message means that the
   PCE does not specify a binding value in which case any previous
   allocated binding values are withdraw.

Further, the PCC's local policy aspect has been seperated out as - 

   In the absence of any instruction from the PCE, the PCC's local
   policy dictates how the binding allocations are made for a given LSP.

Thanks!


Thanks! 
Andrew

On 2021-03-18, 7:09 AM, "Pce on behalf of julien.meu...@orange.com" 
 wrote:

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 privilegiee

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

[Chengli (Cheng Li)]

To all,

The latest diff of BSID draft is 
https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-07.txt&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt

Sorry for using the wrong diff file.

Thanks,
Cheng



-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Chengli (Cheng Li)
Sent: Friday, March 26, 2021 10:46 AM
To: Aijun Wang ; julien.meu...@orange.com; 
pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)

Hi Aijun,

Many thanks for your comments! Please see my reply inline. The diff is attached.

Respect,
Cheng



-Original Message-
From: Aijun Wang [mailto:wangai...@tsinghua.org.cn] 
Sent: Monday, March 22, 2021 11:57 AM
To: julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: RE: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)

Hi, 

1. The concept of PCC requests the allocating of BSID for a LSP is clear, but 
the scenario that PCE allocate the BSID is not convincible. 
  PCE can request the PCC to allocate the BSID for one LSP. It should not 
allocate the value directly. 


[Cheng]Section 8 is optionally used when PCE is in control of label space 
(PCECC) and would not be used for vanilla stateful PCE.

2. What's the reason to include the BT=3, that is "SRv6 Endpoint Behavior and 
SID Structure"? It is one general information and not close connection to the 
normal usage of BSID. 
[Cheng] This is an alignment with other SIDs. In order to support backward 
compatibility, we want to remain BT2, and introduce a new BT for support SID 
structure. It can be used for future use case.


3. Will it be more clear to define one new bit(R bit) within the Flag field of 
"TE-PATH-BINDING TLV" to indicate clearly the remove of BSID allocation to a 
LSP? Instead of the implicit method that depending on the presence of 
TE-PATH-BINDING TLV as described in current draft? 
[Cheng] It is possible. But there are existing implementations that would get 
impacted.


4. For BT=0, the length is set to 7. How to skip the padding trailing zeros to 
a 4-octet boundary when parsing?
[Cheng] We have updated the description of BT=0 as per Adrian's comment. 
Length=7 and handling of padding is as per RFC5440: 

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

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: pce-boun...@ietf.org  On Behalf Of 
julien.meu...@orange.com
Sent: Thursday, March 18, 2021 7:09 PM
To: pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code 
Point Allocation)

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 distribut

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

[Chengli (Cheng Li)]

Hi Tom, 

Sorry for sending the error diff.

The latest diff is here 
https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-07.txt&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt

Also, Julien has replied to Adrian about the IANA allocation comments. 
The IANA early allocation will be issued without error type at this time.

Thanks,
Cheng



-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of tom petch
Sent: Monday, March 22, 2021 8:14 PM
To: julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)

Separate to my other comments

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

Sent: 18 March 2021 11:08

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.


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




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

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

[Chengli (Cheng Li)]

Oh, Adrian, all, 

some update for comment 4, Regarding multiple TE-PATH-BINDING TLVs, we have 
updated the operation rules as follow.

   In case of multiple TE-PATH-BINDING TLVs, all
   existing instances of TE-PATH-BINDING TLVs MUST always be included in
   the LSP object.  In case of an error condition, the whole message is
   rejected and the resulting PCErr message MAY include the offending
   TE-PATH-BINDING TLV in the PCEP-ERROR object.


Also, the draft has been updated, and the latest diff is here: 
https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-07.txt&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt

Sorry for sending the internal diff version when we handle multiple comments:(

Cheng





-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Chengli (Cheng Li)
Sent: Friday, March 26, 2021 10:27 AM
To: adr...@olddog.co.uk; julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)

Hi Adrian,

Long time no see! Thanks for your valuable comments!  :)

It takes few days to address them, LOL. The latest revision has updated, see 
https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt
https://github.com/dhruvdhody/ietf/blob/master/draft-ietf-pce-binding-label-sid-08.xml

Diff is attached.
Please see my reply inline.

Respect,
Cheng



-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Tuesday, March 23, 2021 6:18 PM
To: julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: RE: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)

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)"?

---

[Cheng] Removed Segment-ID


Abstract

"Such a binding label/SID"
This is the first use of "label". You need some context.

---

[Cheng] Added - "This document specifies the binding value as an MPLS label or 
Segment Identifier."


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.


[Cheng] Updated to identify PCC.  

---

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.

---

[Cheng] How about this - 

   o  BT = 0: The binding value is a 2

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

[Chengli (Cheng Li)]

Hi Tom,

Thanks, please see inline.

Cheng

-Original Message-
From: tom petch [mailto:ie...@btconnect.com] 
Sent: Monday, March 22, 2021 8:02 PM
To: julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)

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

Sent: 18 March 2021 11:08

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


I find the terminology imprecise and in need of tightening up.

S.11.1.1 uses MPLS Label and MPLS Label Stack Entry as does RFC3032 which is as 
it should be.

Elsewhere the I-D uses binding label/SID without ever being precise about its 
meaning.  It needs defining  or expanding to binding MPLS label/SID or probably 
being replaced by something neater.

s.1 uses binding MPLS label; what is the difference?

Binding value is then defined which seems to me to make binding label/SID and 
unnecessary mouthful.

s.3 has binding label or SID as well as MPLS label binding

this section also uses 'MPLS label' - good - but then spoils it by using label 
unqualified

It then uses MPLS label entry which would appear to be a reference to an MPLS 
label stack entry

Likewise label stack entry would appear to mean MPLS label stack entry

s.4 uses MPLS label binding

The problem comes with loose terminology when e.g. a document is up for 
revision and future readers wonder why, if the same concept is being referred 
to, does the terminology keep changing, which sometimes just leads to a waste 
of time, other times to errors in implementation.

Since label has overtones of MPLS whereas SID is clearly SR, then I think you 
need a different term when you mean one or the other.  I think that 'binding 
value' as used in at least one place is a better choice, with an explanation 
thereof early on in the introduction. 'Binding value is used here to refer to 
an MPLS label or an IPv6 SID as appropriate'

[Cheng]I have added - 

In this document, binding label/SID is used to generalize the allocation of 
binding value for both SR and non-SR paths.

Removed - 
- binding MPLS label
- binding label or SID   
- MPLS label binding

Made some other correction. Hope the above clarification and cleanup is enough. 

Also,
- Binding value is the term when refering to the specified value in the TLV 
- binding label/SID is used in the generic sense 
I find this to be useful distinction. 


Thanks! 
Cheng




Tom Petch


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

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

[Chengli (Cheng Li)]

Hi Tom,

Many thanks for your comments. Please see my reply inline.

Respect,
Cheng



-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of tom petch
Sent: Monday, March 22, 2021 8:14 PM
To: julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)

Separate to my other comments

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

Sent: 18 March 2021 11:08

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.


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

[Cheng] WG/existing implemntations are happy with 0; I dont see a strong reason 
to change that.


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'

[Cheng] Changed to - 
TBD4: Unable to allocate the specified binding value
TBD5: Unable to allocate a new binding label/SID
Thanks!

Tom Petch




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
<<< text/html; name="Diff_ draft-ietf-pce-binding-label-sid-08-20210324.txt - draft-ietf-pce-binding-label-sid-08.txt.html": Unrecognized >>>
___
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)

[Chengli (Cheng Li)]

Hi Olivier,

Many thanks for your comments, please see my reply inline.

Respect,
Cheng


-Original Message-
From: olivier.dug...@orange.com [mailto:olivier.dug...@orange.com] 
Sent: Saturday, March 20, 2021 12:39 AM
To: julien.meu...@orange.com; pce@ietf.org; 
draft-ietf-pce-binding-label-...@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)

Hi all,

I support adoption of this draft, but I have a certain number of questions for 
the authors:

 - As far as I know, routers manage their MPLS label allocation by interface,
   except for Segment Routing which uses an SRGB. In the draft, you mention
   that the BSID, associated with a given LSP, could be taken from the SRGB or
   from a local block. Does this imply that the BSID value must be available for
   all interfaces? (i.e. all packets arriving on any interface with the BSID 
will
   be forwarded in the LSP) or does the BSID only depend on the source IP 
address
   of the LSP? But, in the latter case, if this source IP address corresponds to
   a loopback interface (the most frequent case), the BSID becomes de facto
   global. So, if the BSID does not have a global meaning, should the
   TE-Path-Binding TLV contain a reference (e.g. the IP address) to the 
interface
   to which this BSID is associated?

[Cheng] I dont think there is any coupling between source IP address and BSID 
in SPRING RFCs. 
A BSID is availaible on all interfaces.   


 - In the draft, you mention that there could be several TE-PATH-BINDING TLVs in
   the LSP object (I assume one TE-Path-Binding per BSID). In case a PCE 
requests
   multiple BSIDs from a PCC via a PCupd or PCInitiate message for a given LSP,
   should the PCE insert as many empty TE-PATH-BINDING TLVs as requested BSIDs?
   Similarly, if the PCE wishes to add an additional BSID, should it insert the
   TE-PATH-BINDING TLVs corresponding to the previously allocated BSIDs plus an
   empty TE-PATH-BINDING TLV for the new BSID?

[Cheng] Some more text has been added to describe the handling of multiple 
TE-PATH-BINDING TLVs. 
Hope that clarifies the above queries. Please check the diff.


 - Once the BSID is allocated, is it advertised (flooded) in the IGP for use by
   other routers in the network or does it remain under the control of the PCE?
   As there may be use cases for both scenarios, should a new flag be added to
   indicate whether the BSID is to be advertised or not in the IGP?


[Cheng]BSIDs are not flooded in the IGP as per the current RFCs in LSR.


 - In the case of hierarchical paths, how could we use BSID? For example: we 
would
   route 2 LSPs 1 & 2 through a hierarchical tunnel H-LSP by associating BSID1
   and BSID2 to H-LSP in order to use it respectively for LSP1 and LSP2 like 
this:

   A->B->C (incoming LSP1) --\    /-- Z->U 
(continuation of LSP1)
  --> C->Y->Z (hierarchical H-LSP) -->
   D->E->C (incoming LSP2) --/    \-- Z->W 
(continuation of LSP2)

   In this example, how Z can determine which packets from LSP1 should continue 
to
   U and which packets from LSP2 should continue to W? A solution would be to 
keep
   the BSID1, respectively BSID2, for each packets belonging to LSP1 
respectively
   LSP2 to help Z determine the next hop. So, for this purpose,would it be
   possible to add a flag to indicate that the BSID must be preserved, so that
   packets can pass through a hierarchical tunnel transparently?

[Cheng] This is out of scope of this I-D also this would be against the BSID 
handling in SPRING. 
It could be discussed in draft-ietf-pce-stateful-interdomain perhaps?

If I understand correctly, the BSID1 should represent Y-Z-U, and BSID2 
represents Y-Z-W, so, an node C, the packets will be forwarded into specific 
LSP according to the BSID.

Regards

Olivier

Le 18/03/2021 à 12:08, julien.meu...@orange.com a écrit :
> 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 ema

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

[Chengli (Cheng Li)]

Hi Andrew, 

Thanks for your comments, please see my reply inline.

Also, the diff is attached.

Respect,
Cheng




-Original Message-
From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com] 
Sent: Saturday, March 20, 2021 4:21 AM
To: julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-...@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)

Hi all,

Overall Support WGLC. It's an important document in the world of SRTE, and the 
document goes to good lengths to describe the various scenarios and 
combinations. 

Only one question I have for the authors and WG, for any further clarification 
on the following text (section 4):


  The absence of TE-PATH-BINDING TLV in PCUpd message
   means that the PCE does not specify a binding value in which case the
   binding value allocation is governed by the PCC's local policy.


I find the "governed by PCC local policy" a bit too vague and could lead to 
implementation interop differences. Assuming a PCInitiated LSP that been 
established with a BSID: If the PCE wants to withdraw the binding SID , I 
interpret the document as the PCE would send a PCUpdate without the TLV, but 
the behaviour is now up to PCC as per that text. if the PCC local 
policy/implementation is to do nothing, how can the PCE explicitly force-remove 
the BSID with a PCUpdate? In a similar manner, If the PCE does not want to 
change the value but PCC local policy is to treat missing TLV as remove, then 
PCE should always send the TLV in every PCUpdate (which I'm okay with) which is 
not stated, otherwise the local policy/implementation may interpret it as a 
removal compared to an implementation which may interpret it as being okay to 
not send the TLV on every PCUpdate since there was "no change". 

In summary: might need a bit of a wording to further detail "PCE wishes to 
withdraw" case. 

[Cheng] You are correct, there was some issues with multiple TE-PATH-BINDING 
TLV. This has been updated. See the diff.

The above text has been updated to - 

   The absence of TE-PATH-BINDING TLV in PCUpd message means that the
   PCE does not specify a binding value in which case any previous
   allocated binding values are withdraw.

Further, the PCC's local policy aspect has been seperated out as - 

   In the absence of any instruction from the PCE, the PCC's local
   policy dictates how the binding allocations are made for a given LSP.

Thanks!


Thanks! 
Andrew

On 2021-03-18, 7:09 AM, "Pce on behalf of julien.meu...@orange.com" 
 wrote:

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