Hi Benjamin, This has been added in -15 version.
Thanks! Dhruv On Sat, Oct 19, 2019 at 9:32 AM Benjamin Kaduk via Datatracker <[email protected]> wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-pce-stateful-hpce-14: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for addressing my Discuss point! > > I would consider including the conclusion from our discussion about what > would happen if a PCEP speaker does not support stateful H-PCE but the peer > assumes it does, perhaps in an operational considerations section, but this > does > not rise to a Discuss-level point. For convenience, this was discussed as: > > % I further did a mental exercise for PCC -> C-PCE -> P-PCE and assumed > % all support stateful and H-PCE extension but what happens when any > % PCEP speaker does not support stateful H-PCE but the peer assumes that > % it does. On further PCEP message exchange, the messages may not get > % further propagated and thus at worse would not lead to the stateful > % H-PCE based 'parent' control of the LSP. This is something any peer > % should be prepared for anyways. > > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
