[Teas] Robert Wilton's Discuss on draft-ietf-teas-gmpls-signaling-smp-11: (with DISCUSS)

Robert Wilton via Datatracker <noreply@ietf.org> Thu, 07 April 2022 11:43 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 188003A1811; Thu, 7 Apr 2022 04:43:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-teas-gmpls-signaling-smp@ietf.org, teas-chairs@ietf.org, teas@ietf.org, vbeeram@juniper.net, vbeeram@juniper.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <164933181107.6161.4337041650776377766@ietfa.amsl.com>
Date: Thu, 07 Apr 2022 04:43:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/V3JuPc-o1IQGAbF6RnFucNcf2mI>
Subject: [Teas] Robert Wilton's Discuss on draft-ietf-teas-gmpls-signaling-smp-11: (with DISCUSS)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2022 11:43:31 -0000

Robert Wilton has entered the following ballot position for
draft-ietf-teas-gmpls-signaling-smp-11: 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-teas-gmpls-signaling-smp/



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

Thanks for this document, and sorry for the late discuss, which should
hopefully be trivial to fix.

   Notification (N): 1 bit

      When set to 1, this bit indicates that the control plane message
      exchange is only used for notification during protection
      switching.  When set to 0 (default), it indicates that the control
      plane message exchanges are used for protection-switching
      purposes.  The N bit is only applicable when the LSP Protection
      Type Flag is set to 0x04 (1:N Protection with Extra- Traffic),
      0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional
      Protection), or 0x20 (Shared Mesh Protection).  If 0x20 (SMP), the
      N bit MUST be set to 1.  The N bit MUST be set to 0 in any other
      case.

I think that the way that this RFC4872 text has been updated makes this text
unclear/ambiguous.

Specifically, I think that somebody could reasonably interpret this as saying
that the N bit is set to 1 for SMP, and otherwise it must always be set to 0,
but I don't think that is the intention.  So please can this be clarified.

One fix could be to swap the order of the last 2 sentences.  E.g.,

      or 0x20 (Shared Mesh Protection).  The N bit MUST
      be set to 0 in any other case. If 0x20 (SMP), the
      N bit MUST be set to 1.

Alternatively, I think that you could possibly just remove the "If 0x20 (SMP),
the N bit MUST be set to 1." and instead rely on the text in 5.2/5.3, (perhaps
strengthening with RFC 2119 language if required).

Regards,
Rob