Re: [mpls] Second call: A question about draft-ietf-mpls-sfl-control

loa@pi.nu Mon, 04 March 2024 11:57 UTC

Return-Path: <loa@pi.nu>
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 675ADC1516E0; Mon, 4 Mar 2024 03:57:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 9Tl966EQhISJ; Mon, 4 Mar 2024 03:57:30 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC10AC15155C; Mon, 4 Mar 2024 03:57:29 -0800 (PST)
Received: from pi.nu (localhost.localdomain [127.0.0.1]) by pipi.pi.nu (Postfix) with ESMTP id A46FD3A8BF1; Mon, 4 Mar 2024 12:57:26 +0100 (CET)
Received: from 124.106.198.177 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Mon, 4 Mar 2024 12:57:26 +0100
Message-ID: <40bf81a7423c836c823a7981d9016e89.squirrel@pi.nu>
In-Reply-To: <006b01da6e27$87e606b0$97b21410$@olddog.co.uk>
References: <044701da68da$42740570$c75c1050$@olddog.co.uk> <005201da6e20$8456a290$8d03e7b0$@olddog.co.uk> <cf3e3e17e36ff8e915e7ebe9605e7f94.squirrel@pi.nu> <006b01da6e27$87e606b0$97b21410$@olddog.co.uk>
Date: Mon, 04 Mar 2024 12:57:26 +0100
From: loa@pi.nu
To: adrian@olddog.co.uk
Cc: loa@pi.nu, 'mpls' <mpls@ietf.org>, draft-ietf-mpls-sfl-control.all@ietf.org
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/_w6Xfud1mNNNIpvPksvM1Jo5ej8>
Subject: Re: [mpls] Second call: A question about 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: Mon, 04 Mar 2024 11:57:31 -0000

Adrian,

Bullet 3 would be most attractive, but since I don't have the cycles
I think bullet 2 with a little tweak is what I think we should do.
The tweak would be that where we say that MP2P and MP2MP are out of
scope for this document. we also say that a smaller protocol fix is
needed to include MP2P and MP2MP.

Of course it someone steps in and says he/she is willing to do the job.
I would be willing you support this, e.g. by reviewing the document.

/Loa

> Thanks, Loa.
>
>> I read the original mail :), but I did not respond :(.
>
> You are forgiven.
>
>> The reason is that I did not understand the implications of the protocol
>> fix and the scoping alternatives.
>>
>> Regardless of which alternative we choose, we will have the document
>> back
>> to the working group for fixing and a new WGLC, right? At least the
>> working group needs to have a chance to say what it thinks about the
>> fix.
>>
>> That scenario is right and the protocol fix is reasonably easy, I think
>> that the first alternative is the most attractive.
>
> So, the reason for my question ("does anyone care?") is that it is
> important
> to understand whether we even need to consider the fix before working out
> the fix.
> Answers might be:
> - No one cares
>     - Abandon the work (subject to formal call on list)
> - People care about P2P and P2MP but not MP2P and MP2MP
>     - Rescope the work (subject to formal call on the list)
> - People care about MP2P and/or MP2MP
>     - Bring the draft back to the WG and develop the fix (and then do WG
> last call)
>
> The third of these would (of course?) require someone to do the work!
>
> Cheers,
> Adrian
>
>
>
>
>> Hi,
>>
>> Resending this because I am hearing silence and that could mean:
>> - no one cares
>> - no one read the original email
>>
>> A
>>
>> -----Original Message-----
>> From: mpls <mpls-bounces@ietf.org> On Behalf Of Adrian Farrel
>> Sent: 26 February 2024 17:36
>> To: 'mpls' <mpls@ietf.org>
>> Cc: draft-ietf-mpls-sfl-control.all@ietf.org
>> Subject: [mpls] A question about draft-ietf-mpls-sfl-control
>>
>> Hi WG,
>>
>> While talking about draft-ietf-mpls-rfc6374-sfl and
>> draft-ietf-mpls-sfl-control with Stewart, and resulting from SEC ART
>> review
>> of draft-ietf-mpls-sfl-control by Charlie Kaufman, we discovered that
>> there
>> is a small hole in the control protocol arising in MP2P LSPs when one of
>> the
>> senders crashes and restarts.
>>
>> There are two possible approaches to solving this:
>> 1. introduce a protocol fix
>> 2. scope the utility of the control protocol draft to p2p and p2mp only
>>
>> But, before going there, we are interested to know whether anyone cares
>> about this control protocol. Has anyone implemented it? Does anyone plan
>> to
>> implement it?
>>
>> Thanks for any answers.
>>
>> Adrian
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>
>
>