From nobody Mon May 30 00:58:48 2022 Return-Path: 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 42FA6C14CF06 for ; Mon, 30 May 2022 00:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 fXAySsVLyGEF for ; Mon, 30 May 2022 00:58:43 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 804DEC14F748 for ; Mon, 30 May 2022 00:58:43 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id v11-20020a17090a4ecb00b001e2c5b837ccso3745195pjl.3 for ; Mon, 30 May 2022 00:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lgs9glsXMpV7mh38hQoqA7WdyLEnGUHjmIZSUdPQQWk=; b=QRl+WORveI8CuSSEofGT9Sg3xAxP+RbETb8DS0Q8QcQEc4xwLI+WWJ/Mqy+tEUro1P ZVUQ3qfskm1mUoaJrT5x3xf12oyfCljMhCub9jMmIsW+O1PXCYkynQ28PDGNYR/lqjT/ HnHqKXFjmU654XKHTChc9Dh8jOeJ/BE4O6xUsLM8y0vZj3+YQiRARXxxPHmx68X9e7fl p5mFHqCEVr3R2ZHBwBIGVLlDqRbrU92SthauM5ZpLpW+w1SLBQRY7K3NHS879M/oJ85N lCy3ff3IcjZhJubK89FqRYITAZQAu+Ewi0AjRYF9acjXl/hG2MRk+3yWN6+32ABuTDo3 2FPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lgs9glsXMpV7mh38hQoqA7WdyLEnGUHjmIZSUdPQQWk=; b=Q2ZnTcVLTsNDbsdBv+9sEqYZ0po+JPbL7zwXjVjLkeccCCPCa23Ue253KQHV0EZ/BL s5A6VaEd+cEVGo7MfQf+RC9s+mHXA33JGMqsohUpMyY5gtHuXx2yFrnF+a1idqsAzQKV HFpv77QT5UYNRsTULhy8g4RlDPENYOtinKRxXtLqYkX/bRQowdVmQoR7PziFgO371sIz jd7Gq0YvEpJEj5QqdSsoyEHpywSD+/yILy8pztdb0mq7EcbK8511jtBzgKGR4o4TpWYl RstNtXq2lTj+L6obapx27D9G5Cto0ftXfFtRxtWmYFGovKhhUnJlFEefPdQAUcjKurfe lg0w== X-Gm-Message-State: AOAM532Vh21Xb2UkDNEpmJ5uAasWXe/PV5dHLPiRzg6Th9PZMrj6Xb1D d6auBosFUq7eEChQdih420DNFFEn/o+IamUkNS7dZXzj X-Google-Smtp-Source: ABdhPJz96Ld8Zkj9W5gcvsuIRhpt/iVMV8U2WwJzDPNwoyweZtZ8JtYBq3+qY0lPiguYaETugm7DZeCBv3V0saWAkIs= X-Received: by 2002:a17:90a:404d:b0:1e2:d775:4a43 with SMTP id k13-20020a17090a404d00b001e2d7754a43mr7325168pjg.93.1653897522760; Mon, 30 May 2022 00:58:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Mon, 30 May 2022 03:58:32 -0400 Message-ID: To: Andrew Alston - IETF Cc: SPRING WG Content-Type: multipart/alternative; boundary="00000000000056d2e105e036063e" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2022 07:58:47 -0000 --00000000000056d2e105e036063e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew The workaround today for operators migrating to SR would migrate all unicast to SR-MPLS or SRv6 and any services using LDP signaling such as L2 VPN VPLS targeted LDP or MVPN PTA mLDP would keep LDP enabled in parallel until L2 VPNs can be migrated to EVPN BGP based signaling and mLDP migrated to SR P2MP policy using Tree SID solution. Once migrated, LDP can be eliminated from the network. RFC 7473 Controlling the state advertisement of non negotiated LDP Applications. With this knob labels are NOT allocated for unicast applications and are only allocated for L2VPN or mLDP applications providing that streamlined LDP light style functionality you are asking about that is crucial for operators migrating to SR. https://datatracker.ietf.org/doc/html/rfc7473 Most vendors support this SAC capability knob when deploying SR. Kind Regards Gyan On Mon, May 30, 2022 at 2:22 AM Andrew Alston - IETF 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=E2=80=99t 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 =E2=80=93 both compat= ible with > IPv4 and IPv6 =E2=80=93 that simply exists to setup and tear down the ser= vice > labels for point to point services. A form of targeted LDP without all t= he > other complexities involved in LDP =E2=80=93 that could potentially run a= t 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 thi= s > 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 an= d > 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 > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000056d2e105e036063e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew=C2=A0

The workaround today for operators migrating to SR would migrate = all unicast to SR-MPLS or SRv6 and any services using LDP =C2=A0signaling s= uch as L2 VPN VPLS targeted LDP or MVPN PTA mLDP would keep LDP enabled in = parallel until L2 VPNs can be migrated to EVPN BGP based signaling and mLDP= migrated to SR P2MP policy using Tree SID solution.

Once migrated, LDP can be eliminated from the = network.

RFC 7473 Contro= lling the state advertisement of non negotiated LDP Applications. =C2=A0

With this knob labels are = NOT allocated for unicast applications and are only allocated for L2VPN or = mLDP applications providing that streamlined LDP light style functionality = you are asking about that is crucial for operators migrating to SR.


Most ve= ndors support this SAC capability knob when deploying SR.

Kind Regards=C2=A0

Gyan

=
On Mon, May 30, 2022 at 2:22 AM Andre= w Alston - IETF <andrew-ietf=3D40liquid.tech@dmarc.ietf.org> wrote:

Hi All,

=C2=A0

Sending this email wearing only the hat of a working= group participant.

=C2=A0

One of the things that our network uses, and is used= by so many networks out there, are martini based pseudowires (which for cl= arity are generally setup using what is described in RFC8077).=C2=A0 In an = SR world however, this creates a problem, because typically you don=E2=80=99t want to run LDP in an SR context.=C2= =A0 This means that standard martini pseudowires no longer function.=C2=A0 = This gets even more complicated when you want to do martini based pseudowir= es over an IPv6 only network, particularly considering the lack of widespread support for LDP6.

=C2=A0

This is also relevant in cases where networks wish t= o run SR-MPLS in the absence of SRv6 for whatever reason.

=C2=A0

So, my question to the working group is this:=

=C2=A0

Is it worth looking at creating a form of LDP light = =E2=80=93 both compatible with IPv4 and IPv6 =E2=80=93 that simply exists t= o setup and tear down the service labels for point to point services.=C2=A0= A form of targeted LDP without all the other complexities involved in LDP =E2=80=93 that could potentially run at a lower preference= than LDP itself (so if LDP is there, use it, if not use this)

=C2=A0

Before I start drafting though, I would like to hear= from the working group if there are others who feel that this is worth doi= ng and, call this a call for expressions of interest in those who may be wi= lling to work towards something like this.=C2=A0 Happy to take emails on list or off list and see if we can fin= d a solution.

=C2=A0

Looking forward to hearing from you all

=C2=A0

Thanks

=C2=A0

Andrew

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--
--00000000000056d2e105e036063e--