Hi Quan, Replies inline below.
Thanks Andrew From: "xiong.q...@zte.com.cn" <xiong.q...@zte.com.cn> Date: Sunday, February 4, 2024 at 3:26 AM To: "Andrew Stone (Nokia)" <andrew.st...@nokia.com> Cc: "d...@dhruvdhody.com" <d...@dhruvdhody.com>, "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 You don't often get email from xiong.q...@zte.com.cn. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> 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 Andrew, Thanks for your detailed review and suggestions! Much appreciated! Please see in line with [Quan]. - 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? [Quan]: Thanks for your remind. Other than the BGP ongoing work, the acronym of ELP (Entropy Label Position) was also defined in that draft. Would it be better to add this reference to the ELP? Thanks! [Andrew]: Seems sensible to me to define ELP here and disconnect from the IDR draft. In the past often PCE/IDR documents often cross reference the protocol agnostic documents rather than cross reference each other (I think) and even if there’s minor re-statement of definitions should be okay. - Section 3 wording is a bit clunky to me and 'node segment path' could be construed differently. Perhaps an alternative wording of below suggestion? [Quan]: Your suggested texts will be taken and replace the OLD in next version. Thanks! [Andrew]: ACK - Section 4.2 and section 4.3 -> This document defined / This document defines. [Quan]: Thanks for your remind and it will be updated in next version. [Andrew]: ACK - 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?. [Quan]: Thanks for your comment. From my understanding , E position is a recommendation. To clarify it , would it be better to update the section 4.3 to "If this flag is set, the PCC SHOULD insert <ELI,EL> into the position after this SR-ERO subobject" and update the section 5 to "It indicates that two <ELI, EL> pairs SHOULD be inserted into the label stack of the SR-TE forwarding entry, respectively after the label for S3 and label for S6."? [Andrew] Yep that sounds good to me. Thanks! - 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" ? [Quan]: Thanks for your suggestion. Would it be better to remove the second sentence in section 6 and add the "When computing the ELI/EL positions the PCE MUST take into consideration MSD imposition" in section 3? [Andrew] I'm not sure if section 6 would be good location for it or not. I see that sentence as more of a functional requirement rather than security consideration, as it's just a way to nudge the reader "don't forget about this __". I'm not against it going to section 6, but feel section 3 would be more appropriate. Best Regards, Quan Original From: AndrewStone(Nokia) <andrew.st...@nokia.com> To: 熊泉00091065;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>; Date: 2024年02月03日 02:30 Subject: Re: WG Adoption of draft-peng-pce-entropy-label-position-10 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
