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

[James Guichard <[e-mail]>]

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 <[e-mail]>
Date: Thursday, September 12, 2024 at 8:29 AM
To: James Guichard <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, September 11, 2024 at 9:38 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>>
To: 肖敏10093570;
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;
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 <[e-mail]<mailto:[e-mail]>> wrote:

Hi Zaheduzzaman,

Thanks for your review and comments.

Please see inline.
Original
From: ZaheduzzamanSarkerviaDatatracker <[e-mail]<mailto:[e-mail]>>
To: The IESG <[e-mail]<mailto:[e-mail]>>;
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;
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