Dear Dan, Thank you for your review of this document. In an effort to address the issue you raised, the authors of this document prepared a new paragraph to add in the Introduction section as follows: [RFC8776] defines a collection of common YANG data types for Traffic Engineering (TE) configuration and state capabilities. It defines several identities for LSP protection types. As this document introduces a new LSP Protection Type, [RFC8776] is expected to be updated to support the SMP specified in this document. [draft-ietf-teas-yang-te] defines a YANG data model for the provisioning and management of TE tunnels, LSPs, and interfaces. It includes some protection and restoration data nodes relevant to this document. Management aspects of the SMP are outside the scope of this document, and they are expected to be addressed by other documents. Please, let us know if this is not sufficient to address your concerns. Best regards, Jeong-dong (on behalf of the co-authors) -----Original Message----- From: "Dan Romascanu via Datatracker" <noreply@xxxxxxxx> To: <ops-dir@xxxxxxxx>; Cc: <last-call@xxxxxxxx>; <dromasca@xxxxxxxxx>; <teas@xxxxxxxx>; <draft-ietf-teas-gmpls-signaling-smp.all@xxxxxxxx>; Sent: 2022-02-01 (화) 21:00:54 (UTC+09:00) Subject: [Last-Call] Opsdir last call review of draft-ietf-teas-gmpls-signaling-smp-10 Reviewer: Dan Romascanu Review result: Not Ready This document updates RFC 4872 and RFC 4873 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the Shared Mesh Protection (SMP) mechanism defined by ITU-T Recommendation G.808.3. It describes in details the operation of SMP with GMPLS Signaling Extension, the GMPLS Signaling Extension for SMP, and the updates to PROTECTION Object. I believe that the document is useful for operators runing GMPLS and SMP. The signaling aspects seem to be well defined. However, the document misses completly any operational and manageability considerations. Are they covered by other documents? Are updates required for any GMPLS management RFCs? Are there any configuration or alarms aspects that the operators should be aware about? What is the operational impact of upgrading networks to run SMP? These are parts of the questions I would expect to be addressed, or at least some pointers provided to existing documents (IETF, ITU-T) or future work. I would suggest that these issues be addressed before the document is approved for publication. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
