Re: [spring] [Pals] [EXTERNAL] Re: Martini Pseudowires and SR

Gyan Mishra <hayabusagsm@gmail.com> Mon, 30 May 2022 13:56 UTC

Return-Path: <hayabusagsm@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 33FB8C15C0AF; Mon, 30 May 2022 06:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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=unavailable 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 UMR7Bw6wWct6; Mon, 30 May 2022 06:56:52 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 3A100C15E6DC; Mon, 30 May 2022 06:56:52 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id qe11-20020a17090b4f8b00b001e3239b681bso30909pjb.0; Mon, 30 May 2022 06:56:52 -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=AtwSu6g5Y4qMYSf4RcsSqtHCSlDFB1Npa/6eKX5gToY=; b=IH8RnvVhVDXhK16Rtp+ELYZuzmWmx5GOnOWTeFb5c6iKY4MHBHmjycONu71gVJ0bTC Ye+UaLsneLUD/ROsz9oND8cWNuWria9SX0OGM7Dk1axxa00DzMXBXILC6WqCiueM7zao +LSQXdJkXCkE73wUiYEu7SnKjrY8dxL/NUKtnHPLlLXpVcsnp5ZT/YusXBOtRsuYB8He kmlfaiwPWsuRBwSwKRqRDiu2r1mng9oKBMU4gGkzyhzcntyRjshgpC8xLzByQmI8V9UK W1piuWay35BqnIqISgV0InZiyBzAQGjrATKOA+GBV8Z4Rc8lPRcUXmc9QGzLaGS88zV0 3Xpg==
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=AtwSu6g5Y4qMYSf4RcsSqtHCSlDFB1Npa/6eKX5gToY=; b=nC+4PPVfDXGprW2D25RJpiVq3YZodzWub4NzkdLh7zQf+sVemCjQbsNA24VQmYZJ4v xu6DJnMcGUA+jfJC1tSckHxNb+S2qos+l9+EFJLwhRGVd9V2OgO+Rm2kL6swgxE3rLKe wZuJNTOM2VSKtyYlrFbR4iBCDxAax6efIeoJPuulv3rOCMG9ETzw+JDjsphY64qQNZwi geW8IOL73hRMuc50AIh7GRX0X0Msui5TK+lefXKSRkoV1vmCYQgZ7aFwEbMO04scPsMM Qed65MIVAYsORBOMjLsQIpCo254xLvuB5ppja9aJxsBl4oHvY+R9sOTnNmwElIvgGKpi Xsvw==
X-Gm-Message-State: AOAM532Itvd/FftD36cJ7GJCEso/8pzOG1inaHmM29RQZ7pz39fyNZkG SLe/+B6XmQNUpwCYp4LrahAmBq+cLaej0QvSTwg=
X-Google-Smtp-Source: ABdhPJwcJ2kUyp48G0VkgcUpgjN5niXunlmVqv7UKuaja2Q2ich3mt10stfEI19M9oIiRCgcBoGUbyDzR8sjSIeqono=
X-Received: by 2002:a17:902:e948:b0:15e:cd79:2a1a with SMTP id b8-20020a170902e94800b0015ecd792a1amr56044388pll.109.1653919011052; Mon, 30 May 2022 06:56:51 -0700 (PDT)
MIME-Version: 1.0
References: <AM7PR03MB64514C7EA1750090FE94192CEEDD9@AM7PR03MB6451.eurprd03.prod.outlook.com> <51706C42-15E2-442D-916E-627769062F22@gmail.com> <PH0PR03MB6300D250BC9F3762D91E0337F6DD9@PH0PR03MB6300.namprd03.prod.outlook.com> <BY3PR08MB70600C3B393A3B2E4FCF0671F7DD9@BY3PR08MB7060.namprd08.prod.outlook.com>
In-Reply-To: <BY3PR08MB70600C3B393A3B2E4FCF0671F7DD9@BY3PR08MB7060.namprd08.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 30 May 2022 09:56:40 -0400
Message-ID: <CABNhwV0mAsHh9DeeLHOqHJQDp1X8bRkCHVrE-OzJb3Hd+nCksQ@mail.gmail.com>
To: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <jorge.rabadan@nokia.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, "bess@ietf.org" <bess@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000024244205e03b07c6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/tJy5pDkLBS8IFikJ01rxM31m2WU>
Subject: Re: [spring] [Pals] [EXTERNAL] Re: 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 13:56:56 -0000

I agree with Saha and Jorge as I stated in my response that the directional
choice for use cases VPLS  E-Line, E-LAN, E-Tree signaling is to transition
off LDP to BGP based signaling processing using EVPN for any L2 VPN use
cases when migrating to Segment Routing both SR-MPLS and SRv6.

As I mentioned in my initial response, part of the transition in the
migration is to be able to use RFC 7473 Controlling State Advertisements of
Non Negotiated LDP Applications, which provides a vendor knob to turn off
LDP advertisements for unicast and selectively only allow on a per
application basis for both L2 VPN  customers using T-DP for signaling and
MVPN PTA application PTA mLDP P2MP and MP2MP.

This knob allows the ability to create a slimmed down profile of LDP so
it’s no longer used for Unicast application flows once all unicast is
migrated to Segment Routing and selectively allows the per application SAC
capabilities know to keep the applications requiring LDP to continue to use
until the application has migrated off LDP.

For multicast solutions operators have the option of TREE SID which uses
the Replication SID in SR P2MP policy which has been implemented by most
vendors.

RFC 7473 SAC knob
https://datatracker.ietf.org/doc/html/rfc7473


Once all applications are migrated off LDP, LDP can be safely removed from
the network.

Thanks

Gyan

On Mon, May 30, 2022 at 6:02 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <
jorge.rabadan@nokia.com> wrote:

> I concur with Sasha.
>
> We’ve been gone through a significant effort to unify the service
> signaling by using EVPN. If we are missing anything in EVPN VPWS compared
> to T-LDP based PWs, I would rather look at extending EVPN VPWS (if needed).
> If not an option, it would good to discuss at least why EVPN VPWS is not an
> option.
>
>
>
> Thanks,
>
> Jorge
>
>
>
>
>
> *From: *Pals <pals-bounces@ietf.org> on behalf of Alexander Vainshtein <
> Alexander.Vainshtein@rbbn.com>
> *Date: *Monday, May 30, 2022 at 10:58 AM
> *To: *Stewart Bryant <stewart.bryant@gmail.com>, Andrew Alston - IETF
> <andrew-ietf=40liquid.tech@dmarc.ietf.org>, mpls-chairs <
> mpls-chairs@ietf.org>
> *Cc: *SPRING WG <spring@ietf.org>, pals@ietf.org <pals@ietf.org>,
> bess@ietf.org <bess@ietf.org>
> *Subject: *Re: [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR
>
> Stewart, Andrew and all,
>
> ++ Bess WG.
>
> I fully agree that using (targeted) LDP for setup of Martini PWs in an
> SR-based environment is quite problematic for the operators.
>
>
>
> One alternative is transition to setup of PWs using MP BGP based on the
> EVPN-VPWS mechanisms (RFC 8214
> <https://datatracker.ietf.org/doc/html/rfc8214>).
>
>
>
> These mechanisms probably require some extension to support PWs that carry
> non-Ethernet customer traffic as well as support of some features that can
> be signaled via LDP for Ethernet PWs but cannot be signaled today with
> EVPN-VPWS (e.g., FCS retention – RFC 4720
> <https://datatracker.ietf.org/doc/html/rfc4720>).
>
>
>
> My guess is that, once the basic EVPN-VPWS signaling is supported,
> migration of LDP-signaled PWs to EVPN-VPWS would be simple enough.
>
>
>
> This work, if approved, would require intensive cooperation between PALS
> WG and BESS WG.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@rbbn.com
>
>
>
> *From:* Pals <pals-bounces@ietf.org> *On Behalf Of *Stewart Bryant
> *Sent:* Monday, May 30, 2022 11:10 AM
> *To:* Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org>;
> pals@ietf.org; mpls-chairs <mpls-chairs@ietf.org>
> *Cc:* SPRING WG <spring@ietf.org>
> *Subject:* [EXTERNAL] Re: [Pals] [spring] Martini Pseudowires and SR
>
>
>
> 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://clicktime.symantec.com/3Dg1AP6FnSDeshweMg29hXi7GS?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/or proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
>
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/or proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
> _______________________________________________
> Pals mailing list
> Pals@ietf.org
> https://www.ietf.org/mailman/listinfo/pals
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*