Return-Path: 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 3A8DFC15106E; Thu, 12 Sep 2024 05:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.104 X-Spam-Level: X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gW3wDFLaynrc; Thu, 12 Sep 2024 05:29:52 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A87C14CF15; Thu, 12 Sep 2024 05:29:52 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2d8b68bddeaso725127a91.1; Thu, 12 Sep 2024 05:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726144192; x=1726748992; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jwxI9EnJgGoP4s+31meoihJ+EVY7/yMLlJQb0Mbm8nU=; b=CX8ej2ny5qmU4e1GqBjZAWFHIaM5M9APSHZ8yQq9f3COe+cIlsSARFRWhKWWFjTn0d QeIm4SNAncv3GNklHJSIy9/mQHqVCdx9uuutLZ8+WpaQFpIHdEt0I9okZcRFF3T57FCE ALuA4FpR5K+T11E4wxnuto/68JVxvm093xpzJldqmggtJR6r+MLbNkoC2z0zFh7bIefm XYjMs5TRtrGDCIIfqeJxGjJ2ur5QE/FugEqZS0PV0tdg4PX5j3MBelIyhFaY3C5vkqNK BVetPESs5Sd1hu9Lr034I8hUx1A4U60V2L6bRJlv7vQcpYKvw4NpXhx/ftdvCfLOIH0E AsbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726144192; x=1726748992; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jwxI9EnJgGoP4s+31meoihJ+EVY7/yMLlJQb0Mbm8nU=; b=kFABK9mtGK8hbxjHuuFLWg7nyn5GBCm0DG/Zt14i4tL+brUcZTUdnis/7EBbJmi1PE Buo52qO658/P6Ra/4rnvRIJjQpsK6ZAQeljt76YxSaa0I+5O8K73dKSoB+TIwas5yfSq 3UmAl0qmOk53uOse9LR03uvenTlw55dj1x1FfUA9fAO0FcrTrkGG5GDJUL+xBr7G6Cqh nAxiwhweu8lHRclneMhxeyJa+8mjJKPyjCup/CNZ5mqYiZ5ipF6LiXsdtNAzDSRhtYZC Se6m+WaeLghTQm9LlqF5m4Qnwqu31opwGZ9fxvkjIQL4DUTfeeqB9D/DU7MfyOAQHpAC RAvQ== X-Forwarded-Encrypted: i=1; AJvYcCU3USLJ05IRcsDnU+QxwXkMjdkx3ytllB3u87epvb6dn6K9qLIkLArlheu2qpX4U+zPqBr7oQ==@ietf.org, AJvYcCULReRF+EguZKYxHwyhNqPy1KrVOF1r+OjStqFUwdOY3FjO2ypRSfC6c3Edo2gPJcAfIPhIOA==@ietf.org, AJvYcCVZ8ttw2HmyULH2BfDS0VlRdDuwYsDpw/4wemnKpJ6qLkNGf7es8bS5agCLONY+td8PXNtMZywbZdFz3g4bTEuInA4z8CyG4jueVtwiQAyDQdLvueys09A=@ietf.org, AJvYcCWx/qDUdT+ul/5HUeh/OAg+tvqG1UUfRLKQO8+pxEcXHPa+/ullmtAIK4Pg/bLogBuSf/SFS+NjV4y/uYA=@ietf.org X-Gm-Message-State: AOJu0Yxi1I1T0cgrVVufxVNy9UGXrpBjYMNaKQ2bpDN4RNsg+g1rPGMv nC8p82l2L40VW0siCdcoFZEcG0NZ01V5/+A+gnQ5trVe4JLY9h1eF7tUFUExWsWd3QC+cCXaD1U NmfFuQI6p0UISkYBgBy4wodng0JU= X-Google-Smtp-Source: AGHT+IFxrUwrSJR6EywXIideFWo0RdJASoBoY3vOPcGV+JPjdDT1k0qdq3jWDc7IsS/KiCLqE1tI05PxRdi2AXjQj6E= X-Received: by 2002:a17:90a:4b4a:b0:2d3:df93:1e5f with SMTP id 98e67ed59e1d1-2db9ff7c014mr2889515a91.6.1726144191784; Thu, 12 Sep 2024 05:29:51 -0700 (PDT) MIME-Version: 1.0 References: <20240912093630736metneDzsvPE22OSPn2orh@zte.com.cn> In-Reply-To: From: Zaheduzzaman Sarker Date: Thu, 12 Sep 2024 14:29:41 +0200 Message-ID: To: James Guichard Content-Type: multipart/alternative; boundary="00000000000061eed80621eb4329" Message-ID-Hash: VGYUOGZR4E6H4IBSEWITZLB7PT4RL5XK X-Message-ID-Hash: VGYUOGZR4E6H4IBSEWITZLB7PT4RL5XK X-MailFrom: zahed.sarker.ietf@gmail.com 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: =?utf-8?q?=5Bmpls=5D_Re=3A_Zaheduzzaman_Sarker=27s_Discuss_on_draft-ietf-mpl?= =?utf-8?q?s-inband-pm-encapsulation-15=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: Multi-Protocol Label Switching WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000061eed80621eb4329 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM 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=E2=80=99s 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 b= e > 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 =E2=80=98MUST only be applied to controlled domains= =E2=80=99 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 =E2=80=98fail closed=E2=80= =99 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 > *Date: *Wednesday, September 11, 2024 at 9:38 PM > *To: *zahed.sarker.ietf@gmail.com > *Cc: *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 , 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 > > *To: *=E8=82=96=E6=95=8F10093570; > > *Cc: *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 ;tsaad@cisco.com < > tsaad@cisco.com>;tony.li@tony.li ; > > *Date: *2024=E5=B9=B409=E6=9C=8805=E6=97=A5 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=E2=80=AFAM wrote: > > Hi Zaheduzzaman, > > > Thanks for your review and comments. > > Please see inline. > > Original > > *From: *ZaheduzzamanSarkerviaDatatracker > > *To: *The IESG ; > > *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 ;tsaad@cisco.com < > tsaad@cisco.com>;tony.li@tony.li ;tony.li@tony.li < > tony.li@tony.li>; > > *Date: *2024=E5=B9=B409=E6=9C=8804=E6=97=A5 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-positio= ns/ > > 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 met= hods. > RFC 9341 says - > > "the Alternate-Marking Method MUST only be applied to controlled domai= ns." > > > 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 b= e > 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 chim= e > 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 specific= ation > 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 > > > > > --00000000000061eed80621eb4329 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim,

You are right. I got what I wan= ted 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.

//Zah= ed=C2=A0

On Thu, Sep 12, 2024 at 2:01=E2=80=AFPM James Guichard &l= t;james.n.guichard@future= wei.com> wrote:

Hi Xiao,

=C2=A0<= /span>

As the responsible AD= for this document let me chime in here. I believe that Zahed=E2=80=99s DIS= CUSS is focused on the following text:

=C2=A0<= /span>

As specified in Section 7.1 of RFC9341, for security reasons, the Al= ternate-Marking Method MUST only be applied to controlled domains. That req= uirement 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 docume= nt MUST only be applied to controlled domains, otherwise the potential atta= cks discussed in Section 10 of RFC9341 may be applied to the deployed MPLS networks.

=C2=A0<= /span>

The above text says = =E2=80=98MUST only be applied to controlled domains=E2=80=99 and Zahed is t= rying to clarify that the MUST can be honored. I believe that the answer to= this is yes as MPLS by design is a =E2=80=98fail closed=E2=80=99 protocol and therefore the method described in this document is contained within th= e boundaries of the network where MPLS is enabled.=C2=A0 I am not sure if a= ny further text is necessary, but I will let Zahed confirm.

=C2=A0<= /span>

Thanks!=

=C2=A0<= /span>

Jim

=C2=A0<= /span>

=C2=A0<= /span>

Hi Zahed,

=C2=A0

Thank you for the prompt reply.

Please see inline.

Original

From:=C2=A0ZaheduzzamanSarker <zahed.sarker.ietf@gmail.com>

To:=C2=A0=E8=82=96=E6=95=8F10093570;

Date:=C2=A02024=E5=B9=B409= =E6=9C= =8805=E6=97=A5 19:25

Subject:=C2=A0Re: Zahedu= zzaman Sarker's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: = (with DISCUSS and COMMENT)

=C2=A0

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

Hi=C2=A0Zaheduzzaman,


Thanks for your review and comments.

Please see inline.

Original

Zaheduzzaman=C2=A0Sarker=C2=A0has=C2=A0entered=C2=A0= the=C2=A0following=C2=A0ballot=C2=A0position=C2=A0for
draft-ietf-mpls-inband-pm-encapsulation-15:=C2=A0Discuss

When=C2=A0responding,=C2=A0please=C2=A0keep=C2=A0the=C2=A0subject=C2=A0line= =C2=A0intact=C2=A0and=C2=A0reply=C2=A0to=C2=A0all
email=C2=A0addresses=C2=A0included=C2=A0in=C2=A0the=C2=A0To=C2=A0and=C2=A0C= C=C2=A0lines.=C2=A0(Feel=C2=A0free=C2=A0to=C2=A0cut=C2=A0this
introductory=C2=A0paragraph,=C2=A0however.)


Please=C2=A0refer=C2=A0to=C2=A0https://www.= ietf.org/about/groups/iesg/statements/handling-ballot-positions/=C2=A0
for=C2=A0more=C2=A0information=C2=A0about=C2=A0how=C2=A0to=C2=A0handle=C2= =A0DISCUSS=C2=A0and=C2=A0COMMENT=C2=A0positions.


The=C2=A0document,=C2=A0along=C2=A0with=C2=A0other=C2=A0ballot=C2=A0positio= ns,=C2=A0can=C2=A0be=C2=A0found=C2=A0here:
https://datatracker.ietf.org/doc/draft-ietf-mp= ls-inband-pm-encapsulation/



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

Thanks=C2=A0for=C2=A0working=C2=A0on=C2=A0this=C2=A0specification.

I=C2=A0have=C2=A0noted=C2=A0this=C2=A0specificaiton=C2=A0uses=C2=A0RFC=C2= =A09341=C2=A0performance=C2=A0measurement=C2=A0methods.
RFC=C2=A09341=C2=A0says=C2=A0-

=C2=A0=C2=A0=C2=A0"the=C2=A0Alternate-Marking=C2=A0Method=C2=A0MUST=C2= =A0only=C2=A0be=C2=A0applied=C2=A0to=C2=A0controlled=C2=A0domains."
Hence,=C2=A0I=C2=A0would=C2=A0like=C2=A0to=C2=A0discuss

=C2=A0=C2=A0-=C2=A0if=C2=A0MPLS=C2=A0performance=C2=A0measurement=C2=A0will= =C2=A0be=C2=A0done=C2=A0in=C2=A0"controlled=C2=A0domains"=C2=A0or=
=C2=A0=C2=A0not.=C2=A0If=C2=A0yes,=C2=A0should=C2=A0this=C2=A0specification= =C2=A0not=C2=A0discuss=C2=A0and=C2=A0state=C2=A0about
=C2=A0=C2=A0measurement=C2=A0done=C2=A0in=C2=A0"controlled=C2=A0domain= s"?
[XM]>>> Yes, on this point the MPLS performance measurement follow= s what RFC 9341 says. To make this explicit, I propose to add a new paragra= ph to the beginning of the Security section.

NEW

As specified in Section 7.1 of RFC9341, for security reasons, the Altern= ate-Marking Method MUST only be applied to controlled domains. That require= ment applies when the MPLS performance measurement with the Alternate-Marki= ng 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 potentia= l 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 i= f 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 expe= rt to comment on.=C2=A0

[XM-2]>>> I don't see any comments from MPLS expert, so par= don 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 do= mains under a defined network management". Considering in Secti= on 8 of this document it says "The method for achieving multi-domain p= erformance 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.

=C2=A0

Cheers,

Xiao Min

=C2=A0

//Zahed



=C2=A0

=C2=A0

=C2=A0

=C2=A0=C2=A0-=C2=A0current=C2=A0security=C2=A0consideration=C2=A0does=C2= =A0not=C2=A0describe=C2=A0the=C2=A0implications=C2=A0if=C2=A0the

=C2=A0=C2=A0measurement= =C2=A0is=C2=A0not=C2=A0done=C2=A0in=C2=A0the=C2=A0controlled=C2=A0domains,= =C2=A0should=C2=A0this=C2=A0specification
=C2=A0=C2=A0not=C2=A0describe=C2=A0those?
[XM]>>> Please see above. Is the text of the proposed new paragrap= h applicable?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I=C2=A0have=C2=A0not=C2=A0marked=C2=A0any=C2=A0other=C2=A0transport=C2=A0pr= otocol=C2=A0related=C2=A0issues.

Best Regards,

Xiao Min

=C2=A0

=C2=A0

--00000000000061eed80621eb4329--