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!
- 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!
- 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.
- 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."?
- 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?
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
