Hi pce-pcep-pmtu draft authors, A few questions/comments:
* Since metric objects in PCEP are often defined in pairs - P2P and P2MP, do we need to define behavior for P2MP in this draft as well (or at least mention that it is out of scope if there is no plan to cover)? * In Section 4.2, it is described that new metric object can be included in PCInitiate and PCUpdate to inform about metric computed, but I guess that it can be included when used as bound as well for PCE initiated LSPs * In Section 4.3.1, multi-SL support is described as TBD - can't we just use per SL metric object as described in "https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-10#name-sr-policy-candidate-path-wi";? + a few minor comments/typos/..., mostly grammar related, which is spotted while reading it: Section 1: Typo: well as Generalzied MPLS (GMPLS) ... A SR path can be derived from -> An SR path can be derived from ... [I-D.peng-spring-pmtu-sr-policy] specifies the link maximum transmission unit (MTU) (specify -> specifies) Section 3: ...link MTU of all the links in a path between a... (on -> in) Section 4.1: Shouldn't this be uppercase MUST? "...for the Path MTU metric that must not be exceeded for the..." "...A path P of an LSP is a list..." ( a LSP -> an LSP) "A PCC can also use this metric to request that the PCE optimize" (ask -> request that the) "The error handling and processing of the METRIC object are as specified in [RFC5440]." (is -> are) Section 4.4: Maybe better to call it backup (same way like for example https://www.ietf.org/archive/id/draft-ietf-pce-multipath-11.html#name-two-primary-paths-protected): "The path MTU metric can be used for both the primary and backup paths" (primary and protection path -> primary and backup paths) Thanks a lot, Samuel
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
