Subject: [Last-Call] Opsdir last call review of draft-ietf-teas-gmpls-signaling-smp-10

From: Dan Romascanu via Datatracker <[email-masked]>
Date: Tue, 01 Feb 2022 03:59:59 -0800

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.

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Fri, 18 Feb 2022 11:31:40 +0900 (KST)

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" <[email-masked]>
To:      <[email-masked]>; 
Cc:      <[email-masked]>;   <[email-masked]>;   <[email-masked]>;   <[email-masked]>; 
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

-- 
last-call mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/last-call

---

From: Dan Romascanu <[email-masked]>
Date: Fri, 18 Feb 2022 07:46:24 +0200

Hi Jeong-dong,

Thank you for your response and for addressing the issues that were raised
in my review. The proposed text for the Introduction section addresses my
concerns.

Regards,

Dan

On Fri, Feb 18, 2022 at 4:31 AM Jeong-dong Ryoo <[email-masked]> wrote:

> 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.
>
> Cc:      <[email-masked]>;   <[email-masked]>;   <[email-masked]>;
>  <[email-masked]>;