[mpls] Re: John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)
Stewart Bryant <stewart.bryant@gmail.com> Tue, 10 September 2024 16:31 UTC
Return-Path: <stewart.bryant@gmail.com>
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 <stewart.bryant@gmail.com>
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: <MW5PR13MB5485FB738A4E1D49D160026ED29A2@MW5PR13MB5485.namprd13.prod.outlook.com>
To: James Guichard <james.n.guichard@futurewei.com>
References: <20240909084747863DD6L3jyLtJvvqYF9jzk2r@zte.com.cn,20240910141950285thZInxELPhbnFSBkdgXlH@zte.com.cn,63C1F4CE-3437-4A53-8196-93C00E5FBE6F@tony.li> <202409101437205152g3Mg6rXkxl2HdIohx8JX@zte.com.cn> <EB996189-172B-4E96-A797-542A7AE0622F@gmail.com> <0A606080-BC97-47B7-AD48-779511BC5910@tony.li> <MW5PR13MB5485FB738A4E1D49D160026ED29A2@MW5PR13MB5485.namprd13.prod.outlook.com>
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 <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>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: John Scudder'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/Dx2AhxGzy1kGpg9DscK6DNf9_JA>
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>
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’t 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. From 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’ve 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’t care for. The alternative is that every topic polarizes us, we sit and argue endlessly, and no progress is made. > > T >
- [mpls] John Scudder's Discuss on draft-ietf-mpls-… John Scudder via Datatracker
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… John Scudder
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… BRUNGARD, DEBORAH A
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Greg Mirsky
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… James Guichard
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… James Guichard
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Stewart Bryant
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Joel Halpern
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… James Guichard
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Stewart Bryant
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2