Re: [mpls] Formal poll to abandon draft-ietf-mpls-sfl-control

Adrian Farrel <adrian@olddog.co.uk> Thu, 14 March 2024 08:24 UTC

Return-Path: <adrian@olddog.co.uk>
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 16C0DC14CE38; Thu, 14 Mar 2024 01:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.005
X-Spam-Level:
X-Spam-Status: No, score=-2.005 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, 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=olddog.co.uk
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 1qhkcVY70UoB; Thu, 14 Mar 2024 01:24:10 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05292C14F5ED; Thu, 14 Mar 2024 01:24:02 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 42E8NxQx005458; Thu, 14 Mar 2024 08:23:59 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C05B94604F; Thu, 14 Mar 2024 08:23:59 +0000 (GMT)
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B44454604D; Thu, 14 Mar 2024 08:23:59 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS; Thu, 14 Mar 2024 08:23:59 +0000 (GMT)
Received: from ioxnode1.iomartmail.com (ioxnode1.iomartmail.com [10.12.10.68]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 42E8NxxK007322 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2024 08:23:59 GMT
Date: Thu, 14 Mar 2024 08:23:59 +0000
From: Adrian Farrel <adrian@olddog.co.uk>
To: loa@pi.nu, Stewart Bryant <stewart.bryant@gmail.com>
Cc: draft-ietf-mpls-sfl-control.all@ietf.org, mpls <mpls@ietf.org>
Message-ID: <2062351394.549886.1710404639404@www.getmymail.co.uk>
In-Reply-To: <b2ba88801ed81915150054ccd7f85238.squirrel@pi.nu>
References: <071d01da749b$af812400$0e836c00$@olddog.co.uk> <14065d473d44f04a4efaecebb090c277.squirrel@pi.nu> <DE2A0929-3FB5-4164-B3D0-FD43715DD5BB@gmail.com> <b2ba88801ed81915150054ccd7f85238.squirrel@pi.nu>
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.6-Rev56
X-Originating-IP: 185.69.145.10
X-Originating-Client: open-xchange-appsuite
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=date :from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding; s= 20221128; bh=EsXz9StNsmjv+BLaIR5HormqspnaR0PKqU7r5G1rY18=; b=vZb yX3S5qD3GjoGS97LimLsfqr+t8Tvy0J9Rv7uPbingPAMx05HaDInBPUlc0SrVSS5 E1dX0wVsapXJv8houmpIm1mgn1SU4FZ/uaW1TvNJ4HmvKU2OvsdYYRUmU9jP8f4v cLq4RpuPxCDXFBu1L6s1bQtBtZnfdfEh7bUEqs3MhRnSCUsy9vsrXvDdFBkicYKx Ov5jp91DvJSlgRnY9+lRapwzjTfIAx4r+oa6zN5xTz0xNJCQjYusJbtc0+Z6Dl2e 6zGdY8RW3jo7hg48BLYiwChsZjh6PMzLp/9tBfbazV4rNEW0gH9JpLWUcFgPLHqT o6ykxKPzZXrmkHZHO/A==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28250.006
X-TM-AS-Result: No--22.399-10.0-31-10
X-imss-scan-details: No--22.399-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28250.006
X-TMASE-Result: 10--22.398900-10.000000
X-TMASE-MatchedRID: EMyCvCfVN1GnvGCyBToTI8G0UNgaZpYqnSd2cRY8xQNWcVQdwdqmz7pn yE1R12cEg17RohRp8KmlenoRVYEMHrhPu4tF1R7BUgKYbZFF6GhPnKxAOPp4WTBz1OEwfepXOXB 2cqV0mCKVr8ccfGR5UufflH0KXlMUEb0RuLqy8KELwUwfdPoXvqPLTdfaE15XzLaLRraReVYps6 YYXoyrREcGzPyxaurXzUjBsJbi2RjOWGE/gzv0iCIuZ/6CFMb/SOZtBHQ3LLx7fBdO8ExSLpA4m k9O195DF40HISqSK6oLPoQLNvO6e3ZSumiWd5pPYy6AtAy7YZfoqNj4K1y7OFBlq5zqMfbIh4xj UbXh7HQUFqZZhkhO8YW6TRYv6epu+f+iblcTrL8apIb9znReA+YMKpv6oSrJEd+K6O5Nt52e2Fo VUbGcLpz/qDOB4g4a9TL8C+mi4sKSag5+i6uYdOJ28KqpjndpAWQaZTMSP87LN5nQQXYmEuzHNV saiyNEVUrCQFOwusCFRpKOWMHSlglwXR3PN2FZBxsweNg3EaGFkCkkB0UMNpsoi2XrUn/JyeMtM D9QOgBKWdTfwsJjy+hidBD6VjbxlExlQIQeRG0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/jXbBmX-C4Ht_k2IkuDqOUi7FZ4k>
Subject: Re: [mpls] Formal poll to abandon draft-ietf-mpls-sfl-control
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2024 08:24:15 -0000

Hi,
 
I believe that if we were to poll the WG for adoption now, it would fail. There are, as I see it, two people willing to review the work (you and Stewart) but no one who will edit and no one who wants the solution for implementation or deployment.
 
For me, that means that this should not be a working group document. It should drop back to individual, anf if someone gets excited in the future, they can pick it up and ask for readoption.
 
This keeps it very clear to the whole community what the status is.
 
A
On 14/03/2024 05:22 CET loa@pi.nu wrote:
 
 
Adrian,
 
I understand why we will have pull the draft back from the IESG, but
I wonder why it is necessary to kick it out of the WG, why not just let
it expire as a wg draft and have sit there if we find people that want
to work on it?
 
/Loa
 
 
I will be sad as well, but no one has expressed any interest in the
control plane work only in unblocking the other SFL drafts.
Interestingly the last time this was on the MPLS agenda people asked for
control planes for LDP and RSVP-TE, but no one offered to so any work on
this.
In the intervening years SDN has become more prevalent and I suggest that
anyone wanting to deploy a facility that this simple control plane would
address would probably use SDN to manage the SFLs.
If there is someone that wants to put this in a network and there is at
least one other person interested in working through how it works in
detail then I would be prepared to take this to completion, but in the
absence of both such commitments I think it should go back to the WG and
presumably eventually expire.
- Stewart
>
>> On 13 Mar 2024, at 04:20, loa@pi.nu wrote:
>>
>> Adrian,
>>
>> You have correctly interpreted my feelings, I think it is sad that we
>> drop the document.
>>
>> Since there seems to be no support for continuing the work, I have to
>> accept
>> that the document is dropped.
>>
>> /Loa
>>
>>> All,
>>>
>>> As you will have seen, there has been some discussion on the list about
>>> the
>>> work still needed to complete draft-ietf-mpls-sfl-control and a bug in
>>> the
>>> spec that Stewart has discovered.
>>>
>>> I asked on the list (2024-02-26) whether anyone is still interested in
>>> this
>>> work
>>> I repeated the question (2024-03-04)
>>> Stewart rephrased my questions (2024-03-04) to ask if anyone has
>>> implemented
>>> or deployed, or has plans to implement or deploy
>>>
>>> The only response has been from Loa, suggesting that if someone is
>>> willing
>>> to do the work then he would support them, and that (my interpretation)
>>> he
>>> would be sad to see the document dropped.
>>>
>>> So, this email is a formal call for consensus.
>>>
>>> The chairs propose to pull the document back from the AD and drop it
>>> from
>>> the working group. This would allow anyone to pick the document up
>>> again
>>> in
>>> the future, but it would need to go back through the working group
>>> adoption
>>> process.
>>>
>>> Please speak up if you are opposed to this action. In particular,
>>> please
>>> state why you are opposed (e.g., you know something about
>>> implementation/deployment) and how you propose that the document should
>>> move
>>> forward (i.e., who would do what work).
>>>
>>> In the absence of voices opposed to this approach, the chairs will take
>>> the
>>> action.
>>>
>>> This call ends on Tuesday 19th March 2024 at 17.00 UTC (i.e., after the
>>> MPLS
>>> session at IETF-119).
>>>
>>> Thanks,
>>> Adrian (on behalf of the MPLS WG chairs)
>>>
>>> _______________________________________________
>>> mpls mailing list
>>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>
>