[Pce] Re: draft-ietf-pce-entropy-label-position-07 early Opsdir review

[[e-mail]]

Hi Qin，

Thanks for your detailed review and comments on this document!

Your concerns will be reflected in next version which may be submitted after Chinese holiday. 

Please see inline with Quan->. Thanks!

Best Regards,
Quan







Original


From: QinWuviaDatatracker <[e-mail]>
  
To: [e-mail] <[e-mail]>;
  
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2026年09月30日 12:13
  
Subject: draft-ietf-pce-entropy-label-position-07 early Opsdir review
  


Document: draft-ietf-pce-entropy-label-position
Title: Path Computation Element Communication Protocol (PCEP) Extension for
SR-MPLS Entropy Label Positions Reviewer: Qin Wu Review result: Has Issues
 
Hi,
 
I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.
 
The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.
 
A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.
 
While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.
 
- Document: [draft-ietf-pce-entropy-label-position-07]
 
- Reviewer: [Qin Wu]
 
- Review Date: [2026-09-30]
 
- Intended Status: [Standards Track]
 
---
 
## Summary
 
This document defines a set of extensions for PCEP protocol for Entropy Label
Positions. These extension can be used to configure where in the label stack
the ELI/EL pairs should be inserted in SR-MPLS network. I have read the v-07, I
think it is on the right tack but has a few issues that should be resolved
before publication.
 
## Major Issues
 
1. Section 6 said:
" 
   If the PCC does not set the request flag but the PCE includes E flags
   in the SR-ERO response, the PCC MUST NOT apply them and return a
   PCErr message with Error-Type = 10 ("Reception of an invalid object")
   and Error-value = TBD5 ("Unexpected ELP information").
" 
It is not clear why only PCC initiated Entropy Label Positions computation is
allowed? Suppose both PCC and PCE support the computation of SR path with ELP
information, why PCE initiated ELP information computation is forbidden?
 
It will be great to clarify why PCE initiated ELP information computation is
ruled out in the operational consideration section.

Quan->In stateless PCE [RFC5440], the PCC can send the LSP request to ask PCE to compute path. In stateful PCE [RFC8231], the PCE can compute the path and intial the LSP to the PCC. But in these two cases, only when PCC and PCE both supports the ELP capability, the PCC can accept the ELP configuration.  It is mandary. I will clarify it in the next version.
 
2. Section 10.2 said:
" 
   The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang].  In
   future, this YANG module should be extended or augmented to provide
   the following additional information relating to entropy label
   position.
" 
I am wondering whether this pararaph should be moved to operational section.
It is not clear to me how YANG data model in the management plane can work
together with PCEP to support the computation of SR path with ELP information,
can we design the model to replace PCE capability exchange phase and ELP
configuration request phase?

Quan->Thanks, it will be moved to operational section. I think the PCEP yang may be modified such as adding E bit in PCE capability exchange and E bit in SR-ERO.
 
3. Section 6 Error handling
when you say
" 
   If a PCUpd or later path re-computation changes or removes a path,
   the PCE SHOULD changes or removes the E flag at the same time and the
   PCC SHOULD replace the ELP with the new SR-ERO subobject when the ELP
   is valid.
 
" 
how do you know ELP is still valid when path re-computation changes or a path
is removed? How PCUpd is different from path re-computation changes and path
removal? Should this be discussed in the operational section as well, in
additional to Error handling section?

Quan->Sorry, this pararaph has been replaced by the next pararaph and it will be removed in the next version.
It is mandary to have the ELP information recomputed together with the SR-ERO subobjects and the PCC will do
  the complete replacement for the previous ELP position set for that LSP. 


 
4. When you compute SR path with ELP information, have you consider add ELP
flag for each segments, Is there any impact on network operation? what is your
criteria to select a set of segments to add ELP flag using the SR-ERO
subobject? Suggest to add some text in the operational consideration to talk
about this.

Quan->Thanks for your remind, I will add some clarification in the operational consideration.
 
---
 
## Minor Issues
 
1. Section 1
s/keeping a good level of entropy in the load-balancing/keeping a good level of
entropy for the load-balancing
 
2. Section 1 Said
"In some cases, the controller(e.g., PCE) could be used to perform the TE path
computation as well as ELP information" can not parse this sentence, PCE can be
used to perform ELP information? or perform ELP information calculation or ELP
position information calculation?
 
3. Section 3
 
Please add ERLD into a terminology section, in addition, provide reference to
ERLD, i think it is RFC8662
 
s/the number of labels a router can read in an MPLS packet and use in its
load-balancing function/the number of labels which a router can read in an MPLS
packet and use in its load-balancing function
 
s/the ELRD value is an important consideration when inserting ELI/EL / the ERLD
value is an important factor that needs to be considered when inserting ELI/EL
s/the minimum ELRD must be evaluated for each node along a computed path / the
minimum ERLD must be evaluated for each node along a computed path
 
4. Section 3 said:
" 
This necessary step adds additional complexity in the ELI/EL insertion
process and it may not be feasible for an ingress router to compute
the appropriate ERLD for each node in the path, since a SR-MPLS path
may contain segments the ingress router can resolve such as inter-domain
scenarios. " I can not parse this sentence, are you saying, in the inter-domain
secarnios, more segments needs to be parsed by the ingress router, in addition,
some ingress router can not compute ERLD value? If that is case, please break
down this long sentence into 2 or 3 short sentences.
 
add MSD into terminology section
 
5. Section 4.1
What is PST? Path Setup Type, please add PST into new teminology section, in
addtion, please add reference for PST, I think it is RFC8408.
 
I can not parse the following sentence "supports the results of SR path with
ELP from PCE"? Support assembling the results of SR with ELP from PCE? or
Supports reading the results of SR path with ELP from PCE?
 
6. Section 4.3 said
" 
the PCC SHOULD insert <ELI, EL> into the position after this SR-ERO subobject
" 
I understand <ELI, EL> is inserted after SR-ERO subobject, should we see ELI+EL
as one segment or two segments? what data format will be look like when we set
the order for <ELI, EL>+SR-ERO?
 
7. Section 5
It lacks clarity on whether New LSP-EXTENDED-FLAG Flag and New SR-ERO Flag MUST
be used together? It is also not clear whether New SR PCE Capability Flag
should be exchanged first, and then we can have LSP-EXTENDED-FLAG Flag exchange
between PCE and PCC?
 
8. Section 6
s/Unvalid ELP information/Invalid ELP information
s/unvalid/invalid
 
Quan-> Thanks for your detailed editorial review, I will revised them in next version.