Hi Andrew, Thank you for your support and suggestions.
Since this draft is going to be refined considering the new draft being built in SPRING, the current uploaded draft is not changed accordingly. Please find more responses in line below. From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com] Sent: Friday, April 1, 2022 10:31 PM To: Dhruv Dhody <d...@dhruvdhody.com>; pce@ietf.org Cc: draft-li-pce-pcep-p...@ietf.org Subject: Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05 Hi PCE WG Support adoption, seems reasonable to relay path MTU as status information and criteria/constraint in PCEP. A few comments/questions (these are non-blocking to adoption): 1. Shouldn’t the MTU bound use case be an inversion of the current description? Rather than specify a max mtu, wouldn't an operator prefer to find a path that satisfies a minimum MTU to avoid fragmentation? For example, if I have a requirement for X byte MTU along my path, then my bounds should indicate "please find a path that supports at minimum MTU value of X" ? Similar to a bandwidth constraint? This is the paragraph reference: Further, a PCC MAY use the Path MTU metric in a Path Computation Request (PCReq) message to request a path meeting the MTU requirement of the path. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path MTU metric that must not be exceeded for the PCC to consider the computed path as acceptable. The Path MTU metric must be less than or equal to the value specified in the metric-value field. Shuping> You are correct that the PMTU metric is different from other metric types and thus we need to explain that in the document more clearly. We will work on an update for this. 1. Should the term optimize be defined in the below snippet? I assume the goal to find a path providing the largest MTU possible, so recommend some text describing what is the optimization goal when the goal is metric type MTU. A PCC can also use this metric to ask PCE to optimize the path MTU during path computation. In this case, the B bit MUST be cleared. Shuping> The objective of the optimization is to find the path with the largest PMTU. We will further work on the text to be updated in the draft. 1. Glad to see considerations for ietf-pce-multipath in the document. Since multipath document generically handles embedding other objects including METRIC (section 7.1 in draft-ietf-multipath), I would assume this metric would follow suit similar to existing metrics (ex TE-metric). Do the authors have potential other special use cases/needs involving the PMTU metric object per ERO? Shuping> The multipath case will be further developed. 1. In section 3.3 it specifies " A PCC MAY include the path MTU metric as a bound constraint or to indicate optimization criteria (similar to PCReq)." I assume the intention here was to indicate that a PcRpt may carry the MTU metric as a constraint, so probably worth explicitly stating PcRpt may carry it rather than comparing to PcReq. Shuping> In section 3.3 it can be changed to " A PCC MAY include the path MTU metric as a bound constraint or to indicate optimization criteria in PcRpt (similar to PCReq)." 1. The document makes a brief remark on the differentiation for MSD compared to PMTU. While correct, it’s likely worth remarking that for SR-MPLS the type of SIDs pushed onto the path would also have an impact to MTU in the path selection. For example, AdjSIDs being popped as the packet is in transit vs node SIDs remaining constant vs more complexity with BSIDs being used in the transit path could actually cause the packet size to grow while in mid-flight. Was there any consideration into the impact of this for PCE and or guidance for how PCE should be able to handle this ? I don’t have content to suggest but since there’s no discussion SR-MPLS segment type behavior makes me wonder if there might be a scenario or situation gap. Shuping> Thank you for your suggestions. We will work on them and consider where to add the text. Best Regards, Shuping Thanks Andrew From: Pce <pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>> on behalf of Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> Date: Monday, March 28, 2022 at 12:10 PM To: "pce@ietf.org<mailto:pce@ietf.org>" <pce@ietf.org<mailto:pce@ietf.org>> Cc: "draft-li-pce-pcep-p...@ietf.org<mailto:draft-li-pce-pcep-p...@ietf.org>" <draft-li-pce-pcep-p...@ietf.org<mailto:draft-li-pce-pcep-p...@ietf.org>> Subject: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05 Hi WG, This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05. https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/ 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 11th April 2022. Thanks! Dhruv & Julien
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
