Mahesh Jethanandani has entered the following ballot position for draft-ietf-pce-segment-routing-ipv6-23: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for working on this document. I am not an expert in PCEP and its related drafts, but as I understand it, this document is defining an extension for SRv6 and not SR-MPLS. Therefore, I am confused by this long paragraph in the Introduction section that delves into how SR-MPLS works. To quote: [RFC8231] specifies extensions to PCEP that allow a stateful PCE to compute and recommend network paths in compliance with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide synchronization of LSP state between a PCC and a PCE or between a pair of PCEs, delegation of LSP control, reporting of LSP state from a PCC to a PCE, controlling the setup and path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions are intended for an operational model in which LSPs are configured on the PCC, and control over them is delegated to the PCE. If there is something this paragraph conveys applies to SRv6, it is not apparent in the next paragraph. In anything, the next paragraph on how this would work in SRv6 was clear in itself, without needing this paragraph. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
