[mpls] Re: Zaheduzzaman Sarker's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)

xiao.min2@zte.com.cn Thu, 05 September 2024 07:35 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4D2C15155A; Thu, 5 Sep 2024 00:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50e7NFB0kCFl; Thu, 5 Sep 2024 00:35:45 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC5B2C14CE4A; Thu, 5 Sep 2024 00:35:40 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4WzrkH31gjz5B1Dp; Thu, 5 Sep 2024 15:35:35 +0800 (CST)
Received: from njy2app02.zte.com.cn ([10.40.13.116]) by mse-fl2.zte.com.cn with SMTP id 4857ZQjk053283; Thu, 5 Sep 2024 15:35:26 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app01[null]) by mapi (Zmail) with MAPI id mid201; Thu, 5 Sep 2024 15:35:28 +0800 (CST)
Date: Thu, 05 Sep 2024 15:35:28 +0800
X-Zmail-TransId: 2af966d95f40ffffffffa19-cde92
X-Mailer: Zmail v1.0
Message-ID: <20240905153528384nAO1OTdDbV9fGLJkTIqkD@zte.com.cn>
In-Reply-To: <172543283680.1580666.3170986618289853050@dt-datatracker-68b7b78cf9-q8rsp>
References: 172543283680.1580666.3170986618289853050@dt-datatracker-68b7b78cf9-q8rsp
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: zahed.sarker.ietf@gmail.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 4857ZQjk053283
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 66D95F47.001/4WzrkH31gjz5B1Dp
Message-ID-Hash: PZ2AUTJE746M5UDPW3S5OBMQX2IWDGFZ
X-Message-ID-Hash: PZ2AUTJE746M5UDPW3S5OBMQX2IWDGFZ
X-MailFrom: xiao.min2@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: iesg@ietf.org, draft-ietf-mpls-inband-pm-encapsulation@ietf.org, mpls-chairs@ietf.org, mpls@ietf.org, tsaad@cisco.com
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Zaheduzzaman Sarker's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/-EWe6bVqBO2xcAq-YbIVM3gpxm8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

Hi Zaheduzzaman,
Thanks for your review and comments.
Please see inline.

Original


From: ZaheduzzamanSarkerviaDatatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>;
Cc: draft-ietf-mpls-inband-pm-encapsulation@ietf.org <draft-ietf-mpls-inband-pm-encapsulation@ietf.org>;mpls-chairs@ietf.org <mpls-chairs@ietf.org>;mpls@ietf.org <mpls@ietf.org>;tsaad@cisco.com <tsaad@cisco.com>;tony.li@tony.li <tony.li@tony.li>;tony.li@tony.li <tony.li@tony.li>;
Date: 2024年09月04日 14:54
Subject: Zaheduzzaman Sarker's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-mpls-inband-pm-encapsulation-15: 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-mpls-inband-pm-encapsulation/
 
 
 
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
 
Thanks for working on this specification.
 
I have noted this specificaiton uses RFC 9341 performance measurement methods.
RFC 9341 says -
 
   "the Alternate-Marking Method MUST only be applied to controlled domains." 
 
Hence, I would like to discuss
 
  - if MPLS performance measurement will be done in "controlled domains" or
  not. If yes, should this specification not discuss and state about
  measurement done in "controlled domains"?
 [XM]>>> Yes, on this point the MPLS performance measurement follows what RFC 9341 says. To make this explicit, I propose to add a new paragraph to the beginning of the Security section.
NEW
As specified in Section 7.1 of RFC9341, for security reasons, the Alternate-Marking Method MUST only be applied to controlled domains. That requirement applies when the MPLS performance measurement with the Alternate-Marking Method is taken into account, which means the MPLS encapsulation and related procedures defined in this document MUST only be applied to controlled domains, otherwise the potential attacks discussed in Section 10 of RFC9341 may be applied to the deployed MPLS networks.

  - current security consideration does not describe the implications if the

  measurement is not done in the controlled domains, should this specification
  not describe those?
 [XM]>>> Please see above. Is the text of the proposed new paragraph applicable?
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
I have not marked any other transport protocol related issues.
 
 Best Regards,
Xiao Min