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 002E8C14F6E9; Tue, 10 Sep 2024 09:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 Q0jCAqQnQhki; Tue, 10 Sep 2024 09:31:25 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 47B7BC14F6E4; Tue, 10 Sep 2024 09:31:25 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-5365aa568ceso5637774e87.0; Tue, 10 Sep 2024 09:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725985883; x=1726590683; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=f0eV4hZS7W4E2kfiMxxM4y4NiAJVxWGxC1rzExxNeB4=; b=QSYlmaPv27pR22znVOfmdR5D+5gxVfawrQGa2sRTWy1OegfSVwkDsq7vqqakpOG2N0 bIvr7gsDUCuQHNJw/Wwo70nuTmc1qfUqZVyPmY+TkcWMfcyYzkVPPEqnN4hUo17t+oHr 8psmYpbAnJML/wpMptw4GRFDWU5M/ezlSC337Uvuvoo0VX3YrPCMMNw3bs7CWv5q3B+Q wtfPKg5PWhs1rIzctP31Yzf1A7FkhhNBQxZauyry5m9DynvMEmAm4CsWbnXDYchfEQHB oD1aggRQkXhzWkGecQg8r6eVaCVpDAO+yMqTmGuRhNEg6PZZHroGi05NxU6+Pklz7ww9 DtDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725985883; x=1726590683; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=f0eV4hZS7W4E2kfiMxxM4y4NiAJVxWGxC1rzExxNeB4=; b=ZU1WJnlmGDA4ztFP2qYAjLqhcE6XPJMaZKF98zC138gcwjmBtQ3KFYtNaIHFl+Ot3s bMqIUs9rp1EVA+lPb0gIVP18C4B5FwkZa9UMy1oIMJmQnD2OkHNwyZX79Se3MAZyhKWK fDflolOEEQkFxSxqUSs9cgxXQM73U3csyDymfMIuSFNxcxVGJ6TCadD81rVeIpSrkOr7 Se3OZNf9H2ETzUYh/XUkxBccCpuMBR7YvkpIYioAM6r3dEEL9v1TLsgTKdzuI3F/2TT4 YDXZNULm+SrKYnmRJXHKgqAkBPc9Lx4Zmu7Wf9AyXS9kHj1OGzZoWfPSFil59bVaM6q1 Btbw== X-Forwarded-Encrypted: i=1; AJvYcCU1mkfQuEdHAOJTK/fUHK1UN9x0T+iXbowkLfKerNt51qoiT7Uf+CTmPcLBCi1Oen7xfqtGPQ==@ietf.org, AJvYcCUU+Jmjiq9uO5CR91e1DmgzMQr/zTvwCz3Zq7hQEHBYV/ts8fCAyEtFATBndVCTDyKpvXC2Z75dZV4rZvE=@ietf.org, AJvYcCUcLgQl+sCUQ2BhZCy72XtkzVgFPojW3hdEYV4qtP+yiSN6wHjsjiybjUlts8m9aZMgZwPhcA==@ietf.org, AJvYcCWvEyfge7dErJgjhaGBJj8LPLhEKE81q7Ckoa5NSgPJ+UlBmKfZ/aQZp8khjq5A+WLOUbuBgJAU4PCBGMPDgA2P44lgVyDNUoifknYfc6U5i03sOyGTyhw=@ietf.org X-Gm-Message-State: AOJu0YwPHcUcDpdLae2oa4fcPRZTuC9XEWjU8z6EU1c3I+7C7gRjMUuW 79MoSJWevdMqV9CC//qDS51RYKxB4nJ5Nsi1Wzry8VRTkK6egEot X-Google-Smtp-Source: AGHT+IGthVRJOUBriBSSPA33mGEjNJKor+IIgztCN1HyPiTSjwU9RpsurxSz9+n/4zPGE2PJqU8aYg== X-Received: by 2002:a05:6512:2215:b0:530:ad8d:dcdb with SMTP id 2adb3069b0e04-536587ae7aemr15352446e87.19.1725985882344; Tue, 10 Sep 2024 09:31:22 -0700 (PDT) Received: from smtpclient.apple ([148.252.147.35]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8d25835d31sm503921266b.10.2024.09.10.09.31.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Sep 2024 09:31:21 -0700 (PDT) From: Stewart Bryant Message-Id: <58CB27C6-9D7A-4111-837B-A81B6B5F49CE@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_83FB500E-80E5-4F1D-97B0-EBA41DFC717C" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Date: Tue, 10 Sep 2024 17:31:10 +0100 In-Reply-To: To: James Guichard References: <20240909084747863DD6L3jyLtJvvqYF9jzk2r@zte.com.cn,20240910141950285thZInxELPhbnFSBkdgXlH@zte.com.cn,63C1F4CE-3437-4A53-8196-93C00E5FBE6F@tony.li> <202409101437205152g3Mg6rXkxl2HdIohx8JX@zte.com.cn> <0A606080-BC97-47B7-AD48-779511BC5910@tony.li> X-Mailer: Apple Mail (2.3776.700.51) Message-ID-Hash: XVPZ3FWYNLHJXKESDVCH5VNKOFZQAJLH X-Message-ID-Hash: XVPZ3FWYNLHJXKESDVCH5VNKOFZQAJLH X-MailFrom: stewart.bryant@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: draft-ietf-mpls-inband-pm-encapsulation , "tsaad@cisco.com" , mpls , mpls-chairs , The IESG X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_John_Scudder=27s_Discuss_on_draft-ietf-mpls-inban?= =?utf-8?q?d-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: --Apple-Mail=_83FB500E-80E5-4F1D-97B0-EBA41DFC717C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jim Since MNA Header - the protocol definition - has not left the WG yet the = text should probably read Note that in parallel to the work of this document, there is ongoing = work on MPLS Network Actions (MNA) [RFC9613]. It is expected that the = MPLS performance measurement with the Alternate-Marking will also be = achievable by using MNA encapsulation. In addition, MNA is expected = provide a broader use case applicability. That means the MNA = encapsulation is expected to provide a more advanced solution, when = published as an RFC and it is anticipated that this document will be = made Historic. I don=E2=80=99t think we should make definite statements prior to the = fact, and I remain of the view that if people want to continue to use = the approach described here we should permit them to do so and not pull = the rug from under their feet. Stewart =20 > On 10 Sep 2024, at 15:19, James Guichard = wrote: >=20 > Dear authors/WG/chairs, > =20 > As the responsible AD I would like to clarify that aside from an = unrelated DISCUSS during IESG evaluation, this document has been = approved by the IESG for publication. While the text in question is = somewhat unusual, it is my understanding that it was discussed at length = in the WG, and a fair compromise was reached by including text that = makes the intent of the WG clear with regards to publication of the = document. =46rom a procedural standpoint the MNA solution document must = make its way through the standard publication process, and if it is = eventually published as an RFC then this document will be moved to = Historic. =20 > =20 > I would like to suggest a slight change to the text as follows: > =20 > Note that in parallel to the work of this document, there is ongoing = work on MPLS Network Actions (MNA) [RFC9613]. The MPLS performance = measurement with the Alternate-Marking method can also be achieved by = MNA encapsulation. In addition, MNA will provide a broader use case = applicability. That means the MNA encapsulation is expected to provide a = more advanced solution, when published as an RFC and it is agreed that = this document will be made Historic at that time. > =20 > Thanks! > =20 > Jim > From: Tony Li on behalf of Tony Li = > Date: Tuesday, September 10, 2024 at 9:44 AM > To: Stewart Bryant > Cc: xiao. min2 , = draft-ietf-mpls-inband-pm-encapsulation = , tsaad@cisco.com = , mpls , mpls-chairs = , The IESG > Subject: Re: [mpls] John Scudder's Discuss on = draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT) >=20 >=20 > Hi Stewart, >=20 >=20 > > I am not sure I understand the need to say anything about = anticipated obsolescence of the protocol. > >=20 > > Once it is released in the wild it will have a life of its own = determined by the needs of the operators. If they want to keep using it = they will and we should not prevent them. As a method it is harmless and = by using an ESPL it does not take any critical resources. > >=20 > > It is very rare that we actively obsolete anything like this unless = it is actually harmful, or blocks some other more valuable method, = neither of which apply here. > >=20 > > So why are we actively promoting the obsolescence of this technique = rather than letting the market decide which is our normal approach? >=20 >=20 > Because the WG is potentially generating two approaches to doing the = same function in a relatively short time. Many concerns were expressed = about the confusion that it would create. Some wanted this document to = not be published. The authors of this draft very much wanted it to be = published (as PS) because of their existing deployments. This compromise = was the way of respecting all parties. >=20 > I=E2=80=99ve heard compromises described as deals where everyone walks = away unhappy. If we want the IETF to be a place where compromise and = statesmanship are the norm, then we have to accept the fact that = compromise will lead to outcomes that we don=E2=80=99t care for. The = alternative is that every topic polarizes us, we sit and argue = endlessly, and no progress is made. >=20 > T >=20 --Apple-Mail=_83FB500E-80E5-4F1D-97B0-EBA41DFC717C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Jim

Since MNA Header - the protocol definition = - has not left the WG yet the text should probably = read

Note that in = parallel to the work of this document, there is ongoing work on MPLS = Network Actions (MNA) [RFC9613]. It is expected that the MPLS = performance measurement with the Alternate-Marking will also be = achievable by using MNA encapsulation. In addition, MNA is expected =  provide a broader use case applicability. That means the MNA = encapsulation is expected to provide a more = advanced solution, when published as an RFC and it is anticipated that = this document will be made Historic.

I don=E2=80=99t think we should make definite statements prior to the fact, and = I remain of the view that if people want to continue to use the approach = described here we should permit them to do so and not pull the rug from = under their feet.

Stewart
 


On 10 Sep 2024, at 15:19, James Guichard = <james.n.guichard@futurewei.com> wrote:

Dear = authors/WG/chairs,
 
As the responsible AD I = would like to clarify that aside from an unrelated DISCUSS during IESG = evaluation, this document has been approved by the IESG for publication. = While the text in question is somewhat unusual, it is my understanding = that it was discussed at length in the WG, and a fair compromise was = reached by including text that makes the intent of the WG clear with = regards to publication of the document. =46rom a procedural standpoint = the MNA solution document must make its way through the standard = publication process, and if it is eventually published as an RFC then = this document will be moved to Historic. =  
 
I would like to suggest a slight change to = the text as follows:
 
Note that in parallel = to the work of this document, there is ongoing work on MPLS Network = Actions (MNA) [RFC9613]. The MPLS performance measurement with the = Alternate-Marking method can also be achieved by MNA encapsulation. In = addition, MNA will provide a broader use case applicability. That means = the MNA encapsulation is expected to provide a more advanced = solution, when published as an RFC and it is agreed that this document = will be made Historic at that time.
 
Thanks!
 
Jim

From: Tony Li <tony1athome@gmail.com> on behalf of Tony Li = <tony.li@tony.li>
Date: Tuesday, September 10, = 2024 at 9:44 AM
To: Stewart Bryant = <stewart.bryant@gmail.com>
Cc: xiao. min2 = <xiao.min2@zte.com.cn>, draft-ietf-mpls-inband-pm-encapsulation = <draft-ietf-mpls-inband-pm-encapsulation@ietf.org>, = tsaad@cisco.com <tsaad@cisco.com>, mpls <mpls@ietf.org>, = mpls-chairs <mpls-chairs@ietf.org>, The IESG = <iesg@ietf.org>
Subject: Re: [mpls] John = Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with = DISCUSS and COMMENT)


Hi = Stewart,


> I am not sure I understand the need to say = anything about anticipated obsolescence of the protocol.
> 
> Once it is = released in the wild it will have a life of its own determined by the = needs of the operators. If they want to keep using it they will and we = should not prevent them. As a method it is harmless and by using an ESPL = it does not take any critical resources.
> 
> It is very rare = that we actively obsolete anything like this unless it is actually = harmful, or blocks some other more valuable method, neither of which = apply here.
> 
> So why are we = actively promoting the obsolescence of this technique rather than = letting the market decide which is our normal = approach?


Because the WG is potentially generating two = approaches to doing the same function in a relatively short time. Many = concerns were expressed about the confusion that it would create. Some = wanted this document to not be published. The authors of this draft very = much wanted it to be published (as PS) because of their existing = deployments. This compromise was the way of respecting all = parties.

I=E2=80=99ve heard compromises described as deals where = everyone walks away unhappy.  If we want the IETF to be a place = where compromise and statesmanship are the norm, then we have to accept = the fact that compromise will lead to outcomes that we don=E2=80=99t = care for. The alternative is that every topic polarizes us, we sit and = argue endlessly, and no progress is = made.

T

=

= --Apple-Mail=_83FB500E-80E5-4F1D-97B0-EBA41DFC717C--