Re: [spring] Martini Pseudowires and SR

Stewart Bryant <stewart.bryant@gmail.com> Mon, 30 May 2022 08:10 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54D8C14CF0D; Mon, 30 May 2022 01:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.103
X-Spam-Level:
X-Spam-Status: No, score=-7.103 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, MIME_QP_LONG_LINE=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 GPH2eyE2weik; Mon, 30 May 2022 01:10:30 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE256C14CF0C; Mon, 30 May 2022 01:10:30 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id b8so4496726edf.11; Mon, 30 May 2022 01:10:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=EgpFnqynGZuxVHuAV0qccAPswcQn+Bfbqlq1hXNorbY=; b=QpnfJJDQ/mvF9xHRZyGb91U4nZuu7Ejqkn3neoTeKcLdOBv7KV+kLCN2KmRcKbZGei +uK+hVBww3Q3VUbatBnzBrVGUS84dMAtLd/ZAvNYgJYt+ZjiAHl2eDNU61aJHH5ZGDKc cTK6ruVohpd86WbR/MtAbU+7ZgRjDqif5G73EPqsSUYTok18BXmmeXeHh28xqRBAdhmz Rf8lpEIjkQi63LzxqDgov41Hw+IhL4xAVtzKwfGYe207am17VAkRtNWYcX9KqC4zlcBX fXFigOWQXQrZdywlAzaqBnoIYdvzvo2kLEX4pXCa2J62gC3c4z5ziN6Slh80/GgycEzO 4O/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=EgpFnqynGZuxVHuAV0qccAPswcQn+Bfbqlq1hXNorbY=; b=NhNO4V/7Jq5StTBoGIUwHHSdD2vausnNel64lXP+dXI/0iOZJaAH71yAkLUD5R5RTV IP89vijQOea/EsyXBSiWvSGtJ0LFqNlEuXxTuwoVQ90pwk6OpMQm/h2ouX4fLDDJ7v5B e5e22gBKoyvp3fnXdX5wWaoPMPMcwf/fA+S+yf8NrGPN5RUjr6TZxaIde23125XBelgD M8VJ2sn40TccDlvBl+nx733KWiCviREz++SGnye47uaz8AhoMQQ4gI7CiiK1y/Jxax/Z Jn9Uz9CNIvCwBsJFK2as6JufN6k7WfMjvzNgkQgm6qyhe0tyEVNIsrrYdj3ueH/WIRPn ugiQ==
X-Gm-Message-State: AOAM530lw7MyV8Wo55YyVxwxfZ4lkYqI0ePDTHcXZzQxSABFmHkoZsaX dCP8p0+sp1PqJEwPIsNQKUynZpgkiWk=
X-Google-Smtp-Source: ABdhPJyBo1gJWtGDkn4sD48EnSkFNcSY3K8xKf1G9o46HsMMRJpnl9KJVHp07395GVaWf0LMz5SYew==
X-Received: by 2002:aa7:cacd:0:b0:42b:b1b6:e054 with SMTP id l13-20020aa7cacd000000b0042bb1b6e054mr28013694edt.281.1653898228306; Mon, 30 May 2022 01:10:28 -0700 (PDT)
Received: from smtpclient.apple ([85.255.236.144]) by smtp.gmail.com with ESMTPSA id z5-20020a50f145000000b0042dc460bda6sm3037954edl.18.2022.05.30.01.10.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 May 2022 01:10:27 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-F06A6CB8-069C-4079-BEED-D6A956C4BBB6"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <AM7PR03MB64514C7EA1750090FE94192CEEDD9@AM7PR03MB6451.eurprd03.prod.outlook.com>
Date: Mon, 30 May 2022 09:10:27 +0100
Cc: SPRING WG <spring@ietf.org>
Message-Id: <51706C42-15E2-442D-916E-627769062F22@gmail.com>
References: <AM7PR03MB64514C7EA1750090FE94192CEEDD9@AM7PR03MB6451.eurprd03.prod.outlook.com>
To: Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org>, pals@ietf.org, mpls-chairs <mpls-chairs@ietf.org>
X-Mailer: iPad Mail (19E258)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/xDp8nLe93ntlHx-5Akrz99c5cH4>
Subject: Re: [spring] Martini Pseudowires and SR
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 May 2022 08:10:31 -0000

Including the PALS and MPLS WGs in the discussion.

In the case of PWs, LDP runs directly between the T-PEs to provide the control plane. If it is known that the only use of LDP is to support PW, then a lightweight profile of LDP might be implemented, ignoring unused parts, but this does not necessarily need a standard.

Before you can profile LDP, you have to also profile PWs to determine which subset of the PW system you need to support. The danger here is that you end up going through the PW development cycle again as old requirements re-emerge.

Stewart



Sent from my iPad

> On 30 May 2022, at 07:22, Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org> wrote:
> 
> 
> Hi All,
>  
> Sending this email wearing only the hat of a working group participant.
>  
> One of the things that our network uses, and is used by so many networks out there, are martini based pseudowires (which for clarity are generally setup using what is described in RFC8077).  In an SR world however, this creates a problem, because typically you don’t want to run LDP in an SR context.  This means that standard martini pseudowires no longer function.  This gets even more complicated when you want to do martini based pseudowires over an IPv6 only network, particularly considering the lack of widespread support for LDP6.
>  
> This is also relevant in cases where networks wish to run SR-MPLS in the absence of SRv6 for whatever reason.
>  
> So, my question to the working group is this:
>  
> Is it worth looking at creating a form of LDP light – both compatible with IPv4 and IPv6 – that simply exists to setup and tear down the service labels for point to point services.  A form of targeted LDP without all the other complexities involved in LDP – that could potentially run at a lower preference than LDP itself (so if LDP is there, use it, if not use this)
>  
> Before I start drafting though, I would like to hear from the working group if there are others who feel that this is worth doing and, call this a call for expressions of interest in those who may be willing to work towards something like this.  Happy to take emails on list or off list and see if we can find a solution.
>  
> Looking forward to hearing from you all
>  
> Thanks
>  
> Andrew
>  
>  
>  
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring