[Pce] Call for slot in the PCE WG at IETF 121

[Dhruv Dhody]

Hi,

The PCE WG would be meeting during the IETF 121 [1] week. If you need
agenda time to progress some work, please send a slot request directly to
the chairs/secretary  by Monday, Oct 21st 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 also
Monday, Oct 21st [2]. Also, let us know if you have requested agenda time
in a different WG session for the same topic.

Thanks!
PCE Chairs & Secretary

[1] https://datatracker.ietf.org/meeting/121/agenda
[2] https://datatracker.ietf.org/meeting/important-dates/
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

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

[Dhruv Dhody]

Hi Quan,

On Tue, Sep 24, 2024 at 1:11 PM  wrote:

>
> Hi Cheng,
>
>
> Thanks for your suggestion!
>
>
> Got it about the PSID.
>
> And I also agree with the P flag in LSP. So I suggest to clarify it and
> the adding text may be as following shown.
>
>
> 4.5. Path Attributes Object
>
>
>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 Path Segment Identifier(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. The P flag in LSP Object is also used to indicate
>
> that the allocations of all PSIDs need to be done by the PCE.
>
>
>
Dhruv: Can I suggest changing the last sentence to make it generic -

The usage of P flag in the LSP object for Path Segment as
specified in Section 4.2 also applies to all PSIDs encoded
in the PATH-ATTRIB object.

And in section 4.2, you can remove " in the LSP object", to keep the text
generic and thus apply to TLV in both LSP object and PATH-ATTRIB object.

Thanks!
Dhruv


> Thanks,
>
> Quan
>
>
> Original
> *From: *ChengLi 
> *To: *熊泉00091065;dhruv.i...@gmail.com ;
> *Cc: *pce@ietf.org ;draft-ietf-pce-sr-path-segm...@ietf.org
> ;
> *Date: *2024年09月23日 16:20
> *Subject: **RE: [Pce] Re: Path segment supporting multiple segment lists
> in a candidate path*
>
> Hi Quan，
>
>
>
> PSID(Path Segment ID) was defined in RFC9545 originally, and introduced in
> SRv6 draft, so it can apply to SR-MPLS and SRv6.
>
>
>
> Reusing P flag in LSP is better to me, make it as general, indicating PSID
> allocation request, no matter where the Path Segment TLV will be encoded.
>
>
>
> My 2cents,
>
> Cheng
>
>
>
>
>
> *From:* xiong.q...@zte.com.cn 
> *Sent:* Monday, September 23, 2024 4:59 AM
> *To:* dhruv.i...@gmail.com
> *Cc:* Cheng Li ; 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 Dhruv,
>
>
>
> Thanks for your reply!
>
>
>
> I will take your suggestion for the new version. But I have two concerns.
>
> The PSID is defined as "SRv6 Path Segment Identifier" in
> draft-ietf-spring-srv6-path-segment and it is not mentioned in this
> documents , cause path segment should cover both SR-MPLS and SRv6. So I
> suggest we still use the path segment instead of PSID.
>
> Another concern is that,  for example, when we put multiple path segment
> TLVs in multiple PATH-ATTRIB objects but none in LSP object in PCInitiate
> message,  we also need to indicate PCE or egress PCC to allocate the path
> segment. There may be two options, reusing P flag in LSP object to indicate
> all path segment TLVs or creating a new P flag in PATH-ATTRIB object
> to indicate each path segment TLV. So I think we need to clarify it.
>
>
>
> What is your thoughts? Thanks!
>
>
>
> Best Regards,
>
> Quan
>
>
>
>
>
> Original
>
> *From: *DhruvDhody 
>
> *To: *Cheng Li ;
>
> *Cc: *熊泉00091065;pce@ietf.org ;
> draft-ietf-pce-sr-path-segm...@ietf.org <
> draft-ietf-pce-sr-path-segm...@ietf.org>;
>
> *Date: *2024年09月20日 20:15
>
> *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 
> 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 

[Pce] Re: AD Review of draft-ietf-pce-segment-routing-policy-cp-17

[Dhruv Dhody]

Hi Roman,

On Mon, Sep 23, 2024 at 5:36 PM Roman Danyliw  wrote:

> Hi Druhv!
>
>
>
> Thanks for the follow-up.
>
>
>
> *From:* Dhruv Dhody 
> *Sent:* Monday, September 23, 2024 5:45 AM
> *To:* Roman Danyliw 
> *Cc:* pce@ietf.org
> *Subject:* Re: [Pce] AD Review of
> draft-ietf-pce-segment-routing-policy-cp-17
>
>
>
> *Warning:* External Sender - do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
>
> Hi Roman,
>
>
>
> Thanks for taking on the AD role for this I-D.
>
>
>
> On Sat, Sep 21, 2024 at 12:35 AM Roman Danyliw  wrote:
>
>
>
>
>
> ** Section 4.2.1
>SR Policy Name: SR Policy name, as defined in [RFC9256].  It SHOULD
>be a string of printable ASCII characters, without a NULL terminator.
>
> The use of SHOULD here implies that the encoding could be something other
> than printable ASCII.  That would be prohibited by the text in Section 2.1
> of RFC9256.  Perhaps s/SHOULD/must/.
>
> Same comment for nearly identical text in Section 4.2.3
>
>
>
> Dhruv: FWIW past RFCs that encode strings in PCEP have used a similar
> language - RFC 8231, RFC 9358! That said, I don't mind making a change
> going forward.
>
>
>
> [Roman] Does the WG remember why this “SHOULD” was used?  Would a UTF
> string or non-printable ASCII be acceptable since the “SHOULD” suggests
> there are cases where printable ASCII need not be used?
>
>
>

Dhruv: Not speaking for the WG, but my understanding of the SHOULD in the
past was that as an implementation I will be liberal in what I accept and
not throw an error if I receive non-printable ASCII characters from the
peer.

Thanks!
Dhruv



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

[Pce] Re: AD Review of draft-ietf-pce-segment-routing-policy-cp-17

[Dhruv Dhody]

Hi Roman,

Thanks for taking on the AD role for this I-D.

On Sat, Sep 21, 2024 at 12:35 AM Roman Danyliw  wrote:

> Hi!
>
> I performed an AD review of draft-ietf-pce-segment-routing-policy-cp-17.
> To help load-balance AD documents queues, I am assuming the role of
> responsible AD.
>
> Thanks for this document.  I have the following feedback and questions:
>
> ** Section 4.2.1
>SR Policy Name: SR Policy name, as defined in [RFC9256].  It SHOULD
>be a string of printable ASCII characters, without a NULL terminator.
>
> The use of SHOULD here implies that the encoding could be something other
> than printable ASCII.  That would be prohibited by the text in Section 2.1
> of RFC9256.  Perhaps s/SHOULD/must/.
>
> Same comment for nearly identical text in Section 4.2.3
>
>
Dhruv: FWIW past RFCs that encode strings in PCEP have used a similar
language - RFC 8231, RFC 9358! That said, I don't mind making a change
going forward.



> ** Section 4.2.2
>If the PCE has its AS number, then it SHOULD set it,
>otherwise the AS number can be set to 0.
>
> What would be the circumstance where the PCE has an AS, but still sets it
> to 0.  Why is this not a MUST?
>
>
Dhruv: With the qualifier text, it makes sense to make it a MUST.



> ** Section 5.2
>Priority: Numerical priority with which this LSP is to be recomputed
>by the PCE upon topology change.
>
> Can this text clarify whether a higher number suggests a higher priority?
>
>
Dhruv: Makes sense to add esp because RFC 9256 says "where the lowest value
is the highest priority"



> ** Section 5.3
>Therefore the PCEP speaker SHOULD ignore the presence of this TLV for
>SRv6 Policies.
>
> What are the circumstances where this TLV would NOT be ignored?
>
>
Dhruv: None, make it a MUST!



> ** Section 5.4
>This field can be set to non-
>zero values only by the PCC, it MUST be set to 0 by the PCE and
>SHOULD be ignored by the PCC.
>
> What are the circumstances where it would not be ignored by the PCC?
>
>
Dhruv: None, make it a MUST!



> ** Section 6.5
>The subregistry contains the following codepoints, with
>initial values, to be assigned by IANA with the reference set to this
>document:
>
> Consider explicitly stating there is a reference column in this table.
>
> Same feedback for Section 6.6
>
>
Dhruv: Yes, always a good practice when RFC and the iana registry match.



> ** Section 6.7 and 6.8.  Should the new registries defined here be created
> under the
> https://www.iana.org/assignments/segment-routing/segment-routing.xhtml?
>
>
Dhruv: Yes, authors please add under the "Segment Routing Parameters"
registry.

Also note that these days IANA has asked us to. stop using subregistry and
top registry. The preferred terms are registry and registry group
respectively. From a recent email -

NOTE: In the IANA Considerations section, please replace all occurrences of
"sub-registry" with "registry" and all occurrences of '"Path Computation
Element Protocol (PCEP) Numbers" registry' or "PCEP Numbers registry" with
'Path Computation Element Protocol (PCEP) Numbers" registry group.



> ** Section 8.  Should a statement to the effect of “the Security
> Considerations of RFC8231 continue to apply” be reiterated here?
>
>
Dhruv: Perhaps,

   The security considerations described in [RFC5440], [RFC8231],
   [RFC8281], [RFC8664], and [RFC9256] are applicable to this
   specification.

Authors, if you disagree, please feel free to jump in!


Thanks!

Dhruv (Document Shepherd)



> Regards,
> Roman
>
>
> ___
> 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: AD Review of draft-ietf-pce-stateful-pce-vendor-07

[Dhruv Dhody]

Hi Roman,

Thanks for taking the responsible AD role for this I-D.

On Fri, Sep 20, 2024 at 7:56 PM Roman Danyliw  wrote:

>
> Hi!
>
> I performed an AD review of draft-ietf-pce-stateful-pce-vendor-07.  To
> help load balance AD document queues, I'll be taking over as responsible AD.
>
> Thanks for this document.  My feedback is below:
>
> ** Is there a reason why this document does not formally updated RFC8231
> and RFC8281 given the text in Section 2?
>
>
Dhruv: This is the case of "Extends" as per
draft-kuehlewind-rswg-updates-tag. Within PCE WG, we have not used
"Updates" to mean "extends" and doing it now will just create more
confusion.



> ** Section 2.  I’m not confident in my understanding of RFC5511 models.
> Where is the reference or explanation of this value: 
> in this document?
>
>
Dhruv: That would be Vendor Information object from RFC 7470. This is
understandable to anyone with understanding of PCEP RBNF.



> ** Section 2.  Consider provide specific section references when OLD/NEW
> text is provided.


Dhruv: Thanks for these, makes sense to include section numbers!




> ** Section 2.  Per the definition of PCInitiate, RFC8281 included the text
> “ is defined in RFC 5440”.  Should that be used here?
>
>
Dhruv: The  is common to all PCEP messages and well
understood. In the case where we are simply extending the messages and the
initial message is specified in existing RFC, we have not used that text.
For the sake of uniformity, prefer to keep it that way.



> ** Section 4.2
>Any
>standard YANG module will not include details of vendor-specific
>information.
>
> What is a “standard” YANG module?
>
>
Dhruv: That would be to differentiate with vendor-specific YANG extensions.
RFC 7470 uses similar phrasing.



> ** Section 4.6
>
>Section 6.6 of [RFC7470] highlights how the presence of additional
>vendor-specific information in PCEP messages may congest the
>operations and how to detect and handle it.  A similar approach
>SHOULD be considered for Stateful PCEP messages and for a PCE.
>
> What does it mean when an approach “SHOULD be considered”?  SHOULD is
> already conveying that this behavior is optional.  Can the desired behavior
> please be more tangibly described?
>
>
Dhruv: How about rephrasing this way -

This also applies to stateful PCEP messages as outlined

in Section 2. Specifically, a PCEP speaker SHOULD NOT

include vendor information in a stateful PCEP message

if it believes the recipient does not support that

information.


Authors, if you disagree, please feel free to jump in!


Thanks!

Dhruv (Document Shepherd)




> Regards,
> Roman
> ___
> 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: Path segment supporting multiple segment lists in a candidate path

[Dhruv Dhody]

Hi Cheng,  Quan,

On Fri, Sep 20, 2024 at 2:52 PM Cheng Li 
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 
> *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

[Pce] Re: AD Review of draft-ietf-pce-stateful-pce-optional-09

[Dhruv Dhody]

Hi Roman,

On Thu, Sep 19, 2024 at 7:43 PM Roman Danyliw  wrote:

> Hi!
>
> I performed an AD review of draft-ietf-pce-stateful-pce-optional-09.  To
> help load-balance document queues, I'm taking over a responsible AD for
> this document.  Thanks for the work on this document.
>
>
Dhruv: Thank you for helping out!



> I only have the following feedback which can be addressed with IETF LC
> feedback:
>
> ** Section 3.2.1
>When the P flag is set in the PCRpt message
>received on a PCEP session on which the R bit was set by both peers,
>the object SHOULD be taken into account by the PCE.
>
> What does this “SHOULD” mean here?  Shouldn’t the PCE always take the
> message into account but a local policy might override it?
>
>
Dhruv: The SHOULD is because of the delegation feature as described in
section 3.2.1.1 where even though the P flag is set for the object, PCE
could choose to ignore it for delegated LSPs.

Thanks!
Dhruv (Document Shepherd)



> Regards,
> Roman
> ___
> 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: WG Last Call for draft-ietf-pce-iana-update

[Dhruv Dhody]

Hi Samuel,

Thanks for your review.

On Tue, Sep 17, 2024 at 7:21 PM Samuel Sidor (ssidor)  wrote:

> Hi Julien and PCE WG,
>
> I support progress of this document.
>
> 3 minor (non-blocking) comments:
> 1. Do we need to expand "PCEP" in document title? (It seems to be expanded
> in most of PCEP RFCs)
>

Dhruv: Fixed as "Update to the IANA PCE Communication Protocol (PCEP)
Registration Procedures and Allowing Experimental Error Codes"; PCE is
marked as well-known by RFC-Editor
https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list


> 2. In section 3.1, shouldn't we use normative SHOULD/MUST when specifying
> what an "experiment" should/will do? (I understand that the whole section
> is even called as "Advice ...", so it seems that it is not really
> specifying requirements. However, in reality, it seems to be defining
> required behavior for anyone using experimental error types/values.


Dhruv: I personally prefer to not use normative keywords when they do not
apply to protocols or their implementations :)


> 3. Just a note: If I haven't missed anything, American English is used in
> most of PCEP drafts. I can see a few words from British English
> ("recognise", "synchronised",..) in this draft. That should be fine as long
> as we are not mixing American and British English in a single document (I
> don't see a specific example of some a word that would be specific to
> American English. I'm just raising this because there is a chance that
> could happen during merge of 2 drafts into current one).
>
>
Dhruv: Thanks. Fixed.

Commit ->
https://github.com/ietf-wg-pce/draft-ietf-pce-iana-update/commit/493c08e19c56fc3a72d6c4102e230173de01d2e0

Diff ->
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-pce-iana-update&url_2=https://ietf-wg-pce.github.io/draft-ietf-pce-iana-update/draft-ietf-pce-iana-update.txt

Thanks!
Dhruv



> Thanks a lot,
> Samuel
>
> -Original Message-
> From: julien.meu...@orange.com 
> Sent: Friday, September 6, 2024 2:24 PM
> To: pce@ietf.org
> Subject: [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: WG Last Call for draft-ietf-pce-iana-update

[Dhruv Dhody]

Thanks Quan and Adrian.

Here is the commit -
https://github.com/ietf-wg-pce/draft-ietf-pce-iana-update/commit/94a3e01b069143fdf38fcc4cd0a46b7506a4d517


Diff:
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-pce-iana-update&url_2=https://ietf-wg-pce.github.io/draft-ietf-pce-iana-update/draft-ietf-pce-iana-update.txt

Thanks!
Dhruv

On Wed, Sep 18, 2024 at 2:09 PM Adrian Farrel  wrote:

> Thanks, Quan.
>
>
>
> You make a good point, I think.
>
>
>
> Dhruv, if you have the pen, I see some smart quotes in the Abstract.
>
>
>
> A
>
>
>
> *From:* xiong.q...@zte.com.cn 
> *Sent:* 18 September 2024 09:27
> *To:* julien.meu...@orange.com
> *Cc:* pce@ietf.org
> *Subject:* [Pce] Re: WG Last Call for draft-ietf-pce-iana-update
>
>
>
>
>
> Hi Julien and PCE WG,
>
>
>
> Thanks for the useful and meaningful work!  I support the progress of this
> document.
>
> I am a liitle confused that why RFC9357 is listed as informative
> references while other PCEP registries are listed as normative references.
> Thanks!
>
>
>
> Best Regards,
>
> Quan
>
>
>
>
> <<[Pce] WG Last Call for draft-ietf-pce-iana-update
>
> julien.meu...@orange.com Fri, 06 September 2024 12:24 UTCShow header
> <https://mailarchive.ietf.org/arch/browse/pce/?gbt=1&index=>
>
> 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
>
> ·Attachment: smime.p7s
> <https://mailarchive.ietf.org/arch/msg/pce/Ap9fXsGHorZnnNAcN5fEnIYj3wg/2/>
>
>- [Pce] WG Last Call for draft-ietf-pce-iana-update
><https://mailarchive.ietf.org/arch/msg/pce/Ap9fXsGHorZnnNAcN5fEnIYj3wg/>
>  julien.meuric
>- [Pce] Re: WG Last Call for draft-ietf-pce-iana-up…
><https://mailarchive.ietf.org/arch/msg/pce/UvP2g605Th1A2rbvVA1eSSh8aXI/>  
> Adrian
>Farrel
>- [Pce] Re: WG Last Call for draft-ietf-pce-iana-up…
><https://mailarchive.ietf.org/arch/msg/pce/ntqc55R-tERdPH3LucuuCUXf1xE/>  
> Dhruv
>Dhody
>- [Pce] 答复: WG Last Call for draft-ietf-pce-iana-up…
><https://mailarchive.ietf.org/arch/msg/pce/jFXLF3GulEJK5C9urVsanTUuqGs/>  
> Aijun
>Wang
>- [Pce] Re: WG Last Call for draft-ietf-pce-iana-up…
><https://mailarchive.ietf.org/arch/msg/pce/vJsFC4FBGCK5NkjJrdlza1rBoAY/>  
> Andrew
>Stone (Nokia)
>- [Pce] Re: 答复: WG Last Call for draft-ietf-pce-ian…
><https://mailarchive.ietf.org/arch/msg/pce/73skkAI11AshOeI3pO5AlkPHhJQ/>  
> Cheng
>Li
>- [Pce] Re: WG Last Call for draft-ietf-pce-iana-up…
><https://mailarchive.ietf.org/arch/msg/pce/PkTz2xKqJ6OfeC8lPWQWCsXFumI/>  
> Samuel
>Sidor (ssidor)
>
>
>
___
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

[Dhruv Dhody]

Thanks Quan! LGTM!

On Thu, Sep 12, 2024 at 8:40 AM  wrote:

> Hi Dhruv,
>
>
> Thanks for your review and suggestions!
>
> Please see inline with [Quan].
>
> The new version is attached. Thanks!
>
>
> Best Regards,
>
> Quan
>
>
> Original
> *From: *DhruvDhody 
> *To: *熊泉00091065;
> *Cc: *c...@huawei.com ;
> draft-ietf-pce-sr-path-segm...@ietf.org <
> draft-ietf-pce-sr-path-segm...@ietf.org>;pce@ietf.org ;
> *Date: *2024年09月11日 23:26
> *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(?)
>
>
> [Quan] From my understanding, it is not required to be exlicitly indicated
> and it may need normative keywords MUST.
>
> So as you suggested, this text can be revised as following.
>
> "The ASSOCIATION object MUST 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 SR path belongs to an
> SR policy."
>
> What is your thought?
>
> ==
>
> 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.
>
>
> [Quan] Thanks for your detailed texts. I think it is very great. It is
> very appreciated.
>
> I suggest to add this texts to the end of the introduction section. Please
> see the attachment. Thanks!
>
>
>
> ==
>
> 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 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

[Dhruv Dhody]

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(?)

==

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.

==

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.
>
> 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 
>
> *To: *Joel Halpern ;
>
> *Cc: *熊泉00091065;gregimir...@gmail.com ;
> pce@ietf.org ;draft-ietf-pce-sr-path-segm...@ietf.org <
> 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 
> wrote:
>
> > These references appear useful.  There is however one aspect that I am
> > missing.  It may well be my

[Pce] Re: Scope of draft-ietf-pce-pcep-color draft

[Dhruv Dhody]

Hi Pavan,

Without my chair hat...

On Mon, Sep 9, 2024 at 9:31 PM Vishnu Pavan Beeram 
wrote:

> We (authors) are working through the issues identified during the WGLC [1]
> and would like to seek further input from the WG on the following comment
> from Diego [2] regarding the scope of the draft.
>
> **
> *Now, I think that this PCEP extension should not be limited to RSVP-TE
> LSPs only. I know that colour is inherent to SR-Policy/CP and that PCEP
> extensions defined in draft-ietf-pce-segment-routing-policy-cp already
> cover this aspect, but there are SR-TE implementations out there that
> follow RFCs 8231, 8281, and 8664 that may want to add support for colour
> without having to implement support for
> draft-ietf-pce-segment-routing-policy-cp.*
> **
>
> We would like to accommodate the above change and update the
> "Introduction" as follows:
> **
>
> *   This document introduces extensions to PCEP to carry the color*
>
> *   attribute associated with paths that are setup using RSVP-TE*
>
> *   ([RFC8408]) or Segment Routing (SR) ([RFC8664]) or any other path*
>
> *   setup type supported under the stateful PCE model.  The only*
>
> *   exception where the extensions defined in this document are not used*
>
> *   for carrying the color attribute is when an SR Policy path is setup*
>
> *   using the extensions defined in*
>
> *   [I-D.ietf-pce-segment-routing-policy-cp].  For these SR Policy paths,*
>
> *   the associated color is already included as part of the policy*
>
> *   identifier encoding.*
> **
>
> Are there any concerns with making this change?
>
>
Dhruv: No!

Do remove this text in Section 3 -

   The color TLV
   is ignored if it shows up in the LSP Object of a message where the
   PCEP Path Setup Type [RFC8408] is Segment Routing or SRv6.
And add text to handle the case when both Color TLV and
I-D.ietf-pce-segment-routing-policy-cp are present on the receiving side. I
guess ignoring Color TLV and logging it could be a good way to handle it.

Thanks!
Dhruv


Regards,
> -Pavan (on behalf of the authors)
>
> [1] https://mailarchive.ietf.org/arch/msg/pce/QDetx1Sn3LftKjcvSIRjWop82UI/
> [2] https://mailarchive.ietf.org/arch/msg/pce/r7VCoYKfd2fy5l8dF999Spej04U/
> ___
> 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: WG Last Call for draft-ietf-pce-iana-update

[Dhruv Dhody]

On Sat, Sep 7, 2024 at 2:03 AM Adrian Farrel  wrote:

> Thanks Julien.
>
> This is good and speedy progress (proof, if any were needed , that the
> IETF does not need to take multiple years to make simple changes).
>
> As a co-author, I am content with the text and think it is ready to move
> forward.
>
>

What Adrian said



> Cheers,
> Adrian
>
> PS Not aware of any pertinent IPR
>

+1 I am also unaware of any IPR relevant to this I-D.

Thanks!
Dhruv (co-author)



>
>
> On 06/09/2024 13:23 BST julien.meu...@orange.com wrote:
>
>
> 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 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

[Dhruv Dhody]

Hi Joel,

On Fri, Sep 6, 2024 at 7:22 PM Joel Halpern 
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
> .
>
>
>  1 Introduction
>
>   [RFC8664] specifies extensions to the Path Computation Element
> Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE   to
> compute and initiate SR-TE paths, as well as a PCC to request,   report or
> delegate SR paths. ** *"[ietf-pce-segment-routing-policy-cp]
>   specifies the PCEP extension to signal candidate paths of the SR Policy.
> "*
>
>This document specifies a mechanism to carry the SR path
> identification information in PCEP messages [RFC5440] [RFC8231]
> [RFC8281].  The SR path identifier can be a Path Segment in SR-MPLS
> [RFC9545] and SRv6 [I-D.ietf-spring-srv6-path-segment], or other IDs   that
> can identify an SR path * "or an SR Policy"*.  This
> document also extends the PCECC-   SR mechanism to inform the Path Segment
> to the egress PCC.
>
>
>   5.1.1 Ingress PCC-Initiated Path Segment Allocation
>
>The PATH-SEGMENT TLV MUST be included in an LSP object in the
> PCInitiate message sent from the PCE to the egress to request Path
> Segment allocation by the egress PCC.  The P flag in LSP object MUST   be
> set to 0.  This PCInitiate message to egress PCC would be the   similar to
> the one sent to ingress PCC as per [RFC8664], but the   egress PCC would
> only allocate the Path Segment and would not trigger   the LSP initiation
> operation (as it would be the egress for this   LSP). *
> "The association object should also be carried in PCInitiate message   to
> indicate the SR policy association parameters  as per
> [ietf-pce-segment-routing-policy-cp]   if this path segment identifies an
> SR policy."*
>
>
> What is your thoughts with these texts? Thanks!
>
>
> Best Regards,
>
> Quan
>
>
>
>
>
> <<[Pce] I-D Action: draft-ietf-pce-sr-path-segment-10.txt
>
> internet-dra...@ietf.org Wed, 28 August 2024 13:56 UTCShow header
> 
>
> Internet-Draft draft-ietf-pce-sr-path-segment-10.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) Extension 
> for Path Segment in Segment Routing (SR)
>Authors: Cheng Li
> Mach(Guoyi) Chen
> Weiqiang Cheng
> Rakesh Gandhi
> Quan Xiong
>Name:draft-ietf-pce-sr-path-segment-10.txt
>Pages:   25
>Dates:   2024-08-28
>
> Abstract:
>
>The Path Computation Element (PCE) provides path computation
>functions in support of traffic engineering in Multiprotocol Label
>Switching (MPLS) and Generalized MPLS (GMPLS) networks.
>
>The Source Packet Routing in Networking (SPRING) architecture
>describes how Segment Routing (SR) can be used to steer packets
>through an IPv6 or MPLS network using the source routing paradigm.  A
>Segment Routed Path can be derived from a variety of mechanisms,
>including an IGP Shortest Path Tree (SPT), explicit configuration, or
>a Path Computation Element (PCE).
>
>Path identification is needed for several use cases such as
>performance measurement in Segment Routing

[Pce] Publication has been requested for draft-ietf-pce-stateful-pce-vendor-07

[Dhruv Dhody via Datatracker]

Dhruv Dhody has requested publication of draft-ietf-pce-stateful-pce-vendor-07 
as Proposed Standard on behalf of the PCE working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-vendor/


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

[Pce] Shepherd review of draft-ietf-pce-stateful-pce-vendor-06

[Dhruv Dhody]

Hi Authors,

I have completed my shepherd review. There are only a few comments and
nits. Please fix them and we would be ready to ship this to our AD.

## Comments

- Introduction, the last paragraph

OLD:
This document extends the usage of the Vendor Information Object and
the VENDOR-INFORMATION-TLV to Stateful PCE.  The VENDOR-INFORMATION-
TLV can be carried inside any of the new objects added in PCEP for
Stateful PCE as per [RFC7470], this document extends the stateful
PCEP messages to include the Vendor Information Object as well.
NEW:
The Vendor Information Object and the VENDOR-INFORMATION-TLV are
also valuable in the Stateful PCE model. The VENDOR-INFORMATION-TLV
can be included within any of the new objects introduced in PCEP
for Stateful PCE as defined in [RFC7470]. This document extends
stateful PCEP messages to incorporate the Vendor Information
Object.
END


- Add a new section 1.2

1.2.  Use of RBNF

   The message formats in this document are illustrated using Routing
   Backus-Naur Form (RBNF) encoding, as specified in [RFC5511].  The use
   of RBNF is illustrative only and may elide certain important details;
   the normative specification of messages is found in the prose
   description.  If there is any divergence between the RBNF and the
   prose, the prose is considered authoritative.


- I am unsure about this text in Section 4.6 - "Further, the mechanism
described in this document can help the operator to request control of the
LSPs at a particular PCE." Is it a copy-paste error when you borrowed the
text from a different document?

- I also suggest changing this text "Section 6.6 of [RFC7470] describes
congestion mitigation methods for a PCC for Stateless PCEP messages" to
"Section 6.6 of [RFC7470] highlights how the presence of additional
vendor-specific information in PCEP messages may congest the operations and
how to detect and handle it"

- Section 7, I suggest this text, which we have been using in the recent
RFCs -

OLD:
   As stated in [RFC6952], PCEP implementations SHOULD support the TCP-
   AO [RFC5925] and not use TCP MD5 because of TCP MD5's known
   vulnerabilities and weakness.  PCEP also supports Transport Layer
   Security (TLS) [RFC8253] as per the recommendations and best current
   practices in [RFC9325].
NEW:
   As per [RFC8231], it is RECOMMENDED that these PCEP extensions
   only be activated on authenticated and encrypted sessions across PCEs
   and PCCs using Transport Layer Security (TLS) [RFC8253], as per the
   recommendations and best current practices in RFC 9325 [BCP195]
   (unless explicitly set aside in [RFC8253]).


## Nits

- s/traffic engineered/traffic-engineered/

- s/stateless Path Computation Element Communication Protocol
(PCEP)/stateless PCE Communication Protocol (PCEP) messages/

- s/with [RFC8231] as base/with [RFC8231] as the base/

- s/update attributes of an LSP/update the attributes of an LSP/

- s/In addition, requirements and considerations/In addition, the
requirements and considerations/

- s/The registrations procedures/The registration procedures/

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

[Pce] Re: Early code point allocation for draft-ietf-pce-sr-p2mp-policy-09

[Dhruv Dhody]

Hi WG,

The early allocation is completed. See
https://www.iana.org/assignments/pcep/pcep.xhtml

Thanks!
Dhruv

On Mon, Aug 26, 2024 at 7:25 PM Dhruv Dhody  wrote:

> Hi WG,
>
> We did not receive any objections and thus we will be going ahead with the
> early allocation.
>
> Thanks!
> Dhruv & Julien
>
> On Sun, Aug 4, 2024 at 11:21 AM Dhruv Dhody  wrote:
>
>> Hi WG,
>>
>> We have received a request from the authors
>> of draft-ietf-pce-sr-p2mp-policy for an early code point allocation for
>> the codepoints listed in -
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.1
>> (TBD1)
>>
>> https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.2-4
>> (TBD2)
>>
>> https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.3
>> (TBD3-5)
>>
>> https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.4
>> (TBD6)
>>
>> RFC 7120 requires one 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.
>>
>> According to the chairs’ review, the RFC 7120 criteria are met; if you
>> disagree and believe that the draft does not meet these criteria or believe
>> that early allocation is not appropriate for any other reason, please
>> send an email to the PCE mailing list explaining why by August 19th.
>>
>> Thanks!
>> Dhruv & Julien
>>
>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Adoption Poll of draft-dhody-pce-iana-update

[Dhruv Dhody]

Hi,

On Tue, Aug 27, 2024 at 3:18 PM Aijun Wang 
wrote:

> Hi, Dhruv:
>
>
>> 2) Should the table 2 in section 3, add one line to describe the
>> Error-Type 0-251, and their corresponding Error-Value?
>>
> And note that the practice of maintaining two tables is a standard
> practice as seen at
> https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-messages
>
>
> [WAJ] This is what exactly I want to suggest. This draft will update
> RFC5440, the newly added table shouldn’t only cover the newly assigned type
> range.
>
>
Dhruv: IMHO providing IANA with text instructions is fine. This is what we
did in RFC 8356 as well.

We plan to get an early review from the IANA and we can ask them if they
are happy with the current text. Thanks again for your review.

I will upload -01 in datatracker.

Thanks!
Dhruv



> Thanks!
> Dhruv
>
>
>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
>> *代表 *Dhruv Dhody
>> *发送时间:* 2024年8月22日 11:42
>> *收件人:* pce@ietf.org
>> *抄送:* draft-dhody-pce-iana-upd...@ietf.org;
>> draft-farrel-pce-experimental-err...@ietf.org
>> *主题:* [Pce] Re: Adoption Poll of draft-dhody-pce-iana-update
>>
>>
>>
>> Hi WG,
>>
>>
>>
>> Please find a proposed update that merges
>> draft-farrel-pce-experimental-errors -
>> https://ietf-wg-pce.github.io/draft-ietf-pce-iana-update/draft-ietf-pce-iana-update.html
>>
>> Diff:
>> https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-pce-iana-update&url_2=https://ietf-wg-pce.github.io/draft-ietf-pce-iana-update/draft-ietf-pce-iana-update.txt
>>
>>
>>
>> Please let us know if you have an objection to this update. Authors will
>> post the revision in the datatracker next week and will request Julien to
>> move this I-D quickly.
>>
>> Feel free to also provide your comments and edits.
>>
>>
>>
>> Thanks!
>>
>> Dhruv & Adrian
>>
>>
>>
>> On Mon, Aug 19, 2024 at 2:59 PM  wrote:
>>
>> Hi all,
>>
>> We have clear support and no objection on adopting this small I-D: it is
>> now a PCE WG item.
>>
>> @Authors: please re-submit the draft as draft-ietf-pce-iana-update-00.
>>
>> @Authors of draft-farrel-pce-experimental-errors: please talk to the
>> authors of the aforementioned I-D to consider adding your proposal as a
>> contribution into this new WG effort.
>>
>> Thank you,
>>
>> Julien
>>
>>
>> Le 30/07/2024 à 10:36, julien.meu...@orange.com a écrit :
>> > Hi all,
>> >
>> > In his review of the "native IP" draft, John suggested to consider
>> > adjusting to "IETF Review" the allocation policy of some of the PCEP
>> > registries currently using "Standards Action". Dhruv has submitted
>> > draft-dhody-pce-iana-update to quickly resolve this concern and bring
>> > higher consistency among PCEP registries.
>> >
>> > As a result, does the WG support the adoption of
>> > draft-dhody-pce-iana-update [1] as a WG item? Please, share your
>> > feedback using the PCE mailing list and include your rationale in case
>> > you're opposed.
>> >
>> > Thanks,
>> >
>> > Julien
>> >
>> >
>> > [1] https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/
>> ___
>> 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: Adoption Poll of draft-dhody-pce-iana-update

[Dhruv Dhody]

Hi Aijun,

On Tue, Aug 27, 2024 at 1:18 PM Aijun Wang 
wrote:

> Hi, Dhruv:
>
>
>
> I support the forward this draft in fast track. Some comments are bellows
> for your reference:
>

Dhruv: Thanks for taking time to review.



>
>
> 1) Should the two paragraphs within the “Abstract” be connected via
> some conjunction, for example, “On the other hand” etc. to make the
> conversion more smooth?
>

Dhruv: Since the two paragraphs are orthogonal, I dont think "on the other
hand" is suitable. I will leave it as it is and lets see if the RFC-editor
have suggestions if this needs to be changed.



> 2) Should the table 2 in section 3, add one line to describe the
> Error-Type 0-251, and their corresponding Error-Value?, to cover all the
> possibility?
>
> The final format of table 2 should be looked like the followings:
>
>
>
> ++==+==++
>
> |Error-Type | Meaning   |
>   Error-value   |   Reference|
>
> ++==+==++
>
> | 0-251 |  IETF Review |
>  0-255  |RFC5440|
>
> | 252-255|   Experimental Use   |
>  0-255  |  [this.I-D]   |
>
> |  |
>   |  Experimental Use
>|   |
>
>
> +++++
>
>
>

Dhruv: That would be confusing as it would not align with the existing IANA
registry at
https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object

And note that the practice of maintaining two tables is a standard practice
as seen at https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-messages

Thanks!
Dhruv



> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] *代表
> *Dhruv Dhody
> *发送时间:* 2024年8月22日 11:42
> *收件人:* pce@ietf.org
> *抄送:* draft-dhody-pce-iana-upd...@ietf.org;
> draft-farrel-pce-experimental-err...@ietf.org
> *主题:* [Pce] Re: Adoption Poll of draft-dhody-pce-iana-update
>
>
>
> Hi WG,
>
>
>
> Please find a proposed update that merges
> draft-farrel-pce-experimental-errors -
> https://ietf-wg-pce.github.io/draft-ietf-pce-iana-update/draft-ietf-pce-iana-update.html
>
> Diff:
> https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-pce-iana-update&url_2=https://ietf-wg-pce.github.io/draft-ietf-pce-iana-update/draft-ietf-pce-iana-update.txt
>
>
>
> Please let us know if you have an objection to this update. Authors will
> post the revision in the datatracker next week and will request Julien to
> move this I-D quickly.
>
> Feel free to also provide your comments and edits.
>
>
>
> Thanks!
>
> Dhruv & Adrian
>
>
>
> On Mon, Aug 19, 2024 at 2:59 PM  wrote:
>
> Hi all,
>
> We have clear support and no objection on adopting this small I-D: it is
> now a PCE WG item.
>
> @Authors: please re-submit the draft as draft-ietf-pce-iana-update-00.
>
> @Authors of draft-farrel-pce-experimental-errors: please talk to the
> authors of the aforementioned I-D to consider adding your proposal as a
> contribution into this new WG effort.
>
> Thank you,
>
> Julien
>
>
> Le 30/07/2024 à 10:36, julien.meu...@orange.com a écrit :
> > Hi all,
> >
> > In his review of the "native IP" draft, John suggested to consider
> > adjusting to "IETF Review" the allocation policy of some of the PCEP
> > registries currently using "Standards Action". Dhruv has submitted
> > draft-dhody-pce-iana-update to quickly resolve this concern and bring
> > higher consistency among PCEP registries.
> >
> > As a result, does the WG support the adoption of
> > draft-dhody-pce-iana-update [1] as a WG item? Please, share your
> > feedback using the PCE mailing list and include your rationale in case
> > you're opposed.
> >
> > Thanks,
> >
> > Julien
> >
> >
> > [1] https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/
> ___
> 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: Early code point allocation for draft-ietf-pce-sr-p2mp-policy-09

[Dhruv Dhody]

Hi WG,

We did not receive any objections and thus we will be going ahead with the
early allocation.

Thanks!
Dhruv & Julien

On Sun, Aug 4, 2024 at 11:21 AM Dhruv Dhody  wrote:

> Hi WG,
>
> We have received a request from the authors
> of draft-ietf-pce-sr-p2mp-policy for an early code point allocation for
> the codepoints listed in -
>
>
> https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.1
> (TBD1)
>
> https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.2-4
> (TBD2)
>
> https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.3
> (TBD3-5)
>
> https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.4
> (TBD6)
>
> RFC 7120 requires one 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.
>
> According to the chairs’ review, the RFC 7120 criteria are met; if you
> disagree and believe that the draft does not meet these criteria or believe
> that early allocation is not appropriate for any other reason, please
> send an email to the PCE mailing list explaining why by August 19th.
>
> Thanks!
> Dhruv & Julien
>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Zaheduzzaman Sarker's No Objection on draft-ietf-pce-pcep-extension-native-ip-35: (with COMMENT)

[Dhruv Dhody]

Hi Aijun, Zahed,

On Fri, Aug 23, 2024 at 11:42 AM Aijun Wang 
wrote:

> Hi, Zaheduzzaman:
>
> Thanks for your review and comments.
> Some detailed responses are inline below.
> If you agree or have other suggestions, please let me know. I will update
> the document accordingly later to reflect our consensus.
>
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
>
> -邮件原件-
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
> 代表 Zaheduzzaman Sarker via Datatracker
> 发送时间: 2024年8月22日 20:11
> 收件人: The IESG 
> 抄送: draft-ietf-pce-pcep-extension-native...@ietf.org; pce-cha...@ietf.org;
> pce@ietf.org
> 主题: [Pce] Zaheduzzaman Sarker's No Objection on
> draft-ietf-pce-pcep-extension-native-ip-35: (with COMMENT)
>
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-pce-pcep-extension-native-ip-35: 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-pcep-extension-native-ip/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for working on this document. I have not comments from transport
> protocol points of view.
>
> I have following comment/question though -
>
>  - In section 6.1 it says -
>
>   "The PCInitiate message SHOULD be sent to PCC which is
> acting as
>   BGP router and/or RR."
>
>In Section 6.2 it says -
>
>   "The PCInitiate message SHOULD be sent to every router on the
>   path."
>
>To me it seems like there is not way to bypass those SHOULDs and get the
>route and session establishment procedure done. If that understanding is
>correct then what are the exceptionsthiking about to let the
> implementers
>skip that part? Also, if this understand is not true, then I would
> expect
>this document to give warnings on the effects of skiping the PCInitiate
>messages.
> 【WAJ】：For “SHOULD” in section 6.1 that you mentioned, the original
> considerations are that such PCInitiate message may be sent to PCCs only(in
> no-RR scenario); or be sent to PCC and RR(in RR scenario). If we use MUST,
> it will be not appropriate for the no-RR scenario. Then, we select the word
> "SHOULD". Or we change the text as below:
> "The PCInitiate message MUST be sent to PCCs which are acting as BGP peer
> routers and exchange routes directly, or MUST be sent to PCC and RR
> respectively when two PCCs exchange the routes via the RR"
>
>
Dhruv: Note that all routers including RR are acting as PCC. The use of
"PCC and RR" gives an impression that RR is not a PCC.

IMHO the use of normative text in this section is not helping. In version
-34 this was lowercase should.

My suggestion would be to change this to -

"The PCInitiate message is sent to the BGP router and/or RR (which are
acting as PCC)."



> For "SHOULD" in section 6.2, actually there are some situations that such
> PCInitiate messages doesn't need to be sent to every router. For example,
> if the links between two router are not congest, it is not necessary to
> control the forward path explicitly via the PCIniitiate message that
> includes EPR objects. The traffic can depend solely on the default path
> that calculated by the IGP algorithm to forward the traffic. This is the
> reason that we use the word "SHOULD", instead of "MUST".
>
>
This could be changed to -

"For the purpose of explicit route addition, the PCInitiate message ought
to be sent to every router on the explicit path."

Do folks agree with this text change instead?

Regards,
Dhruv




> Should we add such explanation into the context then?
>
>
>
> ___
> 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-pcep-extension-native-ip-35.txt

[Dhruv Dhody]

Hi Aijun,

Apart from the global replacement of should/SHOULD, I also noticed the
following issues in -35.

(1) Abstract

To handle Gunter's comment, you made the following change.

17  Abstract
> 18
> 19 This document defines the Path Computation Element Communication
> 20 Protocol (PCEP) extension for Central Control Dynamic Routing
> (CCDR)
> 21 based applications in Native IP networks.  It describes the key
> 22 information that is transferred between the Path Computation
> Element
> 23 (PCE) and the Path Computation Clients (PCC) to accomplish the
> End-
> 24 to-End (E2E) traffic assurance in the Native IP network under
> PCE as
> 25 a central controller (PCECC).
>
> [minor]
> an alternate proposal for abstract easier to digest and read for people
> with less PCEP awareness. Please use or ignore as you find useful
>
> "
> This document defines extensions to the Path Computation Element
> Communication Protocol (PCEP) to support the computation of paths for
> native IP traffic. The proposed extensions enable a Path Computation
> Element (PCE) to calculate and manage paths for native IP networks,
> enhancing the capabilities of PCEP beyond traditional MPLS and GMPLS
> networks. By introducing new PCEP objects and procedures, this document
> allows for the efficient use of IP network resources and supports the
> deployment of traffic engineering in native IP environments. "
>
> 【WAJ】Have updated the document accordingly.
>

I suggest the following rewording, hope this works for you and Gunter.

This document introduces extensions to the PCE Communication Protocol
(PCEP) to support path computation in native IP networks through a
PCE-based central control mechanism known as Centralized Control Dynamic
Routing (CCDR). These extensions empower a PCE to calculate and manage
paths specifically for native IP networks, expanding PCEP’s capabilities
beyond its traditional use in MPLS and GMPLS networks. By implementing
these extensions, IP network resources can be utilized more efficiently,
facilitating the deployment of traffic engineering in native IP
environments.

(2) Thanks for adding normative reference to [I-D.ietf-pce-iana-update],
but you should also refer to it in Section 13.2. I suggest adding the
following note -

Editorial Note (To be removed by RFC Editor): This experimental track
document is allocating a code point in the registry under the
standards action registry which is not allowed.
[I-D.ietf-pce-iana-update] updates the registration policy to IETF
review allowing for this allocation. Note that an early allocation was
made when the document was being progressed in the standards track. At
the time of publication, please remove this note and the reference to
[I-D.ietf-pce-iana-update].


(3) Please move RFC 3209 and RFC 5036 to Informative references.

(4) There is an inconsistent use of lowercase "bytes" and "Byte".

(5) Section 7.2, s/IP address MUST be one unicast address and/IP address
MUST be a unicast address and/

(6) Section 5, you removed the mention of SRP and LSP in error handling.
Note that section 6.1. of RFC 9050 does mention error handling for missing
SRP, LSP objects alongside CCI objects. I saw Gunter's comment but I dont
think the suggestion was that the other objects should be removed.

Thanks!
Dhruv (Doc Shepherd)




On Thu, Aug 22, 2024 at 3:36 PM Aijun Wang 
wrote:

> Hi, All experts:
>
> I have uploaded the updated version of the IESG WGLC document, and wish it
> address all the comments received until now.
> If there is still any existing comments not solved, or new comments,
> please let me know.
>
> I also removed the original section for the implementation considerations.
>
> Thanks all you for your careful reviews and suggestions!
>
>
> Best Regards
>
> Aijun Wang(on behalf of all authors of this document)
>
>
>
>
> -邮件原件-
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
> 代表 internet-dra...@ietf.org
> 发送时间: 2024年8月22日 17:59
> 收件人: i-d-annou...@ietf.org
> 抄送: pce@ietf.org
> 主题: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-35.txt
>
> Internet-Draft draft-ietf-pce-pcep-extension-native-ip-35.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 Native IP Networks
>Authors: Aijun Wang
> Boris Khasanov
> Sheng Fang
> Ren Tan
> Chun Zhu
>Name:draft-ietf-pce-pcep-extension-native-ip-35.txt
>Pages:   37
>Dates:   2024-08-22
>
> Abstract:
>
>This document defines extensions to the Path Computation Element
>Communication Protocol (PCEP) to support the computation of paths for
>native IP traffic.  The proposed extensions enable a Path Computation
>Element (PCE) to calculate and manage paths via Path Computation
>Client (PCC)for native IP networks, enhancin

[Pce] Re: Adoption Poll of draft-dhody-pce-iana-update

[Dhruv Dhody]

Hi WG,

Please find a proposed update that merges draft-farrel-pce-experimental-
errors -
https://ietf-wg-pce.github.io/draft-ietf-pce-iana-update/draft-ietf-pce-iana-update.html
Diff:
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-pce-iana-update&url_2=https://ietf-wg-pce.github.io/draft-ietf-pce-iana-update/draft-ietf-pce-iana-update.txt

Please let us know if you have an objection to this update. Authors will
post the revision in the datatracker next week and will request Julien to
move this I-D quickly.
Feel free to also provide your comments and edits.

Thanks!
Dhruv & Adrian

On Mon, Aug 19, 2024 at 2:59 PM  wrote:

> Hi all,
>
> We have clear support and no objection on adopting this small I-D: it is
> now a PCE WG item.
>
> @Authors: please re-submit the draft as draft-ietf-pce-iana-update-00.
>
> @Authors of draft-farrel-pce-experimental-errors: please talk to the
> authors of the aforementioned I-D to consider adding your proposal as a
> contribution into this new WG effort.
>
> Thank you,
>
> Julien
>
>
> Le 30/07/2024 à 10:36, julien.meu...@orange.com a écrit :
> > Hi all,
> >
> > In his review of the "native IP" draft, John suggested to consider
> > adjusting to "IETF Review" the allocation policy of some of the PCEP
> > registries currently using "Standards Action". Dhruv has submitted
> > draft-dhody-pce-iana-update to quickly resolve this concern and bring
> > higher consistency among PCEP registries.
> >
> > As a result, does the WG support the adoption of
> > draft-dhody-pce-iana-update [1] as a WG item? Please, share your
> > feedback using the PCE mailing list and include your rationale in case
> > you're opposed.
> >
> > Thanks,
> >
> > Julien
> >
> >
> > [1] https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/
> ___
> 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: Roman Danyliw's Discuss on draft-ietf-pce-pcep-extension-native-ip-34: (with DISCUSS and COMMENT)

[Dhruv Dhody]

Hi Roman,

On Tue, Aug 20, 2024 at 9:38 PM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-pce-pcep-extension-native-ip-34: 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/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-pcep-extension-native-ip/
>
>
>
> --
> DISCUSS:
> --
>
> ** Section 14.2.
>
> 14.2.  PCECC-CAPABILITY sub-TLV's Flag field
>
>[RFC9050] created a sub-registry within the "Path Computation Element
>Protocol (PCEP) Numbers" registry to manage the value of the PCECC-
>CAPABILITY sub-TLV's 32-bit Flag field.  IANA is requested to
>allocate a new bit position within this registry, as follows:
>
> The registration policy of PCECC-CAPABILITY sub-TLV
> (https://www.iana.org/assignments/pcep/pcep.xhtml#pcecc-capability) is
> “Standards Action”.  This document has experimental status and does not
> qualify
> for registration.
>
>
Dhruv: We have a document in the PCE WG to fix it -
https://datatracker.ietf.org/doc/draft-ietf-pce-iana-update/
The document is being fast tracked by the WG.



>
> --
> COMMENT:
> --
>
> Thank you to Mallory Knodel for the GENART review.
>
> ** This document has been submitted with “experimental” status.  What is
> the
> nature of the experiment in question here?
>
>
>
Dhruv: Here is some initial suggested text that authors can build on -

The procedures outlined in this document are experimental. The experiment
aims to explore the use of PCE (and PCEP) for end-to-end traffic assurance
in Native IP networks through multiple BGP sessions. Additional
implementation is necessary to gain a deeper understanding of the
operational impact, scalability, and stability of the mechanism described.
Feedback from deployments will be crucial in determining whether this
specification should advance from Experimental to the IETF Standards Track.

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

[Pce] Early code point allocation for draft-ietf-pce-sr-p2mp-policy-09

[Dhruv Dhody]

Hi WG,

We have received a request from the authors of
draft-ietf-pce-sr-p2mp-policy for
an early code point allocation for the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.1
(TBD1)
https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.2-4
(TBD2)
https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.3
(TBD3-5)
https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-09.html#section-9.4
(TBD6)

RFC 7120 requires one 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.

According to the chairs’ review, the RFC 7120 criteria are met; if you
disagree and believe that the draft does not meet these criteria or believe
that early allocation is not appropriate for any other reason, please send
an email to the PCE mailing list explaining why by August 19th.

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

[Pce] Re: 答复: New draft to update IANA registration policy

[Dhruv Dhody]

Hi Tom,

IANA has made the update to -

Wavelength Restriction TLV Action Values

Registry:
https://www.iana.org/assignments/pcep/

Thanks!
Dhruv

On Mon, Jul 29, 2024 at 8:32 PM Dhruv Dhody  wrote:

> Hi Tom,
>
> On Sat, Jul 27, 2024 at 5:03 AM tom petch  wrote:
>
>> Where it says
>> 'This updates
>> | Wavelength|  [RFC8780]  |  |
>> | Restriction ||   |
>> | Constraint TLV  | |   |
>> | Action Values '
>> Is this the
>> "Wavelength Restriction TLV Action Values" subregistry ]
>> of RFC8780?
>>
>>
> In the IANA page it is called "Wavelength Restriction Constraint TLV
> Action Values"
> https://www.iana.org/assignments/pcep/pcep.xhtml#wavelength-restriction-constraint-tlv-action-values
>
> RFC 8780 uses "Wavelength Restriction TLV Action Values"
> https://www.rfc-editor.org/rfc/rfc8780.html#section-8.5
>
> With a little digging I found that the keyword "Constraint" was dropped
> from the TLV name during AUTH48 but the iana was not updated. Let me take
> action on fixing this. Thanks for spotting it!
>
> Thanks!
> Dhruv
>
>
>> Tom Petch
>> 
>> From: Aijun Wang 
>> Sent: 25 July 2024 09:16
>>
>> Hi, Dhruv:
>>
>> Thanks for your quick draft. I think IETF review is enough because the
>> required RFCs needs to be passed all the same stages
>> Although there maybe some different criteria, the related RFCs can assure
>> the interoperability of protocol from different vendors.
>>
>> The document is written clearly. If there is no objection, we can move it
>> faster to be published.
>>
>> Best Regards
>>
>> Aijun Wang
>> China Telecom
>>
>> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
>> 代表 Dhruv Dhody
>> 发送时间: 2024年7月23日 5:19
>> 收件人: pce@ietf.org
>> 主题: [Pce] New draft to update IANA registration policy
>>
>> Hi,
>>
>> I have written a small draft to update the registration policy for all
>> "standards action" to "IETF review" for PCEP registry.
>>
>> https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/
>>
>> The approach that the draft currently takes is to make a blanket change
>> to IETF-review for all "standards action" registry to allow experimental
>> track documents to request allocation. There are some registries where the
>> space is tight but IMHO IETF-review is fine -- our WG and LC process should
>> be enough to handle the case of less bits which ideally require creating a
>> new field/registry as we did in the past for LSP object flags!
>>
>> Thoughts?
>>
>> It might be a good idea to move this quickly as John suggested in his AD
>> review of Native-IP draft [1].
>>
>> Thanks!
>> Dhruv
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/pce/xBn2_9E9vy6h5AnYEMMf3I9vbqM/
>>
>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Early code point allocation for draft-ietf-pce-sid-algo-10

[Dhruv Dhody]

Hi WG,

The early allocation process has been completed. See
https://www.iana.org/assignments/pcep/pcep.xhtml#metric-object-ni-field

Thanks!
Dhruv

On Tue, Jul 23, 2024 at 7:02 AM Dhruv Dhody  wrote:

> Hi WG,
>
> We will be going ahead with the early allocation. Authors have posted
> the -11 version -
> https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-11.html
>
> The authors are planning to make another update based on the feedback from
> IANA.
>
> A point was made to mark 255 as reserved but this practice needs broader
> discussion and preferably a consistent approach across registries.
>
> Thanks!
> Dhruv & Julien
>
> On Sat, Jun 22, 2024 at 1:41 AM Dhruv Dhody  wrote:
>
>> Hi WG,
>>
>> We have received a request from the authors of draft-ietf-pce-sid-algo for
>> an early code point allocation for the codepoints listed in -
>>
>> https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7
>>
>> These are the codepoints for the latest changes made to align with 
>> draft-ietf-lsr-flex-algo-bw-con
>> as per -
>> https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/
>>
>> The chairs would like to know if there are any objections to adding these
>> new metric types and keeping a range aside for user defined metrics.
>>
>> Further, RFC 7120 requires one 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, July 8th, we will kick off the early
>> allocation request.
>>
>> Note that there was an earlier allocation request where some codepoints
>> were already allocated by IANA -
>> https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/
>>
>> Thanks!
>> Dhruv & Julien
>>
>
___
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-p2mp-policy-08.txt

[Dhruv Dhody]

Hi Hooman,

(1) As per
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-p2mp-policy-08#section-4.5.2,
what you want is to use END-POINTS Object as defined in RFC 8306. You are
adding a new Leaf type.

The corresponding IANA section refers to Generalized END-POINTS Objects
(RFC 8779) only. Note that RFC 8306 never created a registry for Leaf-type.
Thus, this document should create a registry for it. Here is my suggested
text -

9.2.  Endpoint Type

   [RFC8306] specified the P2MP END-POINTS object but did not create a
   registry for the 32-bit Leaf type field.  This document establishes
   the registry and populates it with values from [RFC8306] and adds a
   new Leaf type.  IANA is requested to create a new "Endpoint Leaf
   Types" registry with the allocation policy as IETF Review [RFC8126].
   This new registry contains the following values:

   +--++-+
   | Value| Description| Reference   |
   +--++-+
   | 0| Reserved   | This document   |
   +--++-+
   | 1| New leaves to add  | RFC 8306|
   +--++-+
   | 2| Old leaves to remove   | RFC 8306|
   +--++-+
   | 3| Old leaves whose path can  | RFC 8306|
   |  | be modified/reoptimized| |
   +--++-+
   | 4| Old leaves whose path must | RFC 8306|
   |  | be left unchanged  | |
   +--++-+
| 5| All old leaves overwritten | This document   |
   |  | and replaced with the new  | |
   +--++-+

   To keep it consistent with the Generalized Endpoint Types [RFC8779],
   this draft defines a new Endpoint Type in the "Generalized Endpoint
   Types" registry as follows:

   +---+-+-+
   | Value | Type| Reference   |
   +---+-+-+
   | TBD2  | Point-to-Multipoint | This document   |
   |   | with leaf type 5| |
   +---+-+-+

   The Authors are requesting value 5 for this new endpoint type.

(2) There is no need for 2 sections 9.3 and 9.4 when both of them are
allocated in the same TLV registries, please merge them -

9.3.  PCEP TLV Type Indicators

   This draft extends the PCEP OPEN object by defining a new optional
   TLV to indicate the PCE's capability to perform SR-P2MP path
   computation.

   Further, this draft defines two new TLVs for Identifying the P2MP
   Policy and the Replication segment with IPv4 or IPv6 root address.

   IANA is requested to allocate a new value from the IANA Registry
   "PCEP TLV Type Indicators"

   ++--++
   | TLV Type   | Description  | Reference  |
   | Value  |  ||
   ++--++
   | TBD3   | SR-P2MP-POLICY-CAPABILITY| This document  |
   ++--++
   | TBD4   | IPV4-SR-P2MP-INSTANCE-ID TLV | This document  |
   ++--++
   | TBD5   | IPV6-SR-P2MP-INSTANCE-ID TLV | This document  |
   ++--++

(3) Section 9.5 identifies a wrong registry, please fix this as -

9.4.  New CCI Object Type

   This draft defines a new CCI Object type SR P2MP Policy.

   IANA is requested to allocate new codepoints in the "PCEP Objects"
   sub-registry as follows:

   IANA is requested to allocate a new CCI Object type from the "CCI
   Object-Type" Class in the PCEP Objects table.

   +-+--++
   | Object Class| Name | Reference  |
   | Value   |  ||
   +-+--++
   | 44  | CCI Object   ||
   | | Object-Type  ||
   | | TBD6: SR P2MP Policy | This document  |
   +-+--++



I also urge you to work with your shepherd and clean up the document. I
find it hard to review.

Thanks!
Dhruv

On Tue, Jul 30, 2024 at 6:25 PM  wrote:

> Internet-Draft draft-ietf-pce-sr-p2mp-policy-08.txt is now available. It
> is a
> work item of the

[Pce] Re: IPR poll for draft-dhody-pce-iana-update

[Dhruv Dhody]

Hi Andrew,

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

Thanks!
Dhruv

On Tue, Jul 30, 2024 at 7:53 AM Andrew Stone (Nokia) 
wrote:

> 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

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

[Dhruv Dhody]

Hi All,

During the IETF 120 discussion, the conclusion was to choose option 1,
which involves continuing to use the Open message to encode the ID space
controlled by the PCE. It was suggested that a generic Notification
mechanism could be developed to update the parameters exchanged during the
Open message, outside of this I-D.

Please respond here if you disagree with your reasoning.

Thanks!
Dhruv


On Tue, Jul 9, 2024 at 12:51 PM Andrew Stone (Nokia) 
wrote:

> Hi all,
>
>
>
> I like the PcOpen + PcNotify idea, mainly because I hope we can
> generically define a pattern of PcOpen content refresh without the need for
> a session flap.  Using PcOpen+PcNotify also becomes a bit more consistent
> in approach with the similar state synchronization proposal for add/delete
> PcOpen between PCE’s. I do not think we should add (even partial)
> dependency on PCEP-LS to solve that generalized problem. I also do not
> think we should overload PcRpt since the use of PcRpt is well understood to
> be about LSP state, and mucking with it to fit other content feels like
> it's being overloaded.
>
>
>
> Therefore I think it comes down to a new message (PcOpenRefresh?) or
> leveraging PcNotify. I currently don't see a block on using PcNotify for
> this.
>
>
>
> To keep it simple I think the TLVs in the PcNotify should be a snapshot
> equal to the same content as if this was PcOpen upon connect (i.e don't
> send diff).  In other words as an example with
> draft-ietf-pce-controlled-id-space, if someone adds a new range to the PCC,
> the PcNotify would carry a LABEL-CONTROLS-SPACE-TLV which contains both
> existing and new ranges and not build in add/remove/diff semantics inside
> of the TLV itself.
>
>
>
> Thanks
>
> Andrew
>
>
>
> *From: *Cheng Li 
> *Date: *Tuesday, July 9, 2024 at 6:28 AM
> *To: *Dhruv Dhody 
> *Cc: *pce@ietf.org , pce-chairs ,
> Samuel Sidor (ssidor) 
> *Subject: *RE: [Pce] Where the Controlled ID info shuold be
> carried/encoded?
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> 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  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 
> 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

[Pce] Re: 答复: AD review of draft-ietf-pce-pcep-extension-native-ip-30

[Dhruv Dhody]

Hi Aijun,

Thanks for making these changes.

I did a review of
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pcep-extension-native-ip-30&url2=draft-ietf-pce-pcep-extension-native-ip-32&difftype=--html

A few things to consider alongside any other IETF LC comments -

- Section 3, we have added references for a few but not for others.
Consider adding references for terms that are already defined in other RFCs
to keep it consistent.
- Section 12, capitalize "if" in the last paragraph.
- Section 14.6, 14.7 and 14.8, please change "standard action" to "IETF
review".

Note that, for section 14.2 allocation, we need to wait
for draft-dhody-pce-iana-update to make progress.

Thanks!
Dhruv


On Mon, Jul 29, 2024 at 2:36 AM Aijun Wang 
wrote:

> Hi, John:
>
>
>
> I have uploaded the updated version at
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-32
>  and
> wish it address all your concerns.
>
> If there is no more comments, we can put forward it to the IESG LC review
> then.
>
> Thanks in advance for your efforts!
>
>
>
> Some detail replies can see inline below.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org
> ] *代表 *【外部账号】 John Scudder
> *发送时间:* 2024年7月26日 23:59
> *收件人:* Aijun Wang 
> *抄送:* draft-ietf-pce-pcep-extension-native...@ietf.org; pce@ietf.org;
> bhassa...@yahoo.com; fsh...@huawei.com; tan...@huawei.com;
> zhu.ch...@zte.com.cn
> *主题:* Re: AD review of draft-ietf-pce-pcep-extension-native-ip-30
>
>
>
> Hi Aijun,
>
>
>
> Thanks for the update. I have a few more comments, below. I have trimmed
> for brevity, indicated by […], anything trimmed is agreed or anyway doesn’t
> need more discussion.
>
>
>
> If you can update to reflect these comments I think we can send it for
> IETF last call.
>
>
>
> On Jul 22, 2024, at 5:37 AM, Aijun Wang  wrote:
>
>
> Hi, John:
>
> I have updated draft according to your suggestions at
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip__;!!NEt6yMaO-gk!B09SQ9s42Y1hsFo8BANfznJ4lysLpngvzlzwp9ULLAbS_FzVRmaT6Jx-RsCqbWt6uHiW1t3973FwFYcuh7li0A$
> 
> For the document track, I think it is OK to move it forward as the
> experimental track, we will try to update it later to the standard track
> after its experimental deployment.
> The detail responses are inline below【WAJ】
>
> If there is more suggestions, please let us know. Or else, can we schedule
> the IESG Last Call then?
>
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
>
>
> […]
>
>
>
>During the establishment procedure, PCC should report to the PCE the
>status of the BGP session via the PCRpt message, with the status @@
> -453,7 +547,16 @@
>When PCC receives this message with the R bit set to 1 in SRP object
>in PCInitiate message, the PCC should clear the BGP session that is
>indicated by the BPI object.
> ++---
> +jgs: The term "clear the BGP session" isn't standard (although it is
> +common colloquial usage). Looking at RFC 4271, in one place (Section 3)
> +it does talk about "resetting any BGP connections" so I think you would
> +be on firm ground if you want to say "reset". Or you might consider
> +referencing the AutomaticStop event (RFC 4271, Section 8.1.2, Event 8).
>
> 【WAJ】： Here, “clear the BGP session” is just want to express the deletion
> of the BGP configuration on PCC, not reset the BGP connection.
> Should it be more clearer, if we instead say "clear the BGP session
> configuration"?--Have updated the descriptions accordingly.
>
>
>
> Yes, that’s an improvement. This leaves it ambiguous whether the session
> should be torn down immediately or not, do you intend that? E.g. in some
> implementations, a configuration change is not reflected in the operational
> state until a commit (or equivalent) is performed.
>
> 【WAJ】How about “the PCC should clear the BGP configuration and tear down
> the BGP session that is indicated by the BPI object.”? I think it is more
> clear. I have updated the contents according to the above statements.
>
> […]
>
>Such explicit routes operate the same as static routes installed by
>network management protocols (Network Configuration Protocol
>(NETCONF)/YANG).  The procedures of such explicit route addition and @@
> -582,6 +689,9 @@
>
>The PCInitiate message should be sent to the on-path routers
>respectively.  In the example, for explicit route from R1 to R7, the
> ++---
> +jgs: What does “respectively” mean here? Can it be removed?
> 【WAJ】Here, we just want to describe such message should be sent every
> router on the path, each may has different content, for example, the
> different next hop information.
>
>
>
> OK thanks. In that case, wh

[Pce] Re: PCE WG minutes for IETF 120

[Dhruv Dhody]

Thanks Andrew for taking care of the minutes!

A few minor editorial changes were made -
https://datatracker.ietf.org/doc/minutes-120-pce-202407252200/

Thanks!
Dhruv

On Mon, Jul 29, 2024 at 3:08 PM Andrew Stone (Nokia) 
wrote:

> Hi WG,
>
>
>
> Please find the minutes for PCE WG session
> https://datatracker.ietf.org/meeting/120/materials/minutes-120-pce-202407252200-01
>
>
>
> Thanks to those who contributed to the minutes.
>
>
>
> Please reach out to pce-cha...@ietf.org in case any correction needs to
> be made.
>
>
>
> Thanks,
>
> Dhruv, Julien & Andrew
>
>
>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: 答复: New draft to update IANA registration policy

[Dhruv Dhody]

Hi Tom,

On Sat, Jul 27, 2024 at 5:03 AM tom petch  wrote:

> Where it says
> 'This updates
> | Wavelength|  [RFC8780]  |  |
> | Restriction ||   |
> | Constraint TLV  | |   |
> | Action Values '
> Is this the
> "Wavelength Restriction TLV Action Values" subregistry ]
> of RFC8780?
>
>
In the IANA page it is called "Wavelength Restriction Constraint TLV Action
Values"
https://www.iana.org/assignments/pcep/pcep.xhtml#wavelength-restriction-constraint-tlv-action-values

RFC 8780 uses "Wavelength Restriction TLV Action Values"
https://www.rfc-editor.org/rfc/rfc8780.html#section-8.5

With a little digging I found that the keyword "Constraint" was dropped
from the TLV name during AUTH48 but the iana was not updated. Let me take
action on fixing this. Thanks for spotting it!

Thanks!
Dhruv


> Tom Petch
> 
> From: Aijun Wang 
> Sent: 25 July 2024 09:16
>
> Hi, Dhruv:
>
> Thanks for your quick draft. I think IETF review is enough because the
> required RFCs needs to be passed all the same stages
> Although there maybe some different criteria, the related RFCs can assure
> the interoperability of protocol from different vendors.
>
> The document is written clearly. If there is no objection, we can move it
> faster to be published.
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
> 代表 Dhruv Dhody
> 发送时间: 2024年7月23日 5:19
> 收件人: pce@ietf.org
> 主题: [Pce] New draft to update IANA registration policy
>
> Hi,
>
> I have written a small draft to update the registration policy for all
> "standards action" to "IETF review" for PCEP registry.
>
> https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/
>
> The approach that the draft currently takes is to make a blanket change to
> IETF-review for all "standards action" registry to allow experimental track
> documents to request allocation. There are some registries where the space
> is tight but IMHO IETF-review is fine -- our WG and LC process should be
> enough to handle the case of less bits which ideally require creating a new
> field/registry as we did in the past for LSP object flags!
>
> Thoughts?
>
> It might be a good idea to move this quickly as John suggested in his AD
> review of Native-IP draft [1].
>
> Thanks!
> Dhruv
>
> [1] https://mailarchive.ietf.org/arch/msg/pce/xBn2_9E9vy6h5AnYEMMf3I9vbqM/
>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: 答复: New draft to update IANA registration policy

[Dhruv Dhody]

Hi Samuel,

On Thu, Jul 25, 2024 at 1:28 AM Samuel Sidor (ssidor) 
wrote:

> Hi Dhruv,
>
>
>
> I support change itself.
>
>
>
> One comment for note/question in the draft:
>
> Question to the WG: The current document updates all
>
> the registries. Should we keep "Standards Action" for
>
> some of them such as flag fields with limited bits?
>
>
>
> I’m personally not worried about that. We should be able to use same
> approach as used for LSP object flags.
>
>
>
> One exception, which I can think of are fixed size objects, which may not
> be allowing TLVs currently (I’m not sure if there is any specific example
> in the list of registries). Do we have any specific plan for those?
>
>
>

I did a quick manual check. We mostly dont have this problem with one
exception of flag fields in sub-objects.

Things to note -
- there are already some subobjects flag field that are IETF review
- some of these have reserved fields that can be easily used
- we could extend by creating a new sub-object type if needed

Thanks!
Dhruv



> Thanks,
>
> Samuel
>
>
>
> *From:* Aijun Wang 
> *Sent:* Thursday, July 25, 2024 10:17 AM
> *To:* 'Dhruv Dhody' ; pce@ietf.org
> *Subject:* [Pce] 答复: New draft to update IANA registration policy
>
>
>
> Hi, Dhruv:
>
>
>
> Thanks for your quick draft. I think IETF review is enough because the
> required RFCs needs to be passed all the same stages
>
> Although there maybe some different criteria, the related RFCs can assure
> the interoperability of protocol from different vendors.
>
>
>
> The document is written clearly. If there is no objection, we can move it
> faster to be published.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人**:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org
> ] *代表 *Dhruv Dhody
> *发送时间:* 2024年7月23日 5:19
> *收件人:* pce@ietf.org
> *主题:* [Pce] New draft to update IANA registration policy
>
>
>
> Hi,
>
>
>
> I have written a small draft to update the registration policy for all
> "standards action" to "IETF review" for PCEP registry.
>
>
>
> https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/
>
>
>
> The approach that the draft currently takes is to make a blanket change to
> IETF-review for all "standards action" registry to allow experimental track
> documents to request allocation. There are some registries where the space
> is tight but IMHO IETF-review is fine -- our WG and LC process should be
> enough to handle the case of less bits which ideally require creating a new
> field/registry as we did in the past for LSP object flags!
>
>
>
> Thoughts?
>
>
>
> It might be a good idea to move this quickly as John suggested in his AD
> review of Native-IP draft [1].
>
>
>
> Thanks!
>
> Dhruv
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/pce/xBn2_9E9vy6h5AnYEMMf3I9vbqM/
>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Early code point allocation for draft-ietf-pce-sid-algo-10

[Dhruv Dhody]

Hi WG,

We will be going ahead with the early allocation. Authors have posted
the -11 version -
https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-11.html

The authors are planning to make another update based on the feedback from
IANA.

A point was made to mark 255 as reserved but this practice needs broader
discussion and preferably a consistent approach across registries.

Thanks!
Dhruv & Julien

On Sat, Jun 22, 2024 at 1:41 AM Dhruv Dhody  wrote:

> Hi WG,
>
> We have received a request from the authors of draft-ietf-pce-sid-algo for
> an early code point allocation for the codepoints listed in -
>
> https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7
>
> These are the codepoints for the latest changes made to align with 
> draft-ietf-lsr-flex-algo-bw-con
> as per -
> https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/
>
> The chairs would like to know if there are any objections to adding these
> new metric types and keeping a range aside for user defined metrics.
>
> Further, RFC 7120 requires one 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, July 8th, we will kick off the early allocation
> request.
>
> Note that there was an earlier allocation request where some codepoints
> were already allocated by IANA -
> https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/
>
> Thanks!
> Dhruv & Julien
>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

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

[Dhruv Dhody]

Forwarding the IPR response to the mailing list to archive it!

-- Forwarded message -
From: Siva Sivabalan 
Date: Tue, Jul 16, 2024 at 4:56 AM
Subject: Re: IPR poll for draft-ietf-pce-stateful-pce-vendor
To: Andrew Stone (Nokia) 
Cc: Samuel Sidor (ssidor) , Cheng Li ,
Zhenghaomian , Zafar Ali (zali) ,
pce-cha...@ietf.org 


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

Thanks,
Siva

On Mon, Jul 15, 2024 at 9:17 PM Andrew Stone (Nokia) 
wrote:

> Hi Authors,
>
>
>
> Friendly reminder of the below (Thanks Cheng and Samuel for replying!)
>
>
>
> Note: I’ve removed pce@ietf from the TO: to not spam the list, please
> reply to the original thread / original email.
>
>
>
> Thanks!
>
> Andrew
>
>
>
> *From: *Samuel Sidor (ssidor) 
> *Date: *Monday, July 8, 2024 at 4:07 AM
> *To: *Cheng Li , Andrew Stone (Nokia) <
> andrew.st...@nokia.com>, Zhenghaomian ,
> msiva...@gmail.com , Zafar Ali (zali) ,
> pce-cha...@ietf.org 
> *Cc: *pce@ietf.org 
> *Subject: *RE: IPR poll for draft-ietf-pce-stateful-pce-vendor
>
> I am not aware of any IPR applicable to this draft that should be
> disclosed in accordance with IETF IPR rules.
>
>
>
> Regards,
>
> Samuel
>
>
>
> *From:* Cheng Li 
> *Sent:* Friday, July 5, 2024 2:46 PM
> *To:* Andrew Stone (Nokia) ; Zhenghaomian <
> zhenghaom...@huawei.com>; msiva...@gmail.com; Samuel Sidor (ssidor) <
> ssi...@cisco.com>; Zafar Ali (zali) ; pce@ietf.org;
> pce-cha...@ietf.org
> *Subject:* RE: IPR poll for draft-ietf-pce-stateful-pce-vendor
>
>
>
> 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

[Dhruv Dhody]

Hi WG,

The WGLC is closed. Thanks for everyone's comments and feedback.

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

Thanks!
Dhruv & Julien


On Thu, Jul 4, 2024 at 6:17 AM Dhruv Dhody  wrote:

> 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: Experimental Error-Types and Error-values

[Dhruv Dhody]

Hi Adrian,

As a WG participant...

On Wed, Jul 3, 2024 at 3:45 AM Adrian Farrel  wrote:

> Hi working group,
>
> I just refreshed draft-farrel-pce-experimental-errors and cleaned up a
> couple of nits.
>
> It tweaks the scope of the IANA registry to carve out a few Error-Types to
> be for Experimental Use. It also describes how to experiment with
> Error-Types and Error-values
>
> BIG QUESTION
>
> Does the working group want to pursue this?
>

IMHO it might be worth doing this. Can those who have used
experimental codepoints for messages, objects and TLV comment on the need
for them for error-types? Could this have helped you in your experiments?

If we go down in this direction, I also wonder if we should reserve some
space for error-values for each of the error-types as it is common practice
to assign new errors under the error-type!

Thanks!
Dhruv



> If so: chairs, can we consider adoption?
> If not: I can get a little peace by dropping the draft
>
> Cheers,
> Adrian
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: 03 July 2024 11:34
> To: Adrian Farrel ; Haomian Zheng <
> zhenghaom...@huawei.com>
> Subject: New Version Notification for
> draft-farrel-pce-experimental-errors-02.txt
>
> A new version of Internet-Draft draft-farrel-pce-experimental-errors-02.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
>
> Name: draft-farrel-pce-experimental-errors
> Revision: 02
> Title:Allowing Experimental Error Codes in the Path Computation
> Element Protocol
> Date: 2024-07-03
> Group:Individual Submission
> Pages:7
> URL:
> https://www.ietf.org/archive/id/draft-farrel-pce-experimental-errors-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-farrel-pce-experimental-errors/
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-farrel-pce-experimental-errors
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-farrel-pce-experimental-errors-02
>
> Abstract:
>
>Experimental RFCs are often considered beneficial approaches to
>developing new protocol features.  To that end, sub-ranges of code
>point registries are often designated as for experimental use.
>
>IANA assigns values to the Path Computation Element Communication
>Protocol (PCEP) parameters (messages, objects, TLVs).  According to
>RFC 5440 as updated by RFC 8356, the allocation policies for the
>registries for PCEP messages, objects, and TLV types are IETF Review
>with some sub-ranges of these registries being assigned for
>Experimental Use.  However, the registry of PCEP Error-Types and
>Error-values has only the IETF Review assignment policy meaning that
>experimentation is somewhat limited.
>
>This document updates RFC 5440 by designating a range of PCEP Error-
>Types for Experimental Use.
>
> ___
> 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] New draft to update IANA registration policy

[Dhruv Dhody]

Hi,

I have written a small draft to update the registration policy for all
"standards action" to "IETF review" for PCEP registry.

https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/

The approach that the draft currently takes is to make a blanket change to
IETF-review for all "standards action" registry to allow experimental track
documents to request allocation. There are some registries where the space
is tight but IMHO IETF-review is fine -- our WG and LC process should be
enough to handle the case of less bits which ideally require creating a new
field/registry as we did in the past for LSP object flags!

Thoughts?

It might be a good idea to move this quickly as John suggested in his AD
review of Native-IP draft [1].

Thanks!
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/pce/xBn2_9E9vy6h5AnYEMMf3I9vbqM/
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] PCE WG Agenda for IETF 120

[Dhruv Dhody]

Hi WG,

The **draft** agenda for the PCE WG sessions during IETF 120 is posted -
https://datatracker.ietf.org/doc/agenda-120-pce/

Please unicast us if there is any change needed.

Please note that the allocated time includes time for Q&A.
Please use the mailing list to bring out the key point that you would like
to discuss during the WG session.
Please send your slides (in pdf format) to emails in the CC in advance by
Sunday July 21st.

Useful information for both in-person and online participation can be found
at - https://www.ietf.org/how/meetings/preparation/.
Refresh your knowledge of Meetecho  -
https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/

Thanks!
Dhruv, Julien & Andrew

ICS file to add to your calendar:
https://datatracker.ietf.org/meeting/120/session/33041.ics
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Pending item for draft-ietf-pce-state-sync

[Dhruv Dhody]

Hi Samuel,

On Tue, Jul 9, 2024 at 12:30 PM Samuel Sidor (ssidor) 
wrote:

> Hi Andrew, Dhruv,
>
>
>
> Proposed text looks fine to me.
>
>
>
> Do we also need to consider future result of discussion for controlled ID?
> E.g. if decision will be done to use Notification message for ID space
> advertisement, will we need to synchronize content of those on top of TLVs
> from Open object?
>
>
>

Personally, I consider controlled ID (and PCECC) to be out of scope of the
state-sync I-D. We can make that explicit in the I-D.
In future another specification can tackle it if there is a need and can
use the technique that you suggest.

Thanks!
Dhruv


> Thanks,
>
> Samuel
>
>
>
> *From:* Dhruv Dhody 
> *Sent:* Tuesday, July 9, 2024 11:18 AM
> *To:* Andrew Stone (Nokia) 
> *Cc:* draft-ietf-pce-state-s...@ietf.org; pce@ietf.org; pce-chairs <
> pce-cha...@ietf.org>
> *Subject:* [Pce] Re: Pending item for draft-ietf-pce-state-sync
>
>
>
> Hi Andrew,
>
>
>
> On Mon, Jul 8, 2024 at 4:37 PM Andrew Stone (Nokia)  40nokia@dmarc.ietf.org> wrote:
>
> Hi Dhruv, PCE WG
>
>
>
> Thanks for bringing this up again. PcNotif object with an add/remove
> semantics is exactly what I was thinking about as well in terms of how to
> carry this. I think we could (later) expand this to PCC->PCE communication
> to permit on-the-fly updates/changes to PcOpen criteria to avoid requiring
> session flap should knobs be flipped. With that said, I do like the
> proposed scoping of this via notification type so that way delete mechanics
> can only be applied for state sync.
>
>
>
> Minor recommendation to clarify the PcNtf should be sent before StateSync
> / PcRpt messages:
>
>
>
> *On session establishment with a state-sync PCE, the PCE MUST also
> exchange*
>
> *notifications for each of the PCCs it already has a session*
>
> *established prior to State Synchronization described in section 3.2.*
>
>
>
>
>
> Dhruv: I suggest adding this here ->
>
>
>
>*  Notification-value=1: Add PCC's Open Information.  On session
>   establishment with a PCC, a PCE with state-sync capability MUST
>   send this notification to other state-sync PCEs with the SPEAKER-
>   ENTITY-ID TLV with values that identify the PCC and any other TLVs
>   encoded in the OPEN object received from the PCC.  On session
>   establishment with a state-sync PCE, the PCE MUST also exchange
>   notifications for each of the PCCs it already has a session
>   established.  The PCE MUST exchange this notification prior to the
>   State Synchronization (described in Section 3.2).  Note that the
>   PCNtf can be used to carry multiple NOTIFICATION objects, one for
>   each PCC.  On receiving this notification, PCE adds the
>   information to its database.
>
>
>
>
>
> Overall text proposal looks good to me. I would assume this belongs in a
> 3.x section in the document.
>
>
>
>
>
> I suggest that this could be a subsection "3.5.1.  Information Received
> via Open Message from PCC"
>
>
>
> Thanks!
>
> Dhruv
>
>
>
>
>
> Only caveat I can see is there would be no mechanism to potentially carry
> flag values from the PcOpen object, however, there's currently no flags
> defined after all these years and I suspect if they ever were defined they
> likely may not be relevant for state sync anyways. Should it ever be
> required, it would be straight forward to define a new TLV for pce-state
> sync to carry that anyways. I do not think we need to handle this now.
>
>
>
> Thanks!
>
> Andrew
>
>
>
> *From: *Dhruv Dhody 
> *Date: *Saturday, July 6, 2024 at 7:52 AM
> *To: *draft-ietf-pce-state-s...@ietf.org <
> draft-ietf-pce-state-s...@ietf.org>, Andrew Stone (Nokia) <
> andrew.st...@nokia.com>
> *Cc: *pce@ietf.org , pce-chairs 
> *Subject: *Pending item for draft-ietf-pce-state-sync
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Hi,
>
> There has been one pending item in draft-ietf-pce-state-sync. During IETF
> 119, we discussed adding support for the PCE to send the information it 
> received
> in the PCC's open message to the other state-sync PCEs.
>
> Here is my initial proposal of using a new notification type for this
> purpose. I have some initial text that authors and WG can consider. We
> can discuss this during IETF 120 as well if required.
>
> ---
>
> 3.5.1.  Information Received via Open Message from PCC
>
>T

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

[Dhruv Dhody]

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  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 
> 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
>>
>> 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 mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Pending item for draft-ietf-pce-state-sync

[Dhruv Dhody]

Hi Andrew,

On Mon, Jul 8, 2024 at 4:37 PM Andrew Stone (Nokia)  wrote:

> Hi Dhruv, PCE WG
>
>
>
> Thanks for bringing this up again. PcNotif object with an add/remove
> semantics is exactly what I was thinking about as well in terms of how to
> carry this. I think we could (later) expand this to PCC->PCE communication
> to permit on-the-fly updates/changes to PcOpen criteria to avoid requiring
> session flap should knobs be flipped. With that said, I do like the
> proposed scoping of this via notification type so that way delete mechanics
> can only be applied for state sync.
>
>
>
> Minor recommendation to clarify the PcNtf should be sent before StateSync
> / PcRpt messages:
>
>
>
> *On session establishment with a state-sync PCE, the PCE MUST also
> exchange*
>
> *notifications for each of the PCCs it already has a session*
>
> *established prior to State Synchronization described in section 3.2.*
>
>
>

Dhruv: I suggest adding this here ->

   *  Notification-value=1: Add PCC's Open Information.  On session
  establishment with a PCC, a PCE with state-sync capability MUST
  send this notification to other state-sync PCEs with the SPEAKER-
  ENTITY-ID TLV with values that identify the PCC and any other TLVs
  encoded in the OPEN object received from the PCC.  On session
  establishment with a state-sync PCE, the PCE MUST also exchange
  notifications for each of the PCCs it already has a session
  established.  The PCE MUST exchange this notification prior to the
  State Synchronization (described in Section 3.2).  Note that the
  PCNtf can be used to carry multiple NOTIFICATION objects, one for
  each PCC.  On receiving this notification, PCE adds the
  information to its database.



> Overall text proposal looks good to me. I would assume this belongs in a
> 3.x section in the document.
>
>
>

I suggest that this could be a subsection "3.5.1.  Information Received via
Open Message from PCC"

Thanks!
Dhruv



> Only caveat I can see is there would be no mechanism to potentially carry
> flag values from the PcOpen object, however, there's currently no flags
> defined after all these years and I suspect if they ever were defined they
> likely may not be relevant for state sync anyways. Should it ever be
> required, it would be straight forward to define a new TLV for pce-state
> sync to carry that anyways. I do not think we need to handle this now.
>
>
>
> Thanks!
>
> Andrew
>
>
>
> *From: *Dhruv Dhody 
> *Date: *Saturday, July 6, 2024 at 7:52 AM
> *To: *draft-ietf-pce-state-s...@ietf.org <
> draft-ietf-pce-state-s...@ietf.org>, Andrew Stone (Nokia) <
> andrew.st...@nokia.com>
> *Cc: *pce@ietf.org , pce-chairs 
> *Subject: *Pending item for draft-ietf-pce-state-sync
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Hi,
>
> There has been one pending item in draft-ietf-pce-state-sync. During IETF
> 119, we discussed adding support for the PCE to send the information it 
> received
> in the PCC's open message to the other state-sync PCEs.
>
> Here is my initial proposal of using a new notification type for this
> purpose. I have some initial text that authors and WG can consider. We
> can discuss this during IETF 120 as well if required.
>
> ---
>
> 3.5.1.  Information Received via Open Message from PCC
>
>To ensure uniform information across all PCEs, each PCE needs to
>relay the information it receives from the PCCs in the Open message
>to other PCEs via the state-sync session.  This includes various PCC
>capabilities and parameters such as Maximum Segment Identifier (SID)
>Depth (MSD).
>
>As per [RFC5440], the PCEP Notification message (PCNtf) can be sent
>by a PCEP speaker to notify its peer of a specific event.  A PCE
>should notify the other state-sync PCEs of the information it
>receives from the PCCs open message.  Section 7.14 of [RFC5440]
>specify the NOTIFICATION object.  This document adds a new
>Notification-type=TBD6 (Inter-PCE State-sync) and two Notification-
>values (Notification-value=1 (Add PCC's Open Information) and
>Notification-value=2 (Remove PCC's Open Information)).
>
>For Notification-type=TBD6, the NOTIFICATION object encodes the
>SPEAKER-ENTITY-ID TLV and any other TLV that can be carried inside
>the OPEN object as a way to signal the PCC's information it received
>via the open message to other state-sync PCEs.
>
>*  Notification-value=1: Add PCC's Open Information.  On session

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

[Dhruv Dhody]

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 
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
>
> 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 mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Pending item for draft-ietf-pce-state-sync

[Dhruv Dhody]

Hi,

There has been one pending item in draft-ietf-pce-state-sync. During IETF
119, we discussed adding support for the PCE to send the information
it received
in the PCC's open message to the other state-sync PCEs.

Here is my initial proposal of using a new notification type for this
purpose. I have some initial text that authors and WG can consider. We can
discuss this during IETF 120 as well if required.

---
3.5.1.  Information Received via Open Message from PCC

   To ensure uniform information across all PCEs, each PCE needs to
   relay the information it receives from the PCCs in the Open message
   to other PCEs via the state-sync session.  This includes various PCC
   capabilities and parameters such as Maximum Segment Identifier (SID)
   Depth (MSD).

   As per [RFC5440], the PCEP Notification message (PCNtf) can be sent
   by a PCEP speaker to notify its peer of a specific event.  A PCE
   should notify the other state-sync PCEs of the information it
   receives from the PCCs open message.  Section 7.14 of [RFC5440]
   specify the NOTIFICATION object.  This document adds a new
   Notification-type=TBD6 (Inter-PCE State-sync) and two Notification-
   values (Notification-value=1 (Add PCC's Open Information) and
   Notification-value=2 (Remove PCC's Open Information)).

   For Notification-type=TBD6, the NOTIFICATION object encodes the
   SPEAKER-ENTITY-ID TLV and any other TLV that can be carried inside
   the OPEN object as a way to signal the PCC's information it received
   via the open message to other state-sync PCEs.

   *  Notification-value=1: Add PCC's Open Information.  On session
  establishment with a PCC, a PCE with state-sync capability MUST
  send this notification to other state-sync PCEs with the SPEAKER-
  ENTITY-ID TLV with values that identify the PCC and any other TLVs
  encoded in the OPEN object received from the PCC.  On session
  establishment with a state-sync PCE, the PCE MUST also exchange
  notifications for each of the PCCs it already has a session
  established.  Note that the PCNtf can be used to carry multiple
  NOTIFICATION objects, one for each PCC.  On receiving this
  notification, PCE adds the information to its database.

   *  Notification-value=2: Remove PCC's Open Information.  On session
  down with a PCC, a PCE with state-sync capability MUST send this
  notification to other state-sync PCEs with the SPEAKER-ENTITY-ID
  TLV with values that identify the PCC to remove the information
  from the database.

   A PCE may receive this Notification from multiple PCEs that a given
   PCC has a session and can use a similar mechanism as described in
   Section 3.4 to keep the freshest state.  In case of the termination
   of state-sync session, this information is also cleaned up alongside
   LSP-DB.
---


Would this be a good way forward? Am I missing something? Is there any
other proposal on the table?

Thanks!

Dhruv (no-hats!)
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Publication has been requested for draft-ietf-pce-segment-routing-policy-cp-17

[Dhruv Dhody via Datatracker]

Dhruv Dhody has requested publication of 
draft-ietf-pce-segment-routing-policy-cp-17 as Proposed Standard on behalf of 
the PCE working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/


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

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

[Dhruv Dhody]

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: WGLC for draft-ietf-pce-pcep-color-04

[Dhruv Dhody]

Hi WG,

The WGLC is closed. Thanks for everyone's comments and feedback.

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

Thanks!
Dhruv & Julien

On Sun, Jun 16, 2024 at 5:23 AM Dhruv Dhody  wrote:

> Hi WG,
>
> Reminder to respond to this WGLC poll.
> Please be more explicit in your support (or not) for publishing this I-D
> by responding on the mailing list. Silence makes it hard to judge
> consensus.
>
> Thanks!
> Dhruv
>
>
> On Tue, Jun 4, 2024 at 9:20 AM Dhruv Dhody  wrote:
>
>> Hi WG,
>>
>> This email starts a 2-weeks working group last call
>> for draft-ietf-pce-pcep-color-04.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-color/
>>
>> 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 18 June 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: Early code point allocation for draft-ietf-pce-sid-algo-10

[Dhruv Dhody]

Hi Tom,



On Sat, Jun 22, 2024 at 12:25 PM tom petch  wrote:

> From: Dhruv Dhody 
> Sent: 22 June 2024 09:41
>
> Hi WG,
>
> We have received a request from the authors of draft-ietf-pce-sid-algo for
> an early code point allocation for the codepoints listed in -
>
> https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7
>
> These are the codepoints for the latest changes made to align with
> draft-ietf-lsr-flex-algo-bw-con as per -
> https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/
>
> The chairs would like to know if there are any objections to adding these
> new metric types and keeping a range aside for user defined metrics.
>
> 
> Looking at what I think is the right table, I see that the value zero is
> reserved which I always think is a good start.  But this request allows the
> value of 255 as part of the range which I always think a bad idea.  I think
> that this, the maximum value, should be reserved e.g. lest the range is
> fully assigned and a value is needed to act as an escape.  For such
> purposes, I think one value is enough so I think that the range should end
> at 254 nd tnot 255
>
>
Dhruv: Looking at our existing allocations at
https://www.iana.org/assignments/pcep/pcep.xhtml

We do not mark 255 (or equivalent MAX) as reserved.

If we want to do it, I prefer we discuss this independently and apply it
across all PCEP registries!
I will also write to IANA to find out if they have a suggestion on what
ought to be the best practice for this!

Thanks!
Dhruv



> Tom Petch
>
> Further, RFC 7120 requires one 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, July 8th, we will kick off the early allocation
> request.
>
> Note that there was an earlier allocation request where some codepoints
> were already allocated by IANA -
> https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/
>
> Thanks!
> Dhruv & Julien
>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Call for slot in the PCE WG at IETF 120

[Dhruv Dhody]

Hi,

The PCE WG would be meeting during the IETF 120 [1] week. If you need
agenda time to progress some work, please send a slot request directly to
the chairs/secretary  by Monday, July 8th 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 also
Monday, July 8th [2]. Also, let us know if you have requested agenda time
in a different WG session for the same topic.

Thanks!
PCE Chairs & Secretary

[1] https://datatracker.ietf.org/meeting/120/agenda
[2] https://datatracker.ietf.org/meeting/important-dates/
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

[Dhruv Dhody]

Hi WG,

We have received a request from the authors of draft-ietf-pce-sid-algo for
an early code point allocation for the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7

These are the codepoints for the latest changes made to align with
draft-ietf-lsr-flex-algo-bw-con
as per -
https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/

The chairs would like to know if there are any objections to adding these
new metric types and keeping a range aside for user defined metrics.

Further, RFC 7120 requires one 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, July 8th, we will kick off the early allocation
request.

Note that there was an earlier allocation request where some codepoints
were already allocated by IANA -
https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/

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

[Pce] Re: WGLC for draft-ietf-pce-pcep-color-04

[Dhruv Dhody]

Hi WG,

Reminder to respond to this WGLC poll.
Please be more explicit in your support (or not) for publishing this I-D by
responding on the mailing list. Silence makes it hard to judge consensus.

Thanks!
Dhruv


On Tue, Jun 4, 2024 at 9:20 AM Dhruv Dhody  wrote:

> Hi WG,
>
> This email starts a 2-weeks working group last call
> for draft-ietf-pce-pcep-color-04.
>
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-color/
>
> 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 18 June 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: IPR poll for draft-ietf-pce-pcep-color

[Dhruv Dhody]

Hi Pavan & Gyan,

We have an IPR response missing from you. Please respond.

Thanks!
Dhruv

On Wed, Jun 5, 2024 at 1:21 AM Andrew Stone (Nokia) 
wrote:

> 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] WGLC for draft-ietf-pce-pcep-color-04

[Dhruv Dhody]

Hi WG,

This email starts a 2-weeks working group last call
for draft-ietf-pce-pcep-color-04.

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

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 18 June 2024.

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

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

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

[Dhruv Dhody]

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  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: Shepherd Review of draft-ietf-pce-pcep-yang

[Dhruv Dhody]

Hi Julien,


On Tue, May 21, 2024 at 10:26 PM  wrote:

> Hi Dhruv,
>
> Thanks for addressing my comments. The new version looks good to me.
>
> Please note however that idnits shouts because of too long lines: have you
> tried circumvent it?
>
>
New version -25 posted where idnits runs clear!

Thanks,
Dhruv



> Cheers,
>
> Julien
>
>
> On 17/05/2024 08:51, Dhruv Dhody wrote:
>
>
> HI Julien,
>
> On Thu, May 16, 2024 at 7:57 PM  wrote:
>
>> Dear authors of draft-ietf-pce-pcep-yang,
>>
>> I've reviewed the aforementioned document to prepare its publication
>> request. The I-D is almost ready to move forward and only has minor
>> issues and nits that should be addressed before sending it to the IESG.
>>
>> Minor issues:
>> - The introduction doesn't mention the ietf-pcep-stats module though
>> it's defined in the body of the I-D; a brief additional sentence would
>> be welcome.
>>
>
> Dhruv: Added "Further, this document also includes the PCEP statistics
> YANG module "ietf-pcep-stats" which provides statistics, counters and 
> telemetry
> data."
>
>
>> - For SR, the leaf "msd-limit" (page 45) is a boolean that should be
>> renamed to be understandable, e.g. into "no-msd-limit" or "ignore-msd".
>>
>
> Dhruv: changed to "no-msd-limit".
>
>
>
>> - On page 46, in the H-PCE section, there's a "if Stateful GMPLS is
>> enabled" left instead of "if H-PCE is enabled.
>>
>
> Dhruv: thanks for spotting that
>
>
>
>> - Section 7.1 about TLS should be deeply summarized and rather point to
>> the referenced document (pointer to be updated).
>>
>
> Dhruv: Changed to -- "The PCC acting as the TLS client opens the TLS
> connection and the PCE acting as the TLS server listens for incoming
> connections as per TLS specifications ([RFC8446] and [RFC5246]). [RFC8253]
> specifies the StartTLS procedure in PCEP that initiates the TLS connection
> before exchanging PCEP messages thus the identity verification is
> completed before the PCEP session is established."
>
>
>> - On page 51, in the description of the hexadecimal case, I don't think
>> the 2 long sentences about the rationale should be included there; if
>> the authors consider it necessary, it may be included in the text body
>> of the draft.
>>
>
> Dhruv: The text/approach is borrowed from RFC 8177. I prefer to keep it.
>
>
>
>> - On page 59, similar comment about the sync-timer description, which
>> I'd shorten into the following:
>>"The value of SyncTimer in seconds is used in the
>> case of synchronized path computation request
>> using the SVEC object. If after the expiration of
>> the SyncTimer all the path computation requests
>> have not been received, a protocol error is
>> triggered and the PCE must cancel the whole set
>> of path computation requests.
>> Zero means that the PCEP entity does not use the
>> SyncTimer."
>>
>
> Dhruv: Thanks. Updated.
>
>
>
>> - On page 69, about path key, the name of the leaf "pcc-original" feels
>> odd, how about "originator-pcc" instead?
>>
>>
> Dhruv: I changed it to pcc-requester and used "original" in the
> description to march the text in RFC 5520.
>
>   leaf pcc-requester {
> type leafref {
>   path "/pcep/entity/peers/peer/addr";
> }
> description
>   "Reference to PCC peer address that
>   issued the original request that led
>   to the creation of the path-key.";
>   }
>
>
>> Nits:
>> - Page 11: s/system generated entity index/system-generated entity index
>> - P.11: s/the local entity is PCE it/the local entity is a PCE, it
>> - P.11: s/dead-timer in YANG is called DeadTimer in the protocol
>> specification/DeadTimer in the protocol specification is called
>> dead-timer in YANG/
>> - P.16: s/learn PCE in the network via IGP discovery/learn a PCE address
>> in the network via the IGP discovery/
>> - P.28-30: There are several bullets points in the descriptions fields
>> that would benefit from semicolons at each line end.
>>
> Dhruv: I used a comma instead for readability
>
>> - P.40: s/maybe relevant/may be relevant/
>> - P.44: s/PCE triggered/PCE-triggered/  [twice]
>> - P.49: s/instance specific data/instance-specific data/
>> - P.105: s/this document also include/this document also includes/
>>
>>
> Dhruv: Ack!
>
> Thanks for your review! New version -24 is posted.
>
> Diff:
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pcep-yang-23&url2=draft-ietf-pce-pcep-yang-24&difftype=--html
>
> Regards,
> Dhruv
>
>
>
>>
>> Best regards,
>>
>> Julien
>>
>> ___
>> 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] WG Adoption of draft-li-pce-controlled-id-space-16

[Dhruv Dhody]

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: Shepherd Review of draft-ietf-pce-pcep-yang

[Dhruv Dhody]

HI Julien,

On Thu, May 16, 2024 at 7:57 PM  wrote:

> Dear authors of draft-ietf-pce-pcep-yang,
>
> I've reviewed the aforementioned document to prepare its publication
> request. The I-D is almost ready to move forward and only has minor
> issues and nits that should be addressed before sending it to the IESG.
>
> Minor issues:
> - The introduction doesn't mention the ietf-pcep-stats module though
> it's defined in the body of the I-D; a brief additional sentence would
> be welcome.
>

Dhruv: Added "Further, this document also includes the PCEP statistics
YANG module
"ietf-pcep-stats" which provides statistics, counters and telemetry data."


> - For SR, the leaf "msd-limit" (page 45) is a boolean that should be
> renamed to be understandable, e.g. into "no-msd-limit" or "ignore-msd".
>

Dhruv: changed to "no-msd-limit".



> - On page 46, in the H-PCE section, there's a "if Stateful GMPLS is
> enabled" left instead of "if H-PCE is enabled.
>

Dhruv: thanks for spotting that



> - Section 7.1 about TLS should be deeply summarized and rather point to
> the referenced document (pointer to be updated).
>

Dhruv: Changed to -- "The PCC acting as the TLS client opens the TLS
connection and the PCE acting as the TLS server listens for incoming
connections as per TLS specifications ([RFC8446] and [RFC5246]). [RFC8253]
specifies the StartTLS procedure in PCEP that initiates the TLS connection
before exchanging PCEP messages thus the identity verification is completed
before the PCEP session is established."


> - On page 51, in the description of the hexadecimal case, I don't think
> the 2 long sentences about the rationale should be included there; if
> the authors consider it necessary, it may be included in the text body
> of the draft.
>

Dhruv: The text/approach is borrowed from RFC 8177. I prefer to keep it.



> - On page 59, similar comment about the sync-timer description, which
> I'd shorten into the following:
>"The value of SyncTimer in seconds is used in the
> case of synchronized path computation request
> using the SVEC object. If after the expiration of
> the SyncTimer all the path computation requests
> have not been received, a protocol error is
> triggered and the PCE must cancel the whole set
> of path computation requests.
> Zero means that the PCEP entity does not use the
> SyncTimer."
>

Dhruv: Thanks. Updated.



> - On page 69, about path key, the name of the leaf "pcc-original" feels
> odd, how about "originator-pcc" instead?
>
>
Dhruv: I changed it to pcc-requester and used "original" in the description
to march the text in RFC 5520.

  leaf pcc-requester {
type leafref {
  path "/pcep/entity/peers/peer/addr";
}
description
  "Reference to PCC peer address that
  issued the original request that led
  to the creation of the path-key.";
  }


> Nits:
> - Page 11: s/system generated entity index/system-generated entity index
> - P.11: s/the local entity is PCE it/the local entity is a PCE, it
> - P.11: s/dead-timer in YANG is called DeadTimer in the protocol
> specification/DeadTimer in the protocol specification is called
> dead-timer in YANG/
> - P.16: s/learn PCE in the network via IGP discovery/learn a PCE address
> in the network via the IGP discovery/
> - P.28-30: There are several bullets points in the descriptions fields
> that would benefit from semicolons at each line end.
>
Dhruv: I used a comma instead for readability

> - P.40: s/maybe relevant/may be relevant/
> - P.44: s/PCE triggered/PCE-triggered/  [twice]
> - P.49: s/instance specific data/instance-specific data/
> - P.105: s/this document also include/this document also includes/
>
>
Dhruv: Ack!

Thanks for your review! New version -24 is posted.

Diff:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pcep-yang-23&url2=draft-ietf-pce-pcep-yang-24&difftype=--html

Regards,
Dhruv



>
> Best regards,
>
> Julien
>
> ___
> 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: Changes for PCEP-LS IANA Considerations

[Dhruv Dhody]

Hi Adrian,

Thanks for providing suggested changes but I would like to keep the IANA
considerations as it is and allocate from the 'IETF Review' codespace which
allows any type of RFC including experimental. I found some recent
experimental RFCs - 9531 and 9268 that follow the same approach.

Thanks!
Dhruv

On Mon, May 6, 2024 at 3:04 AM Adrian Farrel  wrote:

> Hi,
>
> Thanks for posting the adopted draft.
>
> I think we need to make the following changes so catch all of the IANA
> issues associated with being Experimental.
>
> Cheers,
> Adrian
>
> ===
>
> New section...
>
> 6.2.  Experimental Error-Types and Error-Values
>
>This experiment uses a single Experimental Use error-type
>[I-D.farrel-pce-experimental-errors] to indicate 'PCEP-LS Error' to
>cover all experimental error cases. The value used needs to be
>consistent between all partners in the experiment, and
>implementations would ideally make it configurable.
>
>The following error-values apply to this experimental error-type.
>
>Error-Value | Meaning
>+
>  1 | LS Synchronisation Error: Error in processing the LSRpt
>  2 | LS Synchronisation Error: Internal PCC error
>  3 | Mandatory object missing: LS object missing
>  4 | Invalid Operation: Attempted LS Report if LS remote
>| capability was not advertised
>
> ---
>
> New section...
>
> 6.3.   Experimental PCEP TLV Types
>
>This document uses a number of experimental PCEP TLVs. Values are
>chosen from the Experimental Use range. The values used need to be
>consistent between all partners in the experiment, and
>implementations would ideally make them configurable.
>
>For clarity in the document, the TLVs are indicated using the tags
>EXPx for different values of x, as follows.
>
>Value  | Meaning
>---+
> EXP5  | LS-CAPABILITY TLV
> EXP7  | ROUTING-UNIVERSE TLV
> EXP8  | Local Node Descriptors TLV
> EXP9  | Remote Node Descriptors TLV
> EXP10 | Link Descriptors TLV
> EXP11 | Prefix Descriptors TLV
> EXP12 | Node Attributes TLV
> EXP13 | Link Attributes TLV
> EXP14 | Prefix Attributes TLV
> EXP15 | ROUTE-DISTINGUISHER TLV
>
> ---
>
> Throughout the document, make the following changes
>
> TBD5  --> EXP5
> TBD7  --> EXP7
> TBD8  --> EXP8
> TBD9  --> EXP9
> TBD10 --> EXP10
> TBD11 --> EXP11
> TBD12 --> EXP12
> TBD13 --> EXP13
> TBD14 --> EXP14
> TBD15 --> EXP15
>
> ---
>
> 6.2
>
> OLD
>The LS reports sent by PCC MAY carry the remote link-state (and TE)
>information learned via existing means like IGP and BGP-LS only if
>both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV
>to 'Remote Allowed (R Flag = 1)'.  If this is not the case and LS
>reports carry remote link-state (and TE) information, then a PCErr
>with error-type 19 (Invalid Operation) and error-value TBD1
>(Attempted LS Report if LS remote capability was not advertised) and
>it will terminate the PCEP session.
> NEW
>The LS reports sent by PCC MAY carry the remote link-state (and TE)
>information learned via existing means like IGP and BGP-LS only if
>both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV
>to 'Remote Allowed (R Flag = 1)'.  If this is not the case and LS
>reports carry remote link-state (and TE) information, then a PCErr
>with the experimental error-type (PCEP-LS Error) and error-value
>(Attempted LS Report if LS remote capability was not advertised) and
>it will terminate the PCEP session.
> END
>
> ---
>
> 6.3
>
> OLD
>If the PCC encounters a problem which prevents it from completing the
>LS synchronization, it MUST send a PCErr message with error-type TBD2
>(LS Synchronization Error) and error-value 2 (indicating an internal
>PCC error) to the PCE and terminate the session.
> NEW
>If the PCC encounters a problem which prevents it from completing the
>LS synchronization, it MUST send a PCErr message with the
>experimental error-type (PCEP-LS Error) and error-value 2 (LS
>Synchronization Error: Internal PCC error) to the PCE and terminate
>the session.
> END
>
> ---
>
> 6.3
>
> OLD
>The PCE does not send positive acknowledgments for properly received
>LS synchronization messages.  It MUST respond with a PCErr message
>with error-type TBD2 (LS Synchronization Error) and error-value 1
>(indicating an error in processing the LSRpt) if it encounters a
>problem with the LS Report it received from the PCC and it MUST
>terminate the session.
> NEW
>The PCE does not send positive acknowledgments for properly received
>LS synchronization messages.  It MUST respond with a PCErr message
>with with the experimental error-type (PCEP-LS Error) and error-value
>1 (LS Synchronization Error: Error in pr

[Pce] Fwd: IPR poll for draft-dhodylee-pce-pcep-ls

[Dhruv Dhody]

Forwarding since this never made it to the mailing list archive

-- Forwarded message -
From: satish karunanithi 
Date: Thu, Apr 11, 2024 at 11:42 AM
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,
Satish

On Fri, Apr 5, 2024 at 8:44 PM Andrew Stone (Nokia) 
wrote:

> 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

[Pce] Publication has been requested for draft-ietf-pce-stateful-pce-optional-09

[Dhruv Dhody via Datatracker]

Dhruv Dhody has requested publication of 
draft-ietf-pce-stateful-pce-optional-09 as None on behalf of the PCE working 
group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-optional/


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

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

[Dhruv Dhody]

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] Review of draft-ietf-pce-segment-routing-policy-cp-15 from SR Policy Arch POV

[Dhruv Dhody]

Hi Ketan,

Jumping directly to...

>
>> 15  draft-ietf-pce-segment-routing-policy-cp-15
>>>
>>> 17 Abstract
>>>
>>> 19   Segment Routing (SR) allows a node to steer a packet flow along any
>>> 20   path.  SR Policy is an ordered list of segments (i.e., instructions)
>>> 21   that represent a source-routed policy.  Packet flows are steered
>>> into
>>> 22   an SR Policy on a node where it is instantiated called a headend
>>> 23   node.  An SR Policy is made of one or more candidate paths.
>>>
>>> 25   This document specifies Path Computation Element Communication
>>> 26   Protocol (PCEP) extension to associate candidate paths of the SR
>>> 27   Policy.  Additionally, this document updates [RFC8231] to allow
>>> 28   stateful bringup of an SR LSP, without using PCReq/PCRep messages.
>>> 29   This document is applicable to both Segment Routing over MPLS and to
>>> 30   Segment Routing over IPv6 (SRv6).
>>>
>>>
>>>
>>> *[major] This document has the specifications that actually align the
>>> PCEPextensions (e.g. RFC8664) for SR defined prior to this document to the *
>>> *SR Policy architecture RFC9256. This should be the most important thing
>>> to call out and that this spec formally updates RFC8664 and *
>>> *RFC-draft-ietf-pce-segment-routing-ipv6.*
>>>
>>>
>> Dhruv: Happy for the authors to make it clearer but I don't think there
>> is a need for a formal update. "Update" makes sense when there is some text
>> in those RFCs that require changes. It is just a normal extension. From
>> PCEP POV, SR-MPLS and SRv6 extensions for those path setup types exist on
>> their own. If SR Policy is in use, then of course this document should be
>> used.
>>
>
> KT> What is being signaled via RFC8664 is something that is not defined in
> SR Architecture but those specs are still called SR extensions. Putting a
> formal "update" points readers that this document is what extends those
> previous documents for SR Policy (and thereby SR) extensions.
>
>

Dhruv: It is a classic discussion of what does "update" mean :)
See https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag
Till things change, in PCE WG, we apply "update" only when there is a
change in text in a previously published RFC. I personally would like to
keep it that way. Authors can add text in abstract/introduction to make
your point explicit.

Thanks!
Dhruv

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

Re: [Pce] Review of draft-ietf-pce-segment-routing-policy-cp-15 from SR Policy Arch POV

[Dhruv Dhody]

Hi Ketan, Authors,

I am just responding to a few comments as a Shepherd. Please work with each
other and let's resolve these comments

On Mon, Apr 8, 2024 at 5:15 PM Ketan Talaulikar 
wrote:

> Hello Authors/All,
>
> I've reviewed the draft from the perspective of consistency with the SR
> Policy Arch RFC9256 as well as the BGP SR Policy SAFI IDR draft. As such, I
> find some issues that I think need to be addressed before publication.
>
> Note that these may seem editorial (no change needed in PCEP signaling),
> but they are semantically important for this document to convey the intent
> and operations for these extensions.
>
> My comments are embedded in the idnits format below.
>
> Thanks,
> Ketan
>
>
> 13 Path Computation Element Communication Protocol (PCEP) Extensions for
> 14  Segment Routing (SR) Policy Candidate Paths
>
> *[major] A more appropriate title would be "PCEP Extensions for SR
> Policy" *
> *since this is not just about CPs but support for SR Policy construct.*
>
>
Dhruv: In PCEP the key construct that we signal is a CP and thus I consider
the title to be apt.



> 15  draft-ietf-pce-segment-routing-policy-cp-15
>
> 17 Abstract
>
> 19   Segment Routing (SR) allows a node to steer a packet flow along any
> 20   path.  SR Policy is an ordered list of segments (i.e., instructions)
> 21   that represent a source-routed policy.  Packet flows are steered into
> 22   an SR Policy on a node where it is instantiated called a headend
> 23   node.  An SR Policy is made of one or more candidate paths.
>
> 25   This document specifies Path Computation Element Communication
> 26   Protocol (PCEP) extension to associate candidate paths of the SR
> 27   Policy.  Additionally, this document updates [RFC8231] to allow
> 28   stateful bringup of an SR LSP, without using PCReq/PCRep messages.
> 29   This document is applicable to both Segment Routing over MPLS and to
> 30   Segment Routing over IPv6 (SRv6).
>
>
>
> *[major] This document has the specifications that actually align the
> PCEPextensions (e.g. RFC8664) for SR defined prior to this document to the *
> *SR Policy architecture RFC9256. This should be the most important thing
> to call out and that this spec formally updates RFC8664 and *
> *RFC-draft-ietf-pce-segment-routing-ipv6.*
>
>
Dhruv: Happy for the authors to make it clearer but I don't think there is
a need for a formal update. "Update" makes sense when there is some text in
those RFCs that require changes. It is just a normal extension. From PCEP
POV, SR-MPLS and SRv6 extensions for those path setup types exist on their
own. If SR Policy is in use, then of course this document should be used.





>
> 126   Segment Routing Policy for Traffic Engineering [RFC9256] details the
> 127   concepts of SR Policy and approaches to steering traffic into an SR
> 128   Policy.
>
> 130   PCEP Extensions for Segment Routing [RFC8664] specifies extensions to
> 131   the Path Computation Element Protocol (PCEP) that allow a stateful
> 132   PCE to compute and initiate Traffic Engineering (TE) paths, as well
> 133   as a PCC to request a path subject to certain constraint(s) and
> 134   optimization criteria in SR networks.
>
> 136   PCEP Extensions for Establishing Relationships Between Sets of LSPs
> 137   [RFC8697] introduces a generic mechanism to create a grouping of LSPs
> 138   which can then be used to define associations between a set of LSPs
> 139   and a set of attributes (such as configuration parameters or
> 140   behaviors) and is equally applicable to stateful PCE (active and
> 141   passive modes) and stateless PCE.
>
>
>
> *[major] It may be somewhat misleading to give an impression that
> thepurpose for introducing the SRPA is "to create a grouping of LSPs". *
>
>
> *For sure, the SRPA enables the  grouping of CPs associated with a single
> SR Policy. However, SRPA is  absolutely necessary even when signaling a
> single SR Policy CP as it is  indicating the Color of the SR Policy and
> the identifiers of the SR Policy CP  **as per RFC9256.*
>
>
Dhruv: In PCEP, association can exist with a single LSP in the association
group. If authors feel they need to be explicit about it, it is fine with
me.





> 156   Endpoint:  The IPv4 or IPv6 endpoint address of the SR Policy in
> 157  question, as described in [RFC9256].
>
> 159   SRPA:  SR Policy Association.  A new association type 'SR Policy
> 160  Association' is used to group candidate paths belonging to the SR
> 161  Policy.  Depending on discussion context, it can refer to the PCEP
> 162  ASSOCIATION object of SR Policy type or to a group of LSPs that
> 163  belong to the association.
>
> 165   Association Parameters:  As described in [RFC8697], refers to the key
> 166  data, that uniquely identifies the Association.
>
> 168   Association Information:  As described in [RFC8697], refers to the
> 169  non-key information about the Association.
>
> 171 3.  Overview
>
>
>
>
>
>
>
>
>

Re: [Pce] IPR poll for draft-dhodylee-pce-pcep-ls

[Dhruv Dhody]

Hi Andrew,

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

Thanks!
Dhruv

On Fri, Apr 5, 2024 at 8:44 PM Andrew Stone (Nokia) 
wrote:

> 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] Shepherd Review of draft-ietf-pce-segment-routing-policy-cp-14

[Dhruv Dhody]

Hi Mike, Authors,

Please make a new version of the I-D where you handle the following items.
We can then send the I-D to the IESG.

(1) Please handle Ketan's concern and add the IANA note as he suggested -
https://mailarchive.ietf.org/arch/msg/pce/ZaYof63GNYdplFUOLo6G6hJlx3c/

(2) A few comments/query got missed, please update or respond if no changes
are needed...

- Section 5.2, I am unsure about the interaction between the unsetting of
P-flag (PCEP speaker does not support the TLV) and the default value (128
when the TLV is not present). Isn't it a bit weird?
- Section 5.4, Should Oper/Config get a registry for ease of adding new
flags in future?

(3) Some new comments on checking the diff

- abstract, s/[RFC8231]/RFC 8231/ (no references in abstract)
- s/ANY/any/
- RFC 7525 is obsolete by RFC 9325, please update!

(4) I am working on the shepherd writeup -
https://notes.ietf.org/HziLkaoxS6iYoQ3sOcwk-A?view ; will update in the
datatracker once you post a new version handling these.

Thanks!
Dhruv

On Mon, Mar 18, 2024 at 7:40 AM Mike Koldychev  wrote:

> Hi Dhruv,
>
> I've incorporated your changes and all the other comments that I have
> received so far. Hopefully I didn't miss anything. Version 15 is uploaded.
> Thanks a lot for your comments and updates!
>
> Thanks,
> Mike.
>
> On Saturday, March 9th, 2024 at 8:23 AM, Dhruv Dhody 
> wrote:
>
> Hi Authors,
>
> I have finished the shepherd review of
> draft-ietf-pce-segment-routing-policy-cp-14. Please handle these comments
> before we ship this I-D to IESG.
>
> ## Major
> - Section 5.6, you need to add update: RFC 8231 in the draft metadata.
> This should also be captured in the abstract. The prefered way is to
> clearly identify the text in RFC8231 that is changing with "OLD:" and
> "NEW:" format!
> - Section 8, Security considerations need to also cover the non-SRPA TLVs
> which are not considered in the current text.
>
> ## Query
> - Section 4.1,
> 
> If the PCC receives a
> PCInit message with the Association Source set not to the headend IP
> but to some globally unique IP address that the headend owns, then
> the PCC SHOULD accept the PCInit message and create the SRPA with the
> Association Source that was sent in the PCInit message.
> 
> What is the purpose of this text? PCC should use the source as set by the
> PCE - isn't it given? Am I missing something? Boris also pointed this out
> in his review.
>
>
> ## Minor
> - Abstract is not very useful for a non-expert. Maybe change something
> like -
> 
> OLD:
> A Segment Routing (SR) Policy is a non-empty set of SR Candidate
> Paths, which share the same  tuple. SR
> Policy is modeled in PCEP as an Association of one or more SR
> Candidate Paths. PCEP extensions are defined to signal additional
> attributes of an SR Policy. The mechanism is applicable to all SR
> forwarding planes (MPLS, SRv6, etc.).
> NEW:
> Segment Routing (SR) allows a node to steer a packet flow along any
> path. SR Policy is an ordered list of segments (i.e.,
> instructions) that represent a source-routed policy. Packet flows
> are steered into an SR Policy on a node where it is instantiated
> called a headend node. An SR Policy is made of one or more candidate
> paths.
>
> This document specifies Path Computation Element Communication
> Protocol (PCEP) extension to associate candidate paths of the SR
> Policy. It applies equally to the SR-MPLS and Segment Routing over
> IPv6 (SRv6) instantiations of segment routing.
> END
> 
> - Similarly I find Introduction to be very light on details. Consider
> adding text by looking through recently published RFCs for instance.
> - Terminology:
> ```
> OLD:
> SRPA: SR Policy Association. PCEP ASSOCATION that describes the SR
> Policy. Depending on discussion context, it refers to a PCEP
> object or to a group of LSPs that belong to the Association.
> NEW:
> SRPA: SR Policy Association. A new association type 'SR Policy
> Association' is used to group candidate paths belonging to the SR
> Policy. Depending on discussion context, it can refer to the PCEP
> ASSOCIATION object of SR Policy type or to a group of LSPs that
> belong to the association.
> END
> ```
> - Section 4, please add this text at the start -
> 
> As per [RFC8697], LSPs are associated with other LSPs with which they
> interact by adding them to a common association group. As described
> in [RFC8697], the association group is uniquely identified by the
> combination of the following fields in the ASSOCIATION object:
> Association Type, Association ID, Association Source, and (if
> present) Global Association Source or Extended Association ID,
> referred to as Association Parame

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

[Dhruv Dhody]

Hi Éric,

On Thu, Apr 4, 2024 at 12:53 AM Éric Vyncke via Datatracker <
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"
>
> ## 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.
>
> ## 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.



> ## 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."


> ## 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?



> ## Section 4.1.1
>
> Is there a reason why the only defined bit in the flag field it not the
> rightmost one ?
>
>
Dhruv: There used to be another flag "X" that we removed later on.
Implementers preferred not to move the N flag from its current position.



> Please mention the position of the N bit (bit 30 from picture but let's be
> crystal clear).
>
> Is it common for PCEP communication to use the term TLV where the Length
> is not
> actually the field length ? How can a non SRv6 capable PCEP speakers will
> parse/skip this TLV without prior knowledge of the 4-octet alignment ?
>
>
Dhruv: The (MSD-Type,MSD-Value) are not called TLV, they are a part of the
value portion of SRv6-PCE-CAPABILITY sub-TLV. The SRv6-PCE-CAPABILITY has
type (27) and a length field and follows the TLV format. The length field
will indicate how many pairs of (MSD-Type,MSD-Value) are included. Am I
misunderstanding your comment?



> ## Section 4.3.1
>
> No need to reply, but the encoding of TLV object is really weird again as
> it
> starts with an important flag and the length is now only 1 octet.
>
>
Dhruv: This is not a TLV but a subobject. They follows the standard
subobject encoding that PCEP inherited from RSVP-TE -
https://datatracker.iet

Re: [Pce] Mahesh Jethanandani's No Objection on draft-ietf-pce-segment-routing-ipv6-23: (with COMMENT)

[Dhruv Dhody]

Hi Mahesh,

On Wed, Apr 3, 2024 at 4:50 AM Mahesh Jethanandani via Datatracker <
nore...@ietf.org> wrote:

> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-pce-segment-routing-ipv6-23: 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:
> --
>
> Thanks for working on this document. I am not an expert in PCEP and its
> related
> drafts, but as I understand it, this document is defining an extension for
> SRv6
> and not SR-MPLS. Therefore, I am confused by this long paragraph in the
> Introduction section that delves into how SR-MPLS works. To quote:
>
>[RFC8231] specifies extensions to PCEP that allow a stateful PCE to
>compute and recommend network paths in compliance with [RFC4657] and
>defines objects and TLVs for MPLS-TE LSPs.  Stateful PCEP extensions
>provide synchronization of LSP state between a PCC and a PCE or
>between a pair of PCEs, delegation of LSP control, reporting of LSP
>state from a PCC to a PCE, controlling the setup and path routing of
>an LSP from a PCE to a PCC.  Stateful PCEP extensions are intended
>for an operational model in which LSPs are configured on the PCC, and
>control over them is delegated to the PCE.
>
> If there is something this paragraph conveys applies to SRv6, it is not
> apparent in the next paragraph. In anything, the next paragraph on how this
> would work in SRv6 was clear in itself, without needing this paragraph.
>
>
>
Dhruv: The base PCEP specifications were specific to MPLS-TE and over time
they have been extended for SR-MPLS, GMPLS etc.  This and the previous
paragraph is setting the scene to highlight the existing specifications
(RFC 5440 and RFC 8231) that are extended to also support SRv6.

This might be a matter of style - the PCE WG documents do prefer longer
Introductions that references base specifications that are being extended.

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] Gunter Van de Velde's No Objection on draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT)

[Dhruv Dhody]

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



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



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



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




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



>
> 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 the whole para can be read as -

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



> 126When the SR architecture is applied to the MPLS forwarding
> plane, it
> 127is called SR-MPLS.  When the SR architecture is applied to the
> IPv6
> 128data plane, is 

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

[Dhruv Dhody]

Hi Jim,

On Mon, Apr 1, 2024 at 6:06 PM Jim Guichard via Datatracker <
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

[Pce] PCE WG Status @ IETF 119

[Dhruv Dhody]

Hi,

Please find the WG status as presented today -
https://datatracker.ietf.org/meeting/119/materials/slides-119-pce-1-introduction-00.pdf


   - 1 new RFCs since IETF 118
  - RFC 9504 - draft-ietf-pce-pcep-stateful-pce-gmpls
   - I-Ds in the RFC Editor Queue
  - draft-ietf-pce-binding-label-sid-15 (MISSREF)
 - Waiting for draft-ietf-pce-segment-routing-ipv6 (with the IESG)

  - draft-ietf-pce-pceps-tls13 (MISSREF)
 - Waiting for draft-ietf-tls-rfc8446bis (post WGLC)

  - With IESG
  - draft-ietf-pce-segment-routing-ipv6-20
 - IESG Evaluation, Telechat 2024-04-04
  - draft-ietf-pce-pcep-extension-native-ip-30
 - Publication Requested on 2023-12-29
  - Early IANA Allocation
   - draft-ietf-pce-segment-routing-ipv6
 - Renewed!
 - Expires 2025-01-12
  - draft-ietf-pce-segment-routing-policy-cp
 - (1) Renewed and Expires 2025-03-30
 - (2) Expires 2025-02-13
  - draft-ietf-pce-multipath
 - Renewed!
 - Expires 2024-05-09
  - draft-ietf-pce-pcep-extension-native-ip
 - Expires 2024-08-14
  - draft-ietf-pce-sid-algo
 - Expires 2024-09-13
  - draft-ietf-pce-pcep-color
 - Expires 2024-10-30
  - draft-ietf-pce-sr-bidir-path
 - Expires 2024-11-30
  - draft-ietf-pce-circuit-style-pcep-extensions
 - Expires 2025-02-23
  - Recharter
   - Completed on 2023-12-19
   - Errata
  - No new Errata
   - Liaison
  - From ITU-T-SG-15
 - https://datatracker.ietf.org/liaison/1891/
 - To ccamp, mpls, pals, pce, teas
 - Issue 33 of the OTNT SWP, the latest version updated by the SG15
 during a plenary meeting in November 2023.
 - Requesting updates to the relevant materials
 - Deadline is 2024-06-25
 - Action Holder: Deborah (?)
  - Post WG-LC
   - draft-ietf-pce-pcep-yang
 - -22 posted on 2023-09-11
 - -23 posted on 2024-03-18
 - Waiting for shepherd review (Julien)
  - draft-ietf-pce-segment-routing-policy-cp
 - -14 posted on 2024-02-09
 - -15 posted on 2024-03-17
 - Authors responded to shepherd review (Dhruv)
  - WG documents “nearing” WG LC
   - draft-ietf-pce-stateful-pce- optional
 - WGLC Ended 2024-03-14
 - On the agenda
  - draft-ietf-pce-flexible-grid
 - -09 posted on 2023-03-07
 - Expired!
 - Is there still interest?
  - draft-ietf-pce-state-sync
 - -06 posted on 2023-07-08
 - -07 posted on 2024-03-17
 - On the agenda
  - draft-ietf-pce-pcep-color
 - -02 posted on 2023-09-01
 - Expired!
 - Needs implementation section
  - draft-ietf-pce-pcep- extension-pce-controller-sr
 - -08 posted on 2024-01-01
 - Ready for WGLC?
  - draft-ietf-pce-stateful-pce-vendor
 - -02 posted on 2024-02-05
 - Ready for WGLC?
  - draft-ietf-pce-sid-algo
 - -08 posted on 2024-02-01
 - Ready for WGLC
  - WG I-Ds
  - draft-ietf-pce-multipath
 - -10 posted on 2024-01-16
 - Comments from 117 are not handled yet!
 - Going beyond SR Policy architecture
 - Note that the IANA early allocation expiry is coming up!!
  - draft-ietf-pce-sr-path- segment
 - -09 posted on 2024-02-26
 - A refresh!
 - Nearing WGLC?
  - draft-ietf-pce-sr-bidir-path
 - -13 posted on 2024–02-13
 - A refresh!
 - Nearing WGLC?
  - draft-ietf-pce-stateful- interdomain
  - -04 posted on 2023-10-23
 - Update is in pipeline
  - draft-ietf-pce-sr-p2mp-policy
 - -05 posted on 2024-03-03
 - On the agenda
  - draft-ietf-pce-pcep-l2- flowspec
 - -05 posted on 2023-12-25
 - this I-D relies on the processing rules as per RFC 9168
  - draft-ietf-pce-pcep-pmtu
  - -05 posted on 2024-01-28
 - A refresh!
  - draft-ietf-pce-pcep-ifit
 - -04 posted on 2024-01-08
 - A refresh!
  - draft-ietf-pce-pcep-srv6-yang
  - -04 posted on 2023-09-11
 - Discussion with SPRING YANG authors
  - draft-ietf-pce-pcep-extension-pce-controller-srv6
 - -02 posted on 2024-02-04
 - A refresh!
  - draft-ietf-pce-bier-te-00
 - -00 posted on 2023-11-04
  - Recently adopted documents
   - draft-ietf-pce-circuit-style-pcep-extensions
 - -04 posted on 2024-02-26
 - On the agenda
  - draft-ietf-pce-entropy-label-position
 - -01 posted on 2024-02-25
  - WG Adoption Poll Queue
   - Refer to https://wiki.ietf.org/en/group/pce#wg-adoption-call-queue
  - draft-dhodylee-pce-pcep-ls
  - draft-peng-pce-stateful-pce-autobw-update
  - draft-li-pce-controlled-id-space
  - draft-dhody-pce-pcep-extension-pce-controller-p2mp
  - draft-koldychev-pce-operational (need to break into 2 drafts)
  - draft-ch

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

[Dhruv Dhody]

Hi WG,

This is just a refresh!
We are waiting for the shepherd review to take this draft forward

Thanks!
Dhruv



On Mon, Mar 18, 2024 at 5:35 PM  wrote:

> Internet-Draft draft-ietf-pce-pcep-yang-23.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 Path Computation Element Communications
> Protocol (PCEP)
>    Authors: Dhruv Dhody
> Vishnu Pavan Beeram
> Jonathan Hardwick
> Jeff Tantsura
>Name:draft-ietf-pce-pcep-yang-23.txt
>Pages:   132
>Dates:   2024-03-18
>
> Abstract:
>
>This document defines 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.  The data model includes
>configuration and state data.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-23
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-yang-23
>
> 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] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Dhruv Dhody]

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

[Dhruv Dhody]

Hi Samuel,

On Wed, Mar 13, 2024 at 6:44 PM Samuel Sidor (ssidor) 
wrote:

> Hi Cheng,
>
>
>
> Thanks a lot for your responses. Ack for all of them, new proposed version
> looks fine to me.
>
>
>
> For “3.1 STATEFUL-PCE-CAPABILITY TLV section” I was really talking about
> objects defined in RFC5440, but used in stateful messages. Isn’t that
> behavior really “undefined” (before this draft)? Because RFC8231 is really
> talking only about new objects defined in that RFC (SRP, LSP,…) and not
> about older objects re-used in new PCEP messages.
>
>
>

Dhruv: You are correct -
https://datatracker.ietf.org/doc/html/rfc8231#section-7

How about we extend the text like this -

   The R flag MUST be set by both a PCC and a PCE to indicate support
   for the handling of the P and I flag in the PCEP common object header
   to allow relaxing some constraints by marking objects as optional to
   process.  If the PCEP speaker did not set the R flag but receives
   PCEP objects with P or I bit set, it MUST behave as per the
   processing rule in [RFC8231].  Note that while [RFC8231] stated that
   P and I flags of the PCEP objects defined in [RFC8231] are set to 0
   on and ignored on receipt, it did not say anything about already
   existing PCEP objects and thus the behaviour remained undefined.  To
   safely use this future, both peers need to set the R flag.

Thanks!
Dhruv



> Thanks,
>
> Samuel
>
>
>
> *From:* Cheng Li 
> *Sent:* Wednesday, March 13, 2024 4:46 AM
> *To:* Samuel Sidor (ssidor) ;
> draft-ietf-pce-stateful-pce-optio...@ietf.org
> *Cc:* pce-chairs ; pce@ietf.org; Dhruv Dhody <
> d...@dhruvdhody.com>
> *Subject:* RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07
>
>
>
> 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 <
> d...@dhruvdhody.com>
> *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
> ig

[Pce] Shepherd Review of draft-ietf-pce-segment-routing-policy-cp-14

[Dhruv Dhody]

n the "Mandatory Object Missing" Error-Type and two new Error-Values within the "Association Error" Error-Type.
IANA is requested to allocate new error values within the "PCEP-ERROR Object Error Types and Values" subregistry of the PCEP Numbers registry, as follows:



  





IANA is requested to allocate new bit within the "TE-PATH-BINDING TLV Flag field" subregistry of the PCEP Numbers registry, as follows:



  





This document requests IANA to maintain a new registry under
"Segment Routing" registry group.
New values are to be assigned by "Standards Action" [RFC8126].
The new subregistry is requested to be created under it be called "SR Policy Protocol Origin".
The subregistry contains the following codepoints, with initial values, to
be assigned by IANA with the reference set to this document:



  





  [Note to the RFC Editor - remove this section before publication, as
  well as remove the reference to RFC 7942.]

  This section records the status of known implementations of the
  protocol defined by this specification at the time of posting of this
  Internet-Draft, and is based on a proposal described in . The description of implementations in this section
  is intended to assist the IETF in its decision processes in progressing
  drafts to RFCs. Please note that the listing of any individual
  implementation here does not imply endorsement by the IETF. Furthermore,
  no effort has been spent to verify the information presented here that
  was supplied by IETF contributors. This is not intended as, and must not
  be construed to be, a catalog of available implementations or their
  features. Readers are advised to note that other implementations may
  exist.


  According to , "this will allow reviewers and
  working groups to assign due consideration to documents that have the
  benefit of running code, which may serve as evidence of valuable
  experimentation and feedback that have made the implemented protocols
  more mature. It is up to the individual working groups to use this
  information as they see fit".

  

Organization: Cisco Systems

Implementation: IOS-XR PCC and PCE.

Description: All features supported except Computation Priority, Explicit NULL and Invalidation Drop.

Maturity Level: Production.

Coverage: Full.

Contact: mkold...@cisco.com
  
  

  

Organization: Juniper Networks

Implementation: PCC and PCE.

Description: Everything in -05 except SR Policy Name TLV and SR Policy Candidate Path Name TLV.

Maturity Level: Production.

Coverage: Partial.

Contact: cba...@juniper.net
  
  




  This document defines one new type for ASSOCIATION object, which does not add any new
  security concerns beyond those discussed in ,
  ,  and  in itself.
  
 
The information carried in the SRPA object, as per this document is related to SR Policy.
It often reflects information
that can also be derived from the SR Database, but association provides a much easier grouping of related LSPs and messages.
The SRPA could provide an adversary with the opportunity to eavesdrop on the relationship between the LSPs.
Thus securing the PCEP session using Transport Layer
   Security (TLS) , as per the recommendations and
   best current practices in , is RECOMMENDED.




Would like to thank Stephane Litkowski, Boris Khasanov, Abdul Rehman, Alex Tokar, Praveen Kumar and Tom Petch for review and suggestions.

 






  http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.8231.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.8281.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.9256.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.8697.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.8664.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.7525.xml";?>
  http://xml.resource.org/public/rfc/bibxml/reference.RFC.8253.xml";?>
  http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-binding-label-sid.xml";?>



  http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-multipath.xml";?>
  




Dhruv Dhody
Huawei
India

Email: dhruv.i...@gmail.com

Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing, 10095
China

Email: chengl...@huawei.com

Samuel Sidor
Cisco Systems, Inc.
Eurovea Central 3.
Pribinova 10
811 09 Bratislava
Slovakia

Email: ssi...@cisco.com



 





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

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

[Dhruv Dhody]

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

[Pce] PCE WG Agenda for IETF 119

[Dhruv Dhody]

Hi WG,

The **draft** agenda for the PCE WG sessions during IETF 119 is posted -
https://datatracker.ietf.org/doc/agenda-119-pce/

Please unicast us if there is any change needed.

Please note that the allocated time includes time for Q&A. Please use the
mailing list to bring out the key point that you would like to discuss
during the WG session. Please send your slides (in pdf format) to emails in
the CC in advance by Saturday March 16th.

Useful information for both in-person and online participation can be found
at - https://www.ietf.org/how/meetings/preparation/. Refresh your knowledge
of Meetecho  -
https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/

Thanks!
Dhruv, Julien & Andrew

ICS: https://datatracker.ietf.org/meeting/119/session/31937.ics
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Dhruv Dhody]

Gentle reminder... The last date is Monday 4th March!

On Sat, Feb 17, 2024 at 11:43 PM Dhruv Dhody  wrote:

> Hi,
>
> The PCE WG would be meeting during the IETF 119 [1] week. If you need
> agenda time to progress some work, please send a slot request directly to
> the chairs/secretary  by Monday, March 4th 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 also
> Monday, Mar 4th [2]. Also, let us know if you have requested agenda time
> in a different WG session for the same topic.
>
> Thanks!
> PCE Chairs & Secretary
>
> [1] https://datatracker.ietf.org/meeting/119/agenda
> [2] https://datatracker.ietf.org/meeting/important-dates/
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] RV: New Version Notification for draft-contreras-pce-pam-02.txt

[Dhruv Dhody]

Hi Luis,

On Mon, Feb 26, 2024 at 11:59 PM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmuri...@telefonica.com> wrote:

> Hi Dhruv,
>
>
>
> Sorry for my late response.
>
>
>
> In version -01 we proposed a new METRIC Object-type within the existing
> object-class, but after internal analysis we decided to propose a new
> object in this version -02. We think is much cleaner approach and allows to
> re-use attributes already defined. Probably easier as well to parse and
> facilitate backward compatibility with existing implementations.
>
>
>

I am not sure I agree that the approach is much cleaner, but those can be
subjective. Just looking at the number of PCEP objects that have different
object-types at
https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects , it feels
this is the established practice for PCEP extensions and implementations
already does the encoding/decoding for lot of PCEP objects.


> Regarding the potential impacts in terms of RBNF grammar. Do you have any
> pointer or clue for better understanding such kind of impacts on the
> Routing Backus-Naur Form?
>
>
>

The impact is just that you need to update the RBNF for every PCEP message
that can carry this new object whereas in case of using an existing object
you
just get it for free :)

An example can be seen at recent objects added CCI, BU in RFC9050 and
RFC8233 respectively.

Thanks!
Dhruv



> Thanks in advance,
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* Dhruv Dhody 
> *Enviado el:* miércoles, 14 de febrero de 2024 5:42
> *Para:* LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com>
> *CC:* pce@ietf.org
> *Asunto:* Re: [Pce] RV: New Version Notification for
> draft-contreras-pce-pam-02.txt
>
>
>
> H Luis, WG,
>
>
>
> Did you consider defining a new METRIC Object-type (within the existing
> object-class 6) called Precision instead of defining a brand new object
> with new object-class/object-type?
>
>
>
> If we choose to define just a new object-type, it has an added advantage
> of keeping the RBNF grammar cleaner and we dont need to extend it.
>
>
>
> Thoughts?
>
>
>
> Thanks!
>
> Dhruv
>
>
>
> On Wed, Feb 14, 2024 at 12:57 AM LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com> wrote:
>
> Dear all,
>
> We have just updated draft-contreras-pce-pam in the following way:
>
> - we have changed the approach moving from extending existing METRIC
> object to proposing a new PRECISION METRIC object. The reason for that is
> we consider it as a cleaner approach, also allowing clearer structure.
>
> - we have also addressed the question raised by Dhruv (as chair) at IETF
> 118 about the convenience of including some example.
>
> - editorial clean-up.
>
> With this we think all the comments in IETF 118 have been addressed.
>
> Any further comment / suggestion is more than welcome.
>
> Best regards
>
> Luis
>
>
>
> -Mensaje original-
> De: internet-dra...@ietf.org 
> Enviado el: martes, 13 de febrero de 2024 20:22
> Para: LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com>; Fernando Agraz <
> fernando.ag...@upc.edu>; LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com>; salvatore.spadaro <
> salvatore.spad...@upc.edu>
> Asunto: New Version Notification for draft-contreras-pce-pam-02.txt
>
> A new version of Internet-Draft draft-contreras-pce-pam-02.txt has been
> successfully submitted by Luis M. Contreras and posted to the IETF
> repository.
>
> Name: draft-contreras-pce-pam
> Revision: 02
> Title:Path Computation Based on Precision Availability Metrics
> Date: 2024-02-13
> Group:Individual Submission
> Pages:14
> URL:  https://www.ietf.org/archive/id/draft-contreras-pce-pam-02.txt
> Status:   https://datatracker.ietf.org/doc/draft-contreras-pce-pam/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-contreras-pce-pam
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-contreras-pce-pam-02
>
> Abstract:
>
>The Path Computation Element (PCE) is able of determining paths
>according to constraints expressed in the form of metrics.  The value
>of the metric can be signaled as a bound or maximum, meaning that
>path metric must be less than or equal such value.  While this can be
>sufficient for certain services, some others can require the
>utilization of Precision Availability Metrics (PAM).  This document
>defines a new object, namely the PRECISION METRIC object, to be used
>for path calculation or selection for networking servi

[Pce] Fwd: [IANA #1359708] Fwd: Early code point allocation for draft-ietf-pce-circuit-style-pcep-extensions-02

[Dhruv Dhody]

Hi,

This early allocation is completed.

Thanks!
Dhruv

-- Forwarded message -
From: David Dong via RT 
Date: Sat, Feb 24, 2024 at 1:55 AM
Subject: [IANA #1359708] Fwd: [Pce] Early code point allocation for
draft-ietf-pce-circuit-style-pcep-extensions-02
To: 
Cc: , , <
draft-ietf-pce-circuit-style-pcep-extensi...@ietf.org>


Hi Dhruv and Julien,

We've completed the additional early allocations for this document:

STATEFUL-PCE-CAPABILITY TLV Flag Field (Section 8.1):

18  STRICT-PATH-CAPABILITY (TEMPORARY - registered 2024-02-23, expires
2025-02-23)  [draft-ietf-pce-circuit-style-pcep-extensions-03]
19  PATH-RECOMPUTATION-CAPABILITY (TEMPORARY - registered 2024-02-23,
expires 2025-02-23)   [draft-ietf-pce-circuit-style-pcep-extensions-03]

LSP-EXTENDED-FLAG TLV Flag Field (Section 8.2):

4   Strict-Path Flag (O) (TEMPORARY - registered 2024-02-23, expires
2025-02-23)[draft-ietf-pce-circuit-style-pcep-extensions-03]

PCEP TLV Type Indicators (Section 8.3):

72  PATH-RECOMPUTATION TLV (TEMPORARY - registered 2024-02-23, expires
2025-02-23)  [draft-ietf-pce-circuit-style-pcep-extensions-03]

Please see:
https://www.iana.org/assignments/pcep/

If the document hasn't been approved for publication by November, we'll
contact you about renewing for another year.

Best regards,

David Dong
IANA Services Sr. Specialist

On Fri Feb 23 07:28:41 2024, d...@dhruvdhody.com wrote:
> Hi IANA,
>
> Following the procedure for early allocation as per RFC 7120, we would
> like
> to request early allocation for following code points defined in -
>
> https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-
> extensions-03.html#section-8.1
>  (TBD1-2)
> https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-
> extensions-03.html#section-8.2
>  (TBD3)
> https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-
> extensions-03.html#section-8.3
>  (TBD4)
>
> An approval from the AD (in cc) can be found in the email chain below.
>
> Thanks!
> Dhruv & Julien
> PCE WG Co-chairs
>
>
> -- Forwarded message -
> From: John Scudder 
> Date: Fri, Feb 23, 2024 at 12:04 AM
> Subject: Re: [Pce] Early code point allocation for
> draft-ietf-pce-circuit-style-pcep-extensions-02
> To: Dhruv Dhody 
> Cc: draft-ietf-pce-circuit-style-pcep-extensi...@ietf.org <
> draft-ietf-pce-circuit-style-pcep-extensi...@ietf.org>, Samuel Sidor
> (ssidor) 
>
>
> Approved.
>
> —John
>
> P.S.: https://youtu.be/ArjUUDhntzE?t=151 :-)
>
> > On Feb 22, 2024, at 1:26 PM, Dhruv Dhody  wrote:
> >
> >
> > Hi John,
> >
> > The authors of draft-ietf-pce-circuit-style-pcep-extensions have
> requested for the early allocation of the codepoint specified in:
> >
> >
> https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-
> extensions-03.html#section-8.1
> (TBD1-2)
> >
> https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-
> extensions-03.html#section-8.2
> (TBD3)
> >
> https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-
> extensions-03.html#section-8.3
> (TBD4)
> >
> > We polled the WG and there were no objections. According to the
> > chairs’
> review, the RFC 7120 criteria is met. As per the process in the RFC,
> we now
> request your approval before reaching out to the IANA for the early
> allocation.
> >
> > Thanks!
> >
> > Dhruv & Julien
> >
> > On Thu, Feb 22, 2024 at 11:37 PM Samuel Sidor (ssidor)
> > 
> wrote:
> > Thanks, Dhruv.
> >  “draft-ietf-pce-circuit-style-pcep-extensions-03” submitted, which
> > fixed
> typo from previous mail.
> > Regards,
> > Samuel
> >  From: Pce  On Behalf Of Dhruv Dhody
> > Sent: Thursday, February 22, 2024 5:43 AM
> > To: pce@ietf.org
> > Cc: draft-ietf-pce-circuit-style-pcep-extensi...@ietf.org
> > Subject: Re: [Pce] Early code point allocation for
> draft-ietf-pce-circuit-style-pcep-extensions-02
> > Hi WG,
> > We received no objections and thus will be going ahead with the early
> allocation process.
> > Authors,
> > Can you fix the following error and post a new version?  We would
> > then
> trigger the allocation process...
> > OLD:
> > 8.1.  STATEFUL-PCE-CAPABILITY
> >
> > [RFC8231] defines the LSP-EXTENDED-FLAG TLV.  IANA is requested to
> > make the following assignment from the "STATEFUL-PCE-CAPABILITY TLV
> > Flag Field" registry:
> > NEW:
> > 8.1.  STATEFUL-PCE-CAPABILITY
> >
> > [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV.  IANA is requested
> to
> > make the following assignment from the "STA

[Pce] Fwd: [spring] New Version Notification for draft-karboubi-spring-sidlist-optimized-cs-sr-00.txt

[Dhruv Dhody]

Forwarding to PCE List for visibility

-- Forwarded message -
From: Karboubi, Amal 
Date: Wed, Feb 21, 2024 at 9:38 PM
Subject: Re: [spring] New Version Notification for
draft-karboubi-spring-sidlist-optimized-cs-sr-00.txt
To: spr...@ietf.org 


Hello,
We've submitted a new draft
https://datatracker.ietf.org/doc/draft-karboubi-spring-sidlist-optimized-cs-sr/.
This draft describes an alternative approach to achieve the circuit-style
segment routing policies described in WG document
https://datatracker.ietf.org/doc/draft-ietf-spring-cs-sr-policy/ whereby
the imposed limitation of having the SID List of such policies encode the
full path using only adjacency SIDs is removed. The draft introduces a
solution that allows the usage of optimized SID lists (i.e.  SID List that
may contain non-contiguous node SIDs as instructions) and describes
mechanisms that would allow such encoding to still honor all the
requirements of the circuit style policies notably traffic engineering and
bandwidth requirements.

Comments are welcome!

Thanks,
Amal Karboubi

-Original Message-
From: internet-dra...@ietf.org 
Sent: Wednesday, February 21, 2024 10:48 AM
To: Karboubi, Amal ; Alaettinoglu, Cengiz <
cen...@ciena.com>; Shah, Himanshu ; Sivabalan, Siva <
ssiva...@ciena.com>; Defilippi, Todd 
Subject: [**EXTERNAL**] New Version Notification for
draft-karboubi-spring-sidlist-optimized-cs-sr-00.txt

A new version of Internet-Draft
draft-karboubi-spring-sidlist-optimized-cs-sr-00.txt has been successfully
submitted by Amal Karboubi and posted to the IETF repository.

Name: draft-karboubi-spring-sidlist-optimized-cs-sr
Revision: 00
Title:Circuit Style Segment Routing Policies with Optimized SID List
Depth
Date: 2024-02-21
Group:Individual Submission
Pages:11
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-karboubi-spring-sidlist-optimized-cs-sr-00.txt__;!!OSsGDw!LOCKDtXAZV6MjAlGrMJArPpEWtLnrQFUJMKLDapmANpWOqasIEJWOn0f_VmwXOsK8JBRQXAwrbrPY6Q1aOZPpQV6$
[ietf[.]org]
Status:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-karboubi-spring-sidlist-optimized-cs-sr/__;!!OSsGDw!LOCKDtXAZV6MjAlGrMJArPpEWtLnrQFUJMKLDapmANpWOqasIEJWOn0f_VmwXOsK8JBRQXAwrbrPY6Q1aAW0WTQu$
[datatracker[.]ietf[.]org]
HTML:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-karboubi-spring-sidlist-optimized-cs-sr-00.html__;!!OSsGDw!LOCKDtXAZV6MjAlGrMJArPpEWtLnrQFUJMKLDapmANpWOqasIEJWOn0f_VmwXOsK8JBRQXAwrbrPY6Q1aARwiKAx$
[ietf[.]org]
HTMLized:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-karboubi-spring-sidlist-optimized-cs-sr__;!!OSsGDw!LOCKDtXAZV6MjAlGrMJArPpEWtLnrQFUJMKLDapmANpWOqasIEJWOn0f_VmwXOsK8JBRQXAwrbrPY6Q1aFbwYYSA$
[datatracker[.]ietf[.]org]


Abstract:

   Service providers require delivery of circuit-style transport
   services in a segment routing based IP network.  This document
   introduces a solution that supports circuit style segment routing
   policies that allows usage of optimized SID lists (i.e.  SID List
   that may contain non-contiguous node SIDs as instructions) and
   describes mechanisms that would allow such encoding to still honor
   all the requirements of the circuit style policies notably traffic
   engineering and bandwidth requirements.



The IETF Secretariat


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

Re: [Pce] Early code point allocation for draft-ietf-pce-circuit-style-pcep-extensions-02

[Dhruv Dhody]

Hi WG,

We received no objections and thus will be going ahead with the early
allocation process.

Authors,

Can you fix the following error and post a new version?  We would then
trigger the allocation process...

OLD:

8.1.  STATEFUL-PCE-CAPABILITY

   [RFC8231] defines the LSP-EXTENDED-FLAG TLV.  IANA is requested to
   make the following assignment from the "STATEFUL-PCE-CAPABILITY TLV
   Flag Field" registry:

NEW:

8.1.  STATEFUL-PCE-CAPABILITY

   [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV.  IANA is requested to
   make the following assignment from the "STATEFUL-PCE-CAPABILITY TLV
   Flag Field" registry:


Thanks!
Dhruv & Julien

On Wed, Feb 7, 2024 at 7:29 PM Dhruv Dhody  wrote:

> Hi WG,
>
> We have received a request from the authors of
> draft-ietf-pce-circuit-style-pcep-extensions for an early code point
> allocation for the codepoints listed in -
>
>
> https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-02.html#section-8.1
> (TBD1-2)
>
> https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-02.html#section-8.2
> (TBD3)
>
> https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-02.html#section-8.3
> (TBD4)
>
> RFC 7120 requires one 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 Wednesday, Feb 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

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

[Dhruv Dhody]

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] WG Adoption of draft-peng-pce-entropy-label-position-10

[Dhruv Dhody]

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.

Thanks!
Dhruv & Julien

On Fri, Jan 26, 2024 at 10:19 PM Dhruv Dhody  wrote:

> Hi WG,
>
> This email begins the WG adoption poll for
> draft-peng-pce-entropy-label-position-10
>
> https://datatracker.ietf.org/doc/draft-peng-pce-entropy-label-position/
>
> 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 12th Feb 2024.
>
> Please be more vocal during WG polls!
>
> Thanks!
> Dhruv & Julien
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Call for slot in the PCE WG at IETF 119

[Dhruv Dhody]

Hi,

The PCE WG would be meeting during the IETF 119 [1] week. If you need
agenda time
to progress some work, please send a slot request directly to the
chairs/secretary  by Monday, March 4th 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 also
Monday, Mar 4th [2]. Also, let us know if you have requested agenda time in
a different WG session for the same topic.

Thanks!
PCE Chairs & Secretary

[1] https://datatracker.ietf.org/meeting/119/agenda
[2] https://datatracker.ietf.org/meeting/important-dates/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] RV: New Version Notification for draft-contreras-pce-pam-02.txt

[Dhruv Dhody]

H Luis, WG,

Did you consider defining a new METRIC Object-type (within the existing
object-class 6) called Precision instead of defining a brand new object
with new object-class/object-type?

If we choose to define just a new object-type, it has an added advantage of
keeping the RBNF grammar cleaner and we dont need to extend it.

Thoughts?

Thanks!
Dhruv

On Wed, Feb 14, 2024 at 12:57 AM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmuri...@telefonica.com> wrote:

> Dear all,
>
> We have just updated draft-contreras-pce-pam in the following way:
>
> - we have changed the approach moving from extending existing METRIC
> object to proposing a new PRECISION METRIC object. The reason for that is
> we consider it as a cleaner approach, also allowing clearer structure.
>
> - we have also addressed the question raised by Dhruv (as chair) at IETF
> 118 about the convenience of including some example.
>
> - editorial clean-up.
>
> With this we think all the comments in IETF 118 have been addressed.
>
> Any further comment / suggestion is more than welcome.
>
> Best regards
>
> Luis
>
>
>
> -Mensaje original-
> De: internet-dra...@ietf.org 
> Enviado el: martes, 13 de febrero de 2024 20:22
> Para: LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com>; Fernando Agraz <
> fernando.ag...@upc.edu>; LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com>; salvatore.spadaro <
> salvatore.spad...@upc.edu>
> Asunto: New Version Notification for draft-contreras-pce-pam-02.txt
>
> A new version of Internet-Draft draft-contreras-pce-pam-02.txt has been
> successfully submitted by Luis M. Contreras and posted to the IETF
> repository.
>
> Name: draft-contreras-pce-pam
> Revision: 02
> Title:Path Computation Based on Precision Availability Metrics
> Date: 2024-02-13
> Group:Individual Submission
> Pages:14
> URL:  https://www.ietf.org/archive/id/draft-contreras-pce-pam-02.txt
> Status:   https://datatracker.ietf.org/doc/draft-contreras-pce-pam/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-contreras-pce-pam
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-contreras-pce-pam-02
>
> Abstract:
>
>The Path Computation Element (PCE) is able of determining paths
>according to constraints expressed in the form of metrics.  The value
>of the metric can be signaled as a bound or maximum, meaning that
>path metric must be less than or equal such value.  While this can be
>sufficient for certain services, some others can require the
>utilization of Precision Availability Metrics (PAM).  This document
>defines a new object, namely the PRECISION METRIC object, to be used
>for path calculation or selection for networking services with
>performance requirements expressed as Service Level Objectives (SLO)
>using PAM.
>
>
>
> The IETF Secretariat
>
>
>
> 
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
> ___
> 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] Fwd: [IANA #1358857] Re: Early code point allocation for draft-ietf-pce-segment-routing-policy-cp-12

[Dhruv Dhody]

Hi,

This early allocation is completed.

Thanks!
Dhruv

-- Forwarded message -
From: Sabrina Tanamal via RT 
Date: Wed, Feb 14, 2024 at 6:51 AM
Subject: [IANA #1358857] Re: Early code point allocation for
draft-ietf-pce-segment-routing-policy-cp-12
To: 
Cc: , , <
draft-ietf-pce-segment-routing-policy...@ietf.org>


Hi Dhruv and Julien,

We've completed the additional early allocations for this document:

PCEP TLV Type Indicators registry (Section 6.2):

68  COMPUTATION-PRIORITY (TEMPORARY - registered 2024-02-13, expires
2025-02-13)[draft-ietf-pce-segment-routing-policy-cp-14]
69  EXPLICIT-NULL-LABEL-POLICY (TEMPORARY - registered 2024-02-13,
expires 2025-02-13)  [draft-ietf-pce-segment-routing-policy-cp-14]
70  INVALIDATION (TEMPORARY - registered 2024-02-13, expires
2025-02-13)[draft-ietf-pce-segment-routing-policy-cp-14]
71  SRPOLICY-CAPABILITY (TEMPORARY - registered 2024-02-13, expires
2025-02-13) [draft-ietf-pce-segment-routing-policy-cp-14]

PCEP-ERROR Object Error Types and Values registry(Section 6.3):

6   Mandatory Object missing
21: Missing SR Policy Mandatory TLV (TEMPORARY - registered 2024-02-13,
expires 2025-02-13) [draft-ietf-pce-segment-routing-policy-cp-14]

26  Association Error
20: SR Policy Identifers Mismatch (TEMPORARY - registered 2024-02-13,
expires 2025-02-13)   [draft-ietf-pce-segment-routing-policy-cp-14]
21: SR Policy Candidate Path Identifier Mismatch (TEMPORARY - registered
2024-02-13, expires 2025-02-13)
[draft-ietf-pce-segment-routing-policy-cp-14]

TE-PATH-BINDING TLV Flag field registry (Section 6.4):

1   S (Specified-BSID-only) (TEMPORARY - registered 2024-02-13, expires
2025-02-13) [draft-ietf-pce-segment-routing-policy-cp-14]

Please see
https://www.iana.org/assignments/pcep

If the document hasn't been approved for publication by December, we'll
contact you about renewing for another year.

Best regards,

Sabrina Tanamal
Lead IANA Services Specialist

On Tue Feb 13 05:25:39 2024, d...@dhruvdhody.com wrote:
> Hi IANA,
>
> Following the procedure for early allocation as per RFC 7120, we would
> like
> to request early allocation for following code points defined in
>
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-
> cp-14.html#section-6.2
>  (TBD1-4)
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-
> cp-14.html#section-6.3
>  (TBD6-8)
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-
> cp-14.html#section-6.4
>  (TBD9)
>
> An approval from the AD (in cc) can be found in the email chain below.
>
> Note that there was an earlier allocation request where some
> codepoints
> were already allocated by IANA -
> https://mailarchive.ietf.org/arch/msg/pce/8GtjtxNWeA9MxpySx6J7XZKmlUc/
> Thanks!
> Dhruv & Julien
> PCE WG Co-chairs
>
> On Sat, Feb 10, 2024 at 6:37 PM John Scudder  wrote:
>
> > Approved.
> >
> > —John
> >
> > On Feb 10, 2024, at 1:27 AM, Dhruv Dhody  wrote:
> >
> > Hi John,
> >
> > The authors of draft-ietf-pce-segment-routing-policy-cp have
> > requested for
> > the early allocation of the codepoint specified in:
> >
> >
> > https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-
> > policy-cp-14.html#section-6.2
> > <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-
> > ietf-pce-segment-routing-policy-cp-14.html*section-
> > 6.2__;Iw!!NEt6yMaO-gk!Fkn1X-
> > qBnJV4EMHZM1CiBGd6i2laMtrXwmVcfGt5pdN7gxvPDWukyX1bs4fVtHgbBpAjD7SXOd4$>
> > (TBD1-4)
> >
> > https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-
> > policy-cp-14.html#section-6.3
> > <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-
> > ietf-pce-segment-routing-policy-cp-14.html*section-
> > 6.3__;Iw!!NEt6yMaO-gk!Fkn1X-
> > qBnJV4EMHZM1CiBGd6i2laMtrXwmVcfGt5pdN7gxvPDWukyX1bs4fVtHgbBpAjU9kcsWQ$>
> > (TBD6-8)
> >
> > https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-
> > policy-cp-14.html#section-6.4
> > <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-
> > ietf-pce-segment-routing-policy-cp-14.html*section-
> > 6.4__;Iw!!NEt6yMaO-gk!Fkn1X-
> > qBnJV4EMHZM1CiBGd6i2laMtrXwmVcfGt5pdN7gxvPDWukyX1bs4fVtHgbBpAj7X0mWuw$>
> > (TBD9)
> >
> > We polled the WG and there were no objections. According to the
> > chairs’
> > review, the RFC 7120 criteria is met. As per the process in the RFC,
> > we now
> > request your approval before reaching out to the IANA for the early
> > allocation.
> >
> > Thanks!
> >
> > Dhruv & Julien
> >
> > On Wed, Jan 24, 2024 at 11:21 AM Dhruv Dhody 
&

[Pce] Early code point allocation for draft-ietf-pce-circuit-style-pcep-extensions-02

[Dhruv Dhody]

Hi WG,

We have received a request from the authors of
draft-ietf-pce-circuit-style-pcep-extensions for an early code point
allocation for the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-02.html#section-8.1
(TBD1-2)
https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-02.html#section-8.2
(TBD3)
https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-02.html#section-8.3
(TBD4)

RFC 7120 requires one 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 Wednesday, Feb 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] AD review of draft-ietf-pce-segment-routing-ipv6-20

[Dhruv Dhody]

Hi Cheng,

In Section 9.2 (New SRv6-ERO NAI Type Registry) where you define a new
registry, please add -

The allocation policy for this new registry is by IETF Review [RFC8126].


Thanks!
Dhruv

On Wed, Jan 31, 2024 at 10:33 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 formats in this document are specified using Routing
> Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
> +--
> +jgs: as far as I can tell, no they are not. Either remove this
> +paragraph, and the normative reference, or help me understand why I am
> +wrong.
> +
> +Speaking of RBNF, the fact this spec doesn't use it seems to put it out
> +of step with some of the other PCE document set. I'm assuming it's the
> +consensus of the WG that this is fine. (I don't have a problem with the
> +style used here.)
> +--
>
> Further, following terms are used in the document,
>
> @@ -240,6 +253,11 @@
> SID:  Segment Identifier.
>
> SRv6:  Segment Routing for IPv6 forwarding plane.
> +--
> +jgs: in the introduction you expanded this as "Segment Routing over
> +IPv6 data plane", which seems like a better expansion to me. But either
> +way, please pick one and stick with it.
> +--
>
> SRH:  IPv6 Segment Routing Header.
>
> @@ -255,6 +273,14 @@
> Basic operations for PCEP speakers are as per [RFC8664].  SRv6 Paths

Re: [Pce] Clarification regarding Bandwidth Object Type and ordering in PcRpt

[Dhruv Dhody]

Hi Mrinmoy

On Tue, Jan 30, 2024 at 10:43 AM Mrinmoy Das  wrote:

> Hello Team,
>
> Happy New Year! Hope you all are doing fine.
>
> I would like to clarify my understanding of Bandwidth object Type usage
> and ordering in the PcRpt message.
>
> 1. *Ordering:*
>
> As per RFC8231 below the Bandwidth object can come under 
> 
> as well as .
>
>
>
> https://datatracker.ietf.org/doc/html/rfc8231#page-25
>
>
>
> *6.1 .  The PCRpt 
> Message*
>
>
>
>The format of the PCRpt message is as follows:
>
>
>
>::= 
>
>   
>
>Where:
>
>
>
>::= []
>
>
>
>::= []
>
>  
>
>  
>
> Where:
>
>   ::= 
>
> []
>
> 
>
>
>
>   ::=[]
>
> []
>
>
> RFC 5440: Section 6.5 specifies  as follows:
>
>
> ::=[]
>[]
>[]
>
>   []
>
>
> So, in response of a PcReply message from PCE, PCC can send Bandwidth in
> both actual and intended attribute list in following order:
>
>
> **
>
> Bandwidth <--- (i)
>
> Metric
>
> **
>
> **
>
> LSPA
>
> Bandwidth<--(ii)
>
> Metric
>
> IRO
>
> **
>
>
> Is my understanding correct?
>
>
>
Dhruv: Yes!



> 2. *Applicability of above ordering in PcRpt in response of PCInit:*
>
>
> Does this same ordering apply to PcRpt for PcInit as well? E.g. Bandwidth
> object that comes from PcInit will go in  and
> actual bandwidth of the path
>
> will go in ?
>
> My understanding is, in case of a positive scenario, both bandwidth will
> have the same value and PCC can omit reporting bandwidth in the intended
> list.
>
> In case of a negative scenario like PCC couldn't able to setup LSP with
> specified bandwidth, then it will send PcError.
>
>
>
Dhruv: Your understanding is correct but If for some reason PCC has a
different actual and intended path or attributes, say a local policy, it is
free to use the PCRpt encoding that allows it to signal both.



> 3.  *Bandwidth object Type usage:*
>
>
> Bandwidth object in  should be of Type-2 as per
> spec below:
>
>
>
> https://datatracker.ietf.org/doc/html/rfc8231#page-27
>
>
>
> Note that the intended-attribute-list is optional and
>
>thus may be omitted.  In this case, the PCE MAY use the values in the
>
>actual-attribute-list as the requested parameters for the path.
>
>
>
>The actual-attribute-list consists of the actual computed and
>
>signaled values of the BANDWIDTH and METRIC objects defined in
>
>[RFC5440 ].  When included 
> as part of the actual-attribute-list,
>
>Object-Type 2 [RFC5440 ] 
> SHOULD be used for the BANDWIDTH object, and
>
>the C flag SHOULD be set in the METRIC object [RFC5440 
> ].
>
>
>
> So, the Bandwidth object under  will always have
> Type 2. Is that right?
>

Dhruv: yes!



>
> So, in any scenario, if PCC reports the state of a LSP(solicited or
> unsolicited PCRpt), it will always use a Type-2 Bandwidth object to
> report actual bandwidth of a LSP. Right?
>
> Only in case of re-optimization request or when LSP's actual and intended
> Bandwidth can differ, in those cases Bandwidth of both types may be used.
> Is this correct understanding?
>
>
>
Dhruv: Yes, another way to map this to the use of ERO/RRO.
That is if RRO (actual-path) is used, the associated BANDWIDTH of
actual-attribute-list is Type 2. And when Bandwidth is part of
intended-attribute-list it is of Type 1.
If the BANDWIDTH is the same, it MAY be encoded only once!




> 4. *PcRpt message structure: optional object notation:*
>
>
> https://datatracker.ietf.org/doc/html/rfc8231#page-27
>
>
>
> Note that the intended-attribute-list is optional and
>
>thus may be omitted.  In this case, the PCE MAY use the values in the
>
>actual-attribute-list as the requested parameters for the path.
>
>
> above spec lines specifies that reporting of  is
> optional. But the PcRpt message structure notation is showing it mandatory
> as follows:
>
> *6.1 .  The PCRpt 
> Message*
>
>
>
>The format of the PCRpt message is as follows:
>
>
>
>::= 
>
>   
>
>Where:
>
>
>
>::= []
>
>
>
>::= []
>
>  
>
>  
>
> Where:
>
>   ::= 
>
> []
>
> 
>
>
>
>   ::=[]
>
> []
>
>
>
> Shouldn't it be like as follows:
>
> Where:
>
>   ::= 
>
> 
>
> []
>
> Please clarify.
>
>
Dhruv: Yes! Refer to verified erratum -
https://www.rfc-editor.org/errata/eid5492

Thanks!
Dhruv



> Thanks & Regards,
> Mrinmoy
> ___

[Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

[Dhruv Dhody]

Hi WG,

This email begins the WG adoption poll for
draft-peng-pce-entropy-label-position-10

https://datatracker.ietf.org/doc/draft-peng-pce-entropy-label-position/

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 12th Feb 2024.

Please be more vocal during WG polls!

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

Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo

[Dhruv Dhody]

Hi Samuel,

Noted!

One comment from my side -- PLease add some analysis in the security
consideration, an empty security consideration is bound to raise eyebrows!

Thanks!
Dhruv

On Fri, Jan 26, 2024 at 7:01 PM Samuel Sidor (ssidor) 
wrote:

> Hi PCE-chairs,
>
> Since we haven't received any other comments for this draft, I would like
> to ask for WGLC for this draft:
> https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-07.html
>
> Thanks a lot,
> Samuel
>
> -Original Message-
> From: Samuel Sidor (ssidor) 
> Sent: Monday, January 15, 2024 1:11 PM
> To: Samuel Sidor (ssidor) ; tom petch <
> ie...@btconnect.com>; Dhruv Dhody 
> Cc: pce@ietf.org
> Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo
>
> Just small update - 07 version submitted now.
>
> Regards,
> Samuel
>
> -Original Message-
> From: Pce  On Behalf Of Samuel Sidor (ssidor)
> Sent: Friday, January 12, 2024 1:43 PM
> To: tom petch ; Dhruv Dhody 
> Cc: pce@ietf.org
> Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo
>
> Hi Tom,
>
> Attached updated document + diff. I'll submit it tomorrow in case of no
> further comments.
>
> Regards,
> Samuel
>
> -Original Message-
> From: tom petch 
> Sent: Friday, January 12, 2024 12:33 PM
> To: Samuel Sidor (ssidor) ; Dhruv Dhody <
> dhruv.i...@gmail.com>
> Cc: pce@ietf.org
> Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo
>
> From: Samuel Sidor (ssidor) 
> Sent: 12 January 2024 10:53
>
> Thanks Tom,
>
> I'll send updated draft in this mail thread soon.
>
> By the way - there is already big mess in naming of that algorithm across
> multiple RFCs (I really don't want to cause headache to you 😊 ):
>
> 
> I know!  That is why I was keen to get it right in PCE.  Some WG are less
> responsive than others to outside comments so I leave them to get into
> whatever knots they want to:-(  I see LSR as the owner of the algorithm
> work, as least initially, so think that they should be followed.  That
> said, I think that RFC9350 culd have done more but that is water under the
> bridge.  Sometimes you have to say something along the lines of 'xxx whcih
> is referred to as zxyx in the Normative reference'
>
> Tom Petch
>
>
> IGP RFCs are talking about "SR-Algorithm" (as we already discussed in this
> thread), e.g.
> https://datatracker.ietf.org/doc/html/rfc8665#name-sr-algorithm-tlv
>
> SR policy architecture RFC is talking about "SR Algorithm":
> https://datatracker.ietf.org/doc/html/rfc9256#name-segment-types
>
> SR architecture RFC is talking calling it "Prefix SID Algorithm":
> https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.1
>
> And IANA registry is calling it "IGP Algorithm":
>
> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types
>
> ...and they are all talking about same thing.
>
> I'll follow naming from IGP as we are relying a lot on those RFCs and we
> are inheriting already defined Flex-algo behavior from those as well, but
> it is hard to be correct now. I'll add pointers to SR policy architecture
> and SR architecture RFCs as well.
>
> Regards,
> Samuel
>
> -Original Message-
> From: tom petch 
> Sent: Friday, January 12, 2024 11:10 AM
> To: Samuel Sidor (ssidor) ; Dhruv Dhody <
> dhruv.i...@gmail.com>
> Cc: pce@ietf.org
> Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo
>
> Samuel
>
> Yes the comments at the end work for me
>
> Tom Petch
>
> 
> From: Samuel Sidor (ssidor) 
> Sent: 11 January 2024 12:50
> To: tom petch; Dhruv Dhody
> Cc: pce@ietf.org
> Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo
>
> Hi Tom,
>
> Since you responded to both mails (from me and from Dhruv) together, I'll
> respond here.
>
> Please see inline .
>
> Regards,
> Samuel
>
> -Original Message-
> From: tom petch 
> Sent: Thursday, January 11, 2024 1:25 PM
> To: Dhruv Dhody 
> Cc: Samuel Sidor (ssidor) ; pce@ietf.org
> Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo
>
> inline 
>
> 
> From: Dhruv Dhody 
> Sent: 10 January 2024 13:06
>
> Hi Tom, WG,
>
> Speaking as a WG member...
>
> On Wed, Jan 10, 2024 at 4:30 PM tom petch  ie...@btconnect.com>> wrote:
> Sent: 10 January 2024 10:18
>
> Hi PCE WG,
>
> I would like to ask for WG LC for draft-ietf-pce-sid-algo on behalf of
> authors. Are there any remaining issues/comm

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

[Dhruv Dhody]

Hi Mike,

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-13.html#section-6.2

Can the TBD4 SR-POLICY-CAPABILITY be changed to  SRPOLICY-CAPABILITY to
match the naming style for other TLVs?

Thanks!
Dhruv

-- Forwarded message -
From: Dhruv Dhody 
Date: Wed, Jan 24, 2024 at 11:21 AM
Subject: Re: Early code point allocation for
draft-ietf-pce-segment-routing-policy-cp-12
To: 
Cc: , pce-chairs <
pce-cha...@ietf.org>


Hi WG,

We received no objections and thus will be going ahead with the early
 allocation process.

Thanks!
Dhruv & Julien

On Wed, Jan 10, 2024 at 6:53 PM Dhruv Dhody  wrote:

> Hi WG,
>
> We have received a request from the authors of
> draft-ietf-pce-segment-routing-policy-cp for an early code point allocation
> for the codepoints listed in -
>
>
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.2
> (TBD1-4)
>
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.3
> (TBD6-8)
>
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.4
> (TBD9)
>
> Note that there was an earlier allocation request where some codepoints
> were already allocated by IANA -
> https://mailarchive.ietf.org/arch/msg/pce/8GtjtxNWeA9MxpySx6J7XZKmlUc/
> Note that the draft is also undergoing a parallel WGLC -
> https://mailarchive.ietf.org/arch/msg/pce/ert_k7k5iYq3LWbaTc-aMwRRAbs/
>
> RFC 7120 requires one 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 Wednesday, Jan 24th, 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] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp-12

[Dhruv Dhody]

Hi WG,

We received no objections and thus will be going ahead with the early
 allocation process.

Thanks!
Dhruv & Julien

On Wed, Jan 10, 2024 at 6:53 PM Dhruv Dhody  wrote:

> Hi WG,
>
> We have received a request from the authors of
> draft-ietf-pce-segment-routing-policy-cp for an early code point allocation
> for the codepoints listed in -
>
>
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.2
> (TBD1-4)
>
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.3
> (TBD6-8)
>
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.4
> (TBD9)
>
> Note that there was an earlier allocation request where some codepoints
> were already allocated by IANA -
> https://mailarchive.ietf.org/arch/msg/pce/8GtjtxNWeA9MxpySx6J7XZKmlUc/
> Note that the draft is also undergoing a parallel WGLC -
> https://mailarchive.ietf.org/arch/msg/pce/ert_k7k5iYq3LWbaTc-aMwRRAbs/
>
> RFC 7120 requires one 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 Wednesday, Jan 24th, 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-segment-routing-policy-cp-12

[Dhruv Dhody]

Hi WG,

The WGLC has ended. Thanks to everyone who contributed with review comments
during this last call discussion. These are very helpful to gauge the
consensus of the WG to move the draft forward towards publication.

Authors,

Thanks for posting -13. Is there a need for another version update to
handle any pending comments or are we ready to go?

Thanks!
Dhruv & Julien





On Mon, Jan 8, 2024 at 3:58 PM Dhruv Dhody  wrote:

> 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

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

[Dhruv Dhody]

Hi WG,

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

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.2
(TBD1-4)
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.3
(TBD6-8)
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.4
(TBD9)

Note that there was an earlier allocation request where some codepoints
were already allocated by IANA -
https://mailarchive.ietf.org/arch/msg/pce/8GtjtxNWeA9MxpySx6J7XZKmlUc/
Note that the draft is also undergoing a parallel WGLC -
https://mailarchive.ietf.org/arch/msg/pce/ert_k7k5iYq3LWbaTc-aMwRRAbs/

RFC 7120 requires one 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 Wednesday, Jan 24th, 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] Any missed comments for draft-ietf-pce-sid-algo

[Dhruv Dhody]

Hi Tom, WG,

Speaking as a WG member...

On Wed, Jan 10, 2024 at 4:30 PM tom petch  wrote:

> From: Pce  on behalf of Samuel Sidor (ssidor)
> 
> Sent: 10 January 2024 10:18
>
> Hi PCE WG,
>
> I would like to ask for WG LC for draft-ietf-pce-sid-algo on behalf of
> authors. Are there any remaining issues/comments/questions which I (or
> co-authors) missed and which are not handled yet?
>
> URL: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/
>
> 
> Well new to the PCE list may be I fear but I have a basic problem about
> 'algorithm'.
>
> You reference RFC8665 and RFC 8667.  In those it is always SR-Algorithm so
> I think that that should be the spelling here.
>
>
Dhruv: The container is SR-ERO and SRv6-ERO where the field "Algorithm" is
being added. To me it is clear it is an SR-Algorithm. You will find the
similar usage in other RFC i.e.the TLV is called SR-Algorithm TLV but the
field inside is just Algorithm.



> More fundamentally,  8665 sets up an IANA registry with two values, 0 and
> 1, which tells me that 8665 is out of date as soon as it is published and
> that all references should be  to IANA and not the RFC.  The update policy
> is Standards Action.  ADs regard additions to IANA registries as not
> updating the RFC creating the registry so reading 8665 will not tell you
> that it is out of date unless you read between the lines of the IANA
> Considerations and go see what is current.
>
>
Dhruv: It is usual for one to reference the RFC that created the registry,
it is evident there will be future RFCs or documents that add more
codepoints; the reference to the original RFC that created the registry is
still valid. I don't recall anyone asking to explicitly reference the
registry. That said, there is no harm in adding an additional reference to
IANA.



> It gets more problematic.  The IANA registry was updated by RFC9350 which
> keeps the same update criteria  but splits the range into two 0-127 and
> 128-255, the latter being flexible.
>
> s.4.2.1 talks of Flexible Algorithm with a Normative reference to RFC9350
> which begs the question as to the relationship between SR Algorithm and
> Flexible Algorithm when used in this document. Either/or, Synonyms?
>
> Here and  now it may all be obvious but in years to come with multiple
> algorithms in use it will likely be unclear what you are referencing in
> s.3.2, s.3.3, s.3.4; is it the range 0-127 or 0-255 or 128-255 or...?
>
>
Dhruv: It is 0-255! Authors can make that explicit in the I-D.

Thanks!
Dhruv



> Tom Petch
>
>
>
> Thanks a lot,
> Samuel
>
> ___
> 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] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Dhruv Dhody]

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] Murray Kucherawy's No Objection on draft-ietf-pce-pceps-tls13-03: (with COMMENT)

[Dhruv Dhody]

Hi Murray,

On Thu, Jan 4, 2024 at 11:30 AM Murray Kucherawy via Datatracker <
nore...@ietf.org> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-pce-pceps-tls13-03: 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-pceps-tls13/
>
>
>
> --
> COMMENT:
> --
>
> Further to Eric's comment, I'm completely confused by question #4 of the
> shepherd writeup.  While the document claims there are no implementations
> known, the shepherd writeup says there's at least one (and it was easy),
> and
> makes another "Yes" remark that I don't understand.
>
>
>
Dhruv: The shepherd writeup mentions this email response on the mailing
list -
https://mailarchive.ietf.org/arch/msg/pce/dLdcUan2psssBUgzCtXPluEr_ok/ that
mentions some implementation experience. When we asked to include that
information in the implementation section we did not get a confirmation
back. Soo that's that :)

We could update the implementation section to say -

OLD:
   At the time of posting the -02 version of this document, there are no
   known implementations of this mechanism.
NEW:
   At the time of posting the -04 version of this document, there are no
   known implementations of this mechanism. It is believed that one
   vendor has implementation, but these plans are too vague to make
   any further assertions.
END

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

Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-pceps-tls13-03: (with COMMENT)

[Dhruv Dhody]

Hi Èric,

Happy 2024!

On Tue, Jan 2, 2024 at 6:03 PM Éric Vyncke via Datatracker 
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-pce-pceps-tls13-03: 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-pceps-tls13/
>
>
>
> --
> COMMENT:
> --
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05
>
> Thank you for the work put into this document. It was an easy and simple
> read
> for my first document review in 2024!
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
>
> Special thanks to Andrew Stone for the shepherd's detailed write-up
> including
> the WG consensus and the justification of the intended status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # COMMENTS (non-blocking)
>
> ## Section 1
>
> Is it a `Editor's Note:` or a "Note to the IESG" or a "Note to the RFC
> Editor" ?
>

Dhruv: It was an Editor's note while we were working on the I-D. At this
stage perhaps we can just remove the note now and stick it out with the
fate of RFC8446bis (which is in the post-WGLC stage). Sean and Russ should
chime in if they disagree :)




>
> ## Section 3
>
> `MUST prefer to negotiate the latest version` is of course the preferred
> behavior for the initiator, but should the document clearly specify that
> the
> responser "MUST select the latest version" ? (please bear with me as
> English is
> not my primary language).
>

Dhruv: FWIW I see the phrase usage in RFC 9325 as well as in the netconf
tls 1.3 I-D which was in a recent IESG telechat! ¯\_(ツ)_/¯


> ## Section 6
>
> I wonder about the usefulness of an implementation section having `there
> are no
> known implementations of this mechanism.`
>
>
>
>
Dhruv: PCE WG set out an Implementation Section Policy listed at
https://wiki.ietf.org/group/pce/ImplementationPolicy
We wanted the WG and the IETF community to be aware of known
implementations (or lack thereof) at the time of approval, at publication
the section is anyway removed.

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