Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini Pseudowires and SR
Jeff Tantsura <jefftant.ietf@gmail.com> Wed, 01 June 2022 04:41 UTC
Return-Path: <jefftant.ietf@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 F1B6FC15AAF0; Tue, 31 May 2022 21:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 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_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 bctM-eiM0fdz; Tue, 31 May 2022 21:41:20 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 41749C15C093; Tue, 31 May 2022 21:41:06 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id q18so652646pln.12; Tue, 31 May 2022 21:41:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=cPgezS1R3MviF839BhMuEzUCme5YnMlSe6ej/69W1/k=; b=O5Krf5noO3A3y7c9mupObjtt70U+jxu3R154+SCsQ5UmDAHfQfmpo8qtWV9PTnpRh0 KOKcvFoA4PX+yhiBMetb109kZ+TW50/z3ekSoNK7UhcenVAEdDPKlik1LZ/PVGr3elDU TGifMEpRFiGTX2hLo68/dy8DYhMAX7v3y2DWL9frFXjpy9KQz8ZVmSP4yHQjZZjCcj2T 8TCUt9esUD0byB2E6RV20IjG6HQVO4Xu4qPJOnGlHWF9aypfKmvIw98ETZKZU63KWVVh tLgBJd0NdygK+hdcWzkhJX7gk1OUlqmzzIb9jEeumC0llLrA/yJ0CR9TiZpeOUihmkmi bbBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=cPgezS1R3MviF839BhMuEzUCme5YnMlSe6ej/69W1/k=; b=uIkZoLqadhoZH2dUHHclgkpWSl/5DfSOqCeP1za00hNdHcQTGa7gJXmdOKdLiBNvaR oyeRReKdwtHzQSMw4J6iuDh0hwqaGj9gl310CVPeHVURU/lPAnPxXFoTRZBRLAscGZUt 95bf6E7eH01247X2tc6KYGPQ1o6K/xk1Y5lfHNhiiSnif7CzTO7fMYtOZBF7CWGeU6qL n8xp5/5Fi1OnodxkRWO3bt/ezFACXwDC+nXscGSUNEK4Ehlsm1l3YIeQ29xFAUQt5pPo OBWl+1qnC+xjxnOk5pO0DGlAlQAM1h2I5No7m9yFdjfOvI/I2fmPS3G0r0ZQjXCrUCZ6 e5ug==
X-Gm-Message-State: AOAM532TKlp3rgz3WsGaJnAUbPpKqT/iQEPtWq+7yzSxr8WnpSGw1Bi6 qVD22ye1VLR+dAIZLNVNN+E=
X-Google-Smtp-Source: ABdhPJzX2AHkI6X8f5ELEXB9fbm2jpPXihCMLiQn+jQSjBWVMrfCdNZiRpWtOxDKY/TILet8QTQ9Xw==
X-Received: by 2002:a17:902:a581:b0:162:33b3:fff2 with SMTP id az1-20020a170902a58100b0016233b3fff2mr42526747plb.173.1654058465653; Tue, 31 May 2022 21:41:05 -0700 (PDT)
Received: from Jeff-Corp-Win (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id p8-20020aa78608000000b0051b9d27091bsm312753pfn.76.2022.05.31.21.41.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 May 2022 21:41:05 -0700 (PDT)
MIME-Version: 1.0
Date: Tue, 31 May 2022 21:41:00 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Thread-Topic: RE: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR
In-Reply-To: <CAH6gdPz1=_RkWQ0Hekh_jhiLGQP+80dExeJwRg02ScoB-6f1Jg@mail.gmail.com>
Message-ID: <4D89EC94-C066-4F16-B2A1-1BEA6EE30D17@hxcore.ol>
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> <PH0PR03MB6300E03FCF3C0307ADC9D71AF6DC9@PH0PR03MB6300.namprd03.prod.outlook.com>, <CAH6gdPz1=_RkWQ0Hekh_jhiLGQP+80dExeJwRg02ScoB-6f1Jg@mail.gmail.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>, Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Cc: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <jorge.rabadan@nokia.com>, Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org>, mpls-chairs <mpls-chairs@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, SPRING WG <spring@ietf.org>, "pals@ietf.org" <pals@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/blbqkub2rvwP9ypqA3GtfxdGRFM>
Subject: Re: [spring] [bess] [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: Wed, 01 Jun 2022 04:41:24 -0000
+1 Jorge at all. I don’t foresee significant additions to https://clicktime.symantec.com/3Qviu2KUub4f1w6MeHVbgcu6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8214" rel="nofollow">RFC 8214, most legacy PALS stuff doesn’t need to be resurrected.
However - If there’s appetite for IGP extensions for signaling PW (in spirit of SR)) and (rather than using LDP) there’s that – “Method and apparatus for pseudo-wire setup and maintenance using intermediate system to intermediate system (IS-IS)” – US patent 10454819 😉
Cheers,
Jeff
From: Ketan Talaulikar
Sent: Tuesday, May 31, 2022 9:52 AM
To: Alexander Vainshtein
Cc: Rabadan, Jorge (Nokia - US/Sunnyvale); Andrew Alston - IETF; mpls-chairs; Stewart Bryant; SPRING WG; pals@ietf.org; bess@ietf.org
Subject: Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR
+ 1 to Sasha and Jorge
The feature gaps to be addressed in BGP EVPN VPWS should be based on operators' feedback so we add only those that are relevant.
Thanks,
Ketan
On Tue, May 31, 2022 at 4:59 PM Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> wrote:
Jorge and all,
Here is a (admittedly incomplete) list of things that, AFAIK, today are not supported with EVPN VPWS:
- All the non-Ethernet PW types (28 such types can be found in the https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-2" rel="nofollow">IANA registry)
- Not sure if all these types are relevant for the industry today
- AFAIK, TDM and SONET over packet are still widely deployed
- Differentiation between Raw and Tagged Ethernet PW types (not sure it is needed, but still)
- All Interface Attributes listed in the IANA registry with the following exclusions:
- Interface MTU (EVPN VPWS supports a standard way to ignore it which IMHO is one great advantage over LDP-based signaling)
- Flow Label (support is defined in 7432bis)
- Full-blown PW status signaling
- FCS retention – not sure it is used these days
- PW fragmentation and reassembly - not sure it is used these days.
From: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.rabadan@nokia.com>
Sent: Monday, May 30, 2022 1:02 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; 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; bess@ietf.org
Subject: Re: [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR
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 SRStewart, 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 (https://clicktime.symantec.com/3Qviu2KUub4f1w6MeHVbgcu6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8214" rel="nofollow">RFC 8214).
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 – https://clicktime.symantec.com/32Jf7wnYMxKQPc3r3RR9Cy96H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4720" rel="nofollow">RFC 4720).
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.
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" rel="nofollow">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.
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.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess" rel="nofollow">https://www.ietf.org/mailman/listinfo/bess
- [spring] Martini Pseudowires and SR Andrew Alston - IETF
- Re: [spring] Martini Pseudowires and SR Gyan Mishra
- Re: [spring] Martini Pseudowires and SR Stewart Bryant
- Re: [spring] [EXTERNAL] Re: [Pals] Martini Pseudo… Alexander Vainshtein
- Re: [spring] [Pals] [EXTERNAL] Re: Martini Pseudo… Rabadan, Jorge (Nokia - US/Sunnyvale)
- Re: [spring] [Pals] [EXTERNAL] Re: Martini Pseudo… Gyan Mishra
- Re: [spring] [Pals] [EXTERNAL] Re: Martini Pseudo… Gyan Mishra
- Re: [spring] [Pals] [EXTERNAL] Re: Martini Pseudo… Alexander Vainshtein
- Re: [spring] [Pals] [EXTERNAL] Re: Martini Pseudo… Alexander Vainshtein
- Re: [spring] Martini Pseudowires and SR UTTARO, JAMES
- Re: [spring] [**EXTERNAL**] Re: [Pals] Martini Ps… Shah, Himanshu
- Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini… Ketan Talaulikar
- Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini… Jeff Tantsura
- Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini… Christian Schmutzer (cschmutz)
- Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini… Christian Schmutzer (cschmutz)
- Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini… Jeffrey (Zhaohui) Zhang
- Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini… Susan Hares
- Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini… Gyan Mishra
- Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini… Gyan Mishra