Roman Danyliw has entered the following ballot position for
draft-ietf-pce-circuit-style-pcep-extensions-14: Discuss

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-circuit-style-pcep-extensions/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 5.2

5.2.  Information and Data Models
   An implementation SHOULD allow an operator to view the PCEP peer
   capability defined in this document.  Section 4.1 and 4.1.1 of
   [RFC9826] should be extended to include that capability for PCEP
   peer.
   Section 4.2 of [RFC9826] module SHOULD be extended to add
   notification for blocked path modification that satisfies specified
   constraints if path modification is blocked using the PATH-
   MODIFICATION TLV.

-- Per “Section 4.1 and 4.1.1 of [RFC9826] should be extended to include that
capability for PCEP peer”, who is this guidance for?  What does it mean to say
that a given section of an RFC “should be extended”?  Is this extended the
model in RFC9826?

-- Per “Section 4.2 of [RFC9826] module SHOULD be extended to add notification
for blocked path modification that satisfies specified constraints if path
modification is blocked using the PATH-MODIFICATION TLV”, same questions. 
Additionally, this text says the "module SHOULD be extended", upper case
"SHOULD", does that mean anything different than the lower case in the previous
sentence?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 5.4
   A PCE implementation SHOULD notify the operator in case of blocked
   path modification for an LSP that no longer satisfies specified
   constraints.  It SHOULD also allow the operator to view LSPs on the
   PCE that does not satisfy specified constraints.

Is there some interoperable way that the operator should be notified?

Is there some interoperable way about how an operator should “view LSPs”?



_______________________________________________
Pce mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to