Hi Xuesong,
Thanks for your support and comments! Much appreciated!
Please see inline with [Quan].
1. Introduction
...This document proposes a set of extensions for PCEP to configure the ELP
information for SR- MPLS networks.
"
"ELP information" is mentioned here without clear definition (although it is
implied in the context)and it is also used in section 4 about PCEP extensions.
Maybe it could be considered to add a definition firstly. Or if it has been
defined in other document, adding a reference will be helpful.
[Quan]:Thanks for your suggestion. And Andrew also mentioned the ELP as
defined in [I-D.ietf-idr-bgp-srmpls-elp], so would it be better to fix the
sentence in introduction to add the ELP definition such as "The ELP (Entropy
Label Position) as per [I-D.ietf-idr-bgp-srmpls-elp] is defined to indicate
the positions of the ELI/ELs which need to be inserted into the label stack."
It will be updated in next version.
3. Entropy Labels in SR-MPLS Scenario with PCE
...
As described in [RFC8662] section 7, the ERLD value is important for
inserting ELI/EL and the ingress node need to evaluate the minimum
ERLD value along the node segment path. But it will add complexity
in the ELI/EL insertion process. Moreover, the ingress node cannot
find the minimum ERLD along the path and does not support the
computation of the minimum ERLD especially in inter-domain scenarios.
It seems that the proposals of this document addresses the issues for both
inter-domain and intra-domain scenarios, especially for inter-domain. It that
is the case, I suggest to point this out and separate these 2 scenarios into 2
paragraphs.
[Quan]:Yes, the issue is existed in both inter-domain and intra-domain
scenarios, but the problem may be urgent and obvious for inter-domain scenario
cause the ingress node cannot find the minimum ERLD along the path and does
not support the computation of the minimum ERLD. The intra-domain has been
included in the processing of inter-domain and I think one paragraph can
describe it clearly and simply. LOL
5. Operations
The SR path is initiated by PCE or PCC with PCReq, PCInitiated or
PCUpd messages and the E bit is set to 1 in LSP object to request the
ELP configuration. The SR-TE path being received by PCC with SR-ERO
segment list, for example, <S1, S2, S3, S4, S5, S6>, especially S3
and S6 with E-flag set. It indicates that two <ELI, EL> pairs MUST
be inserted into the label stack of the SR-TE forwarding entry,
respectively after the label for S3 and label for S6. With EL
information, the label stack for SR-MPLS would be <label1, label2,
label3, ELI, EL, label4, label5, label6, ELI, EL>.
I think the example here is very clear to explain how the extensions work,
maybe it could be considered to modify the title of this section to
"operational example" directly.
[Quan]: Agree with you. It will be updated in next version.
Best Regards,
Quan
Original
From: XuesongGeng <gengxuesong=40huawei....@dmarc.ietf.org>
To: Dhruv Dhody <d...@dhruvdhody.com>;pce@ietf.org <pce@ietf.org>;
Cc: pce-chairs
<pce-cha...@ietf.org>;draft-peng-pce-entropy-label-posit...@ietf.org
<draft-peng-pce-entropy-label-posit...@ietf.org>;
Date: 2024年02月04日 17:43
Subject: RE: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10
Hi WG,
I have reviewed the document and there is no objection for WG adoption.
Please find some editing comments for authors' reference as below.
Best
Xuesong
---
1. Introduction
...This document proposes a set of extensions for PCEP to configure the ELP
information for SR- MPLS networks.
"
"ELP information" is mentioned here without clear definition (although it is
implied in the context)and it is also used in section 4 about PCEP extensions.
Maybe it could be considered to add a definition firstly. Or if it has been
defined in other document, adding a reference will be helpful.
3. Entropy Labels in SR-MPLS Scenario with PCE
...
As described in [RFC8662] section 7, the ERLD value is important for
inserting ELI/EL and the ingress node need to evaluate the minimum
ERLD value along the node segment path. But it will add complexity
in the ELI/EL insertion process. Moreover, the ingress node cannot
find the minimum ERLD along the path and does not support the
computation of the minimum ERLD especially in inter-domain scenarios.
It seems that the proposals of this document addresses the issues for both
inter-domain and intra-domain scenarios, especially for inter-domain. It that
is the case, I suggest to point this out and separate these 2 scenarios into 2
paragraphs.
5. Operations
The SR path is initiated by PCE or PCC with PCReq, PCInitiated or
PCUpd messages and the E bit is set to 1 in LSP object to request the
ELP configuration. The SR-TE path being received by PCC with SR-ERO
segment list, for example, <S1, S2, S3, S4, S5, S6>, especially S3
and S6 with E-flag set. It indicates that two <ELI, EL> pairs MUST
be inserted into the label stack of the SR-TE forwarding entry,
respectively after the label for S3 and label for S6. With EL
information, the label stack for SR-MPLS would be <label1, label2,
label3, ELI, EL, label4, label5, label6, ELI, EL>.
I think the example here is very clear to explain how the extensions work,
maybe it could be considered to modify the title of this section to
"operational example" directly.
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Saturday, January 27, 2024 12:49 AM
To: pce@ietf.org
Cc: pce-chairs <pce-cha...@ietf.org>;
draft-peng-pce-entropy-label-posit...@ietf.org
Subject: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10
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
