Hi Authors and WG. Overall the document reads pretty clear. Some comments/feedback from doing a read through:
- Is there any value in having a reference to draft-ietf-idr-bgp-srmpls-elp-00? From the read I don't see any other purpose than "this is also ongoing" and can likely be removed? - Section 3 wording is a bit clunky to me and 'node segment path' could be construed differently. Perhaps an alternative wording of below suggestion? OLD "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." NEW SUGGESTION: the ELRD value is an important consideration when inserting ELI/EL and the minimum ELRD must be evaluated for each node along a computed path. 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. - Section 4.2 and section 4.3 -> This document defined / This document defines. - Section 4.3 -> the current text seems to interpret that the E position is a recommendation(is my interpretation), rather than a 'must insert'. Is that the case? In my view it should be a recommendation so perhaps it should include some language such as "When E flag is set, the PCC SHOULD insert <ELI,EL> after this position. When the flag is not set, the PCC SHOULD NOT insert <ELI,EL> after this position" ? Now, of course as I kept reading it turns out Section 5 indicates it's a MUST, is MUST too strong? What should happen if it cannot? I'm not sure why pcc would not be able to but trying to consider what it should do if it cannot?. - Section 6 briefly indirectly comments on MSD implications and Section 3 describes that it can/how to learn MSD but I find doesn't bind it with ELI/EL position calculation. I think this document should include explicit text somewhere that says something such as "When computing the ELI/EL positions the PCE MUST take into consideration MSD imposition" ? Thanks Andrew From: "xiong.q...@zte.com.cn" <xiong.q...@zte.com.cn> Date: Monday, January 29, 2024 at 2:14 AM To: "d...@dhruvdhody.com" <d...@dhruvdhody.com> Cc: "pce@ietf.org" <pce@ietf.org>, "pce-cha...@ietf.org" <pce-cha...@ietf.org>, "draft-peng-pce-entropy-label-posit...@ietf.org" <draft-peng-pce-entropy-label-posit...@ietf.org> Subject: Re: WG Adoption of draft-peng-pce-entropy-label-position-10 Resent-From: <alias-boun...@ietf.org> Resent-To: <andrew.st...@nokia.com>, <julien.meu...@orange.com>, <d...@dhruvdhody.com> Resent-Date: Monday, January 29, 2024 at 2:14 AM Hi Dhruv and WG, I support the adoption as co-author. This draft is useful and reasonable for PCEP extensions to configure the entropy label positions in SR-MPLS networks as described in RFC8662. Thanks, Quan Original From: DhruvDhody <d...@dhruvdhody.com> To: 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年01月27日 00:50 Subject: 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
