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

xiao.min2@zte.com.cn Fri, 13 September 2024 01:34 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 95739C14F689; Thu, 12 Sep 2024 18:34:48 -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 qO-wb6mz-BZa; Thu, 12 Sep 2024 18:34:44 -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 34325C14F5F9; Thu, 12 Sep 2024 18:34:41 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (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 4X4cL66TXrz5B1J5; Fri, 13 Sep 2024 09:34:38 +0800 (CST)
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 mxct.zte.com.cn (FangMail) with ESMTPS id 4X4cKW0l3tz501gH; Fri, 13 Sep 2024 09:34:07 +0800 (CST)
Received: from njy2app03.zte.com.cn ([10.40.13.14]) by mse-fl2.zte.com.cn with SMTP id 48D1XsRY054729; Fri, 13 Sep 2024 09:33:54 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njb2app05[null]) by mapi (Zmail) with MAPI id mid201; Fri, 13 Sep 2024 09:33:55 +0800 (CST)
Date: Fri, 13 Sep 2024 09:33:55 +0800
X-Zmail-TransId: 2afd66e39683ffffffffe8a-03be4
X-Mailer: Zmail v1.0
Message-ID: <20240913093355380iuEkWP_glz5NMlu_tzCkt@zte.com.cn>
In-Reply-To: <MW5PR13MB5485543E52AC9CC71677B8D4D2642@MW5PR13MB5485.namprd13.prod.outlook.com>
References: 20240912093630736metneDzsvPE22OSPn2orh@zte.com.cn,SJ0PR13MB5474B8A3B2FB0304F6042EF2D2642@SJ0PR13MB5474.namprd13.prod.outlook.com,CAEh=tcegLp6rgMfgAXYmOKyQsbA8pEtDr-gPvqpqhUj6JfJRPA@mail.gmail.com,MW5PR13MB5485543E52AC9CC71677B8D4D2642@MW5PR13MB5485.namprd13.prod.outlook.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: james.n.guichard@futurewei.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 48D1XsRY054729
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 66E396AE.002/4X4cL66TXrz5B1J5
Message-ID-Hash: L4VART7L2ZG5WJLCT77GFO7F34J5PUYY
X-Message-ID-Hash: L4VART7L2ZG5WJLCT77GFO7F34J5PUYY
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: zahed.sarker.ietf@gmail.com, 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/pyVoHWa9ow2342ZpOGwDWpGz7r0>
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>

Thank you very much, Jim and Zahed!

I've posted version -18 to address Zahed's comments, as well as incorporating the modified MNA related text. Link as below.
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-inband-pm-encapsulation-18

Best Regards,
Xiao Min

Original


From: JamesGuichard <james.n.guichard@futurewei.com>
To: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>;
Cc: 肖敏10093570;iesg@ietf.org <iesg@ietf.org>;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>;
Date: 2024年09月12日 23:04
Subject: Re: [mpls] Re: Zaheduzzaman Sarker's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)



Thanks, Zahed!
 
Hi Xiao,
 
Please upload a new version with the appropriate text and once Zahed clears his discuss I will move the document forward.
 
Jim
 


From: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
 Date: Thursday, September 12, 2024 at 8:29 AM
 To: James Guichard <james.n.guichard@futurewei.com>
 Cc: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>, iesg@ietf.org <iesg@ietf.org>, 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>
 Subject: Re: [mpls] Re: Zaheduzzaman Sarker's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)



Hi Jim,
 

You are right. I got what I wanted from your response. With that I am happy with the added text and thanks for resolving my discuss. Just let me know when the proposed text lands on the updated draft..I will clear my discuss.


 

//Zahed 



 

On Thu, Sep 12, 2024 at 2:01 PM James Guichard <james.n.guichard@futurewei.com> wrote:



Hi Xiao,
 
As the responsible AD for this document let me chime in here. I believe that Zahed’s DISCUSS is focused on the following text:
 
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.
 
The above text says ‘MUST only be applied to controlled domains’ and Zahed is trying to clarify that the MUST can be honored. I believe that the answer to this is yes as MPLS by design is a ‘fail closed’ protocol and therefore the method described in this document is contained within the boundaries of the network where MPLS is enabled.  I am not sure if any further text is necessary, but I will let Zahed confirm.
 
Thanks!
 
Jim
 
 


From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>
 Date: Wednesday, September 11, 2024 at 9:38 PM
 To: zahed.sarker.ietf@gmail.com <zahed.sarker.ietf@gmail.com>
 Cc: iesg@ietf.org <iesg@ietf.org>, 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>
 Subject: [mpls] Re: Zaheduzzaman Sarker's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)


Hi Zahed,
 
Thank you for the prompt reply.
Please see inline.

Original

From: ZaheduzzamanSarker <zahed.sarker.ietf@gmail.com>



To: 肖敏10093570;



Cc: iesg@ietf.org <iesg@ietf.org>;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>;



Date: 2024年09月05日 19:25



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




 

On Thu, Sep 5, 2024 at 10:35 AM <xiao.min2@zte.com.cn> wrote:


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.







Thanks the text looks good, however, I am not sure if MPLS perfomance can be done in controlled domains or not i.e. what is the controlled domain mean here in this context. I will left that to MPLS expert to comment on. 


[XM-2]>>> I don't see any comments from MPLS expert, so pardon me to chime in. Section 7.1 of RFC9341 provides an explanation on what a controlled domain means, it says "A controlled domain can correspond to a single administrative domain or multiple administrative domains under a defined network management". Considering in Section 8 of this document it says "The method for achieving multi-domain performance measurement with the same Flow-ID label is outside the scope of this document", I think in the context of this document a controlled domain corresponds to a single administrative domain.
 
Cheers,
Xiao Min
 

//Zahed


 
  


 
 
  - 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