Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

["Stone, Andrew (Nokia - CA/Ottawa)" <[e-mail]>]

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.



  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.



  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?


  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.



  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.




Thanks
Andrew


From: Pce <[e-mail]> on behalf of Dhruv Dhody <[e-mail]>
Date: Monday, March 28, 2022 at 12:10 PM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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