From nobody Wed Sep 14 21:30:11 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 82239C1522B8; Wed, 14 Sep 2022 21:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 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_BLOCKED=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, 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 OVXXdT1rhBKm; Wed, 14 Sep 2022 21:30:00 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 BF0EEC1522A4; Wed, 14 Sep 2022 21:30:00 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id i17so4247828uaq.9; Wed, 14 Sep 2022 21:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=HSr4y2q1DuNzO9LDgRtvP4mwuz8/InwzwajVHBgkxl0=; b=D6y9FNUgHjsgeR3o811wQJMIdgbG54JsW04jGJUTzP8FmImsHz22wAGlHv290KAsAs pyRtXgHXtKpJ873DgoI8PDZmJIE0cj5zpvgUNwncQbTYDRD79lJoY+GvxRbOVt19Cy9R ldmfKsvM3UuQjfTqXr8Wx2sh31gntsMLjc47SyAAoOE05wnsb+YaYUtQZjIC+g8YJBTs 7/9AHjQWcTTIeSFo0JkYG5OQoVePX2NU1HMfdna00TAI5xRwYY/wQ1sY6QRR+WoRgDcm gG0U0GwJsEGPQQZI+J4+Rh38wcQMawnCBmM/wO/vIKEmVfCJginTfZ1eMChd0e4GiDVN 0zDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=HSr4y2q1DuNzO9LDgRtvP4mwuz8/InwzwajVHBgkxl0=; b=L1ZbqO/lvoOSICwxdjnl1Q+yx+yJuQi2KQkA0ym2SMliC7Txn3Y1HnND7JJ+CRhie0 Qg/61/u4CBeXxsUHwQyAdKZY+YxozeLGFa5gNzkRmz18IXnWAusUqnsYaXRjQD6SofGb 06sox+30wxZ3Xv/WPVG5AQHxALtUDrBAqD2a33tngBZWdVjDefpMoGsahh92eueU98JJ dA8jsXRhd5na65IcPhGyR4nZQuXHSeeYFJrXWiwDZHzU4Ylu2uQSr9HOiYGo6bqr6QVR tDw3s4aW6mSvEMtc8QvvM6qUhLvt7/UGTI+spa5MFawrfveYBGaT8FFqG0O8C+mLJ/LX nMJA== X-Gm-Message-State: ACgBeo3ZnY5UOzt9M+vz92gJjJTpQggkvpGk4qRFD22YivZQFHq2wvc7 Z9wJBTtYZHdn4GXiksRzVxwQs4kJGh31lueZI1wzDXfA X-Google-Smtp-Source: AA6agR7x7YklJyHZbQJMgQeIo/sS7XdQICJ12XxlV7TB1LQkzG/vv+xyQJAZL5gLBUpQH+1fjYC5O063TbSpMjvW80E= X-Received: by 2002:ab0:65c6:0:b0:3ae:419a:4a36 with SMTP id n6-20020ab065c6000000b003ae419a4a36mr13456132uaq.88.1663216199607; Wed, 14 Sep 2022 21:29:59 -0700 (PDT) MIME-Version: 1.0 References: <51706C42-15E2-442D-916E-627769062F22@gmail.com> <38720EC0-D677-4197-85C6-97DABB11E994@cisco.com> <1FD68315-3A0A-4D55-AA7F-22E254B5671D@cisco.com> In-Reply-To: <1FD68315-3A0A-4D55-AA7F-22E254B5671D@cisco.com> From: Gyan Mishra Date: Thu, 15 Sep 2022 00:29:48 -0400 Message-ID: To: "Christian Schmutzer (cschmutz)" Cc: SPRING WG , "bess@ietf.org" , mpls-chairs , "pals@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c327ef05e8afb2e5" Archived-At: Subject: Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini Pseudowires and SR X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2022 04:30:05 -0000 --000000000000c327ef05e8afb2e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christian I reviewed both PLE draft and I believe this PLE draft will be very helpful for operators migrating to SR-MPLS or SRv6 and need a way to support CES PWE3 T-LDP signaling over EVPN VPWS. I support progressing the draft. Thanks Gyan On Sat, Jun 4, 2022 at 1:34 AM Christian Schmutzer (cschmutz) wrote: > restriction> > > > On 01.06.2022, at 09:42, Christian Schmutzer (cschmutz) < > cschmutz@cisco.com> wrote: > > Hi, > > After the initial hype for PWE3 in the early 2000s we have seen renewed > interest in circuit emulation (TDM PWE3) in 2015 as there was (and still > is) a lot of PDH and SONET/SDH infrastructure out there that operators > can=E2=80=99t get rid of fast enough while those products go end of life. > > We have invested in a modern, complete (SATOP, CESOP and CEP) and > high-density MPLS/PWE3 implementation and several operators and utilities > have deployed our solution (based on T-LDP PWE3). > > Having said that, many operators raised the question on =E2=80=9Cwhy not = EVPN-VPWS > instead of T-LDP?=E2=80=9D as they were already looking at EVPN-VPWS for = ethernet > services. As we see continued interest in our circuit emulation offering > and this EVPN-VPWS question is continuously coming up I believe there is > merit in addressing TDM pseudowire setup via EVPN-VPWS. > > Also more recently we got requests to carry high speed =E2=80=9Cpipes=E2= =80=9D such as > 10GE, 100GE, OC192/STM64 and various FibreChannel variants in a transpare= nt > manner which lead to our PLE data plane proposal documented in > https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple. > > For PLE (being new) we looked at EVPN-VPWS to start with (instead of > T-LDP) and also already started a proposal via > https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple-vpws-signa= lling. > The proposal is not re-inventing the wheel, rather aligning with the > concepts defined in T-LDP. We would appreciate community review and input= . > > I think draft-schmutzer-bess-ple-vpws-signalling can address the =E2=80= =9CTDM=E2=80=99ish=E2=80=9D > features while another document or updates to RFC8214 could address the > other (more generic gaps) to RFC8077 and other T-LDP RFCs. > > Regards > Christian > > On 31.05.2022, at 18:52, Ketan Talaulikar wrote: > > + 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: >> >> 1. All the non-Ethernet PW types (28 such types can be found in the I= ANA >> registry >> >> ) >> 1. Not sure if all these types are relevant for the industry today >> 2. AFAIK, TDM and SONET over packet are still widely deployed >> 2. Differentiation between Raw and Tagged Ethernet PW types (not sure >> it is needed, but still) >> 3. All Interface Attributes listed in the IANA registry with the >> following exclusions: >> 1. Interface MTU (EVPN VPWS supports a standard way to ignore it >> which IMHO is one great advantage over LDP-based signaling) >> 2. Flow Label (support is defined in 7432bis) >> 4. Full-blown PW status signaling >> 5. FCS retention =E2=80=93 not sure it is used these days >> 6. PW fragmentation and reassembly - not sure it is used these days. >> >> >> >> Regards, >> >> Sasha >> >> >> >> Office: +972-39266302 >> >> Cell: +972-549266302 >> >> Email: Alexander.Vainshtein@rbbn.com >> >> >> >> *From:* Rabadan, Jorge (Nokia - US/Sunnyvale) >> *Sent:* Monday, May 30, 2022 1:02 PM >> *To:* Alexander Vainshtein ; Stewart >> Bryant ; Andrew Alston - IETF > 40liquid.tech@dmarc.ietf.org>; mpls-chairs >> *Cc:* SPRING WG ; pals@ietf.org; bess@ietf.org >> *Subject:* Re: [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR >> >> >> >> I concur with Sasha. >> >> We=E2=80=99ve been gone through a significant effort to unify the servic= e >> signaling by using EVPN. If we are missing anything in EVPN VPWS compare= d >> to T-LDP based PWs, I would rather look at extending EVPN VPWS (if neede= d). >> If not an option, it would good to discuss at least why EVPN VPWS is not= an >> option. >> >> >> >> Thanks, >> >> Jorge >> >> >> >> >> >> *From: *Pals on behalf of Alexander Vainshtein < >> Alexander.Vainshtein@rbbn.com> >> *Date: *Monday, May 30, 2022 at 10:58 AM >> *To: *Stewart Bryant , Andrew Alston - IETF < >> andrew-ietf=3D40liquid.tech@dmarc.ietf.org>, mpls-chairs < >> mpls-chairs@ietf.org> >> *Cc: *SPRING WG , pals@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 >> ). >> >> >> >> >> 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 tod= ay >> with EVPN-VPWS (e.g., FCS retention =E2=80=93 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. >> >> >> >> My 2c, >> >> Sasha >> >> >> >> Office: +972-39266302 >> >> Cell: +972-549266302 >> >> Email: Alexander.Vainshtein@rbbn.com >> >> >> >> *From:* Pals *On Behalf Of *Stewart Bryant >> *Sent:* Monday, May 30, 2022 11:10 AM >> *To:* Andrew Alston - IETF ; >> pals@ietf.org; mpls-chairs >> *Cc:* SPRING WG >> *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 th= at >> you end up going through the PW development cycle again as old requireme= nts >> re-emerge. >> >> >> >> Stewart >> >> >> >> >> >> >> >> Sent from my iPad >> >> >> >> On 30 May 2022, at 07:22, Andrew Alston - IETF < >> andrew-ietf=3D40liquid.tech@dmarc.ietf.org> wrote: >> >> =EF=BB=BF >> >> 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 generall= y >> 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 i= n an SR >> context. This means that standard martini pseudowires no longer functio= n. >> 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 compa= tible >> with IPv4 and IPv6 =E2=80=93 that simply exists to setup and tear down t= he service >> labels for point to point services. 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) >> >> >> >> 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 th= is >> 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 a= nd >> 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=3Dhttps%3A%2= F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >> >> >> Notice: This e-mail together with any attachments may contain informatio= n >> of Ribbon Communications Inc. and its Affiliates that is confidential >> and/or proprietary for the sole use of the intended recipient. Any revie= w, >> 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 copi= es, >> including any attachments. >> >> >> Notice: This e-mail together with any attachments may contain informatio= n >> of Ribbon Communications Inc. and its Affiliates that is confidential >> and/or proprietary for the sole use of the intended recipient. Any revie= w, >> 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 copi= es, >> including any attachments. >> >> Notice: This e-mail together with any attachments may contain informatio= n >> of Ribbon Communications Inc. and its Affiliates that is confidential >> and/or proprietary for the sole use of the intended recipient. Any revie= w, >> 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 copi= es, >> including any attachments. >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000c327ef05e8afb2e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Christian

I reviewed both PLE draft and I believe this PLE draft will be = very helpful for operators migrating to SR-MPLS or SRv6 and need a way to s= upport CES PWE3 T-LDP signaling over EVPN VPWS. =C2=A0

I support progressing the draft.=C2=A0
=

Thanks=C2=A0

Gyan

On Sat, Jun 4, 2022 at 1:34 AM = Christian Schmutzer (cschmutz) <cschmutz=3D40cisco.com@dmarc.ietf.org> wrote:
<Resending with trimmed to/cc list to try to pass the BESS recipient res= triction>


On 01.06.2022, at 09:42, Christian Schmutzer (cschmutz) <cschmutz@cisco.com> wr= ote:

Hi,

After the initial hype for PWE3 in the early 2000s we have seen renewe= d interest in circuit emulation (TDM PWE3) in 2015 as there was (and still = is) a lot of PDH and SONET/SDH infrastructure out there that operators can= =E2=80=99t get rid of fast enough while those products go end of life.

We have invested in a modern, complete (SATOP, CESOP and CEP) and high= -density MPLS/PWE3 implementation and several operators and utilities have = deployed our solution (based on T-LDP PWE3).

Having said that, many operators raised the question on =E2=80=9Cwhy n= ot EVPN-VPWS instead of T-LDP?=E2=80=9D as they were already looking at EVP= N-VPWS for ethernet services. As we see continued interest in our circuit e= mulation offering and this EVPN-VPWS question is continuously coming up I believe there is merit in addressing TDM pseud= owire setup via EVPN-VPWS.

Also more recently we got requests to carry high speed =E2=80=9Cpipes= =E2=80=9D such as 10GE, 100GE, OC192/STM64 and various FibreChannel variant= s in a transparent manner which lead to our PLE data plane proposal documen= ted in https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple.

For PLE (being new) we looked at EVPN-VPWS to start with (instead of T= -LDP) and also already started a proposal via=C2=A0https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple-= vpws-signalling. The proposal is not re-inventing the wheel, rather aligning with the conce= pts defined in T-LDP. We would appreciate community review and input.

I think draft-schmutzer-bess-ple-vpws-signalling can address the =E2= =80=9CTDM=E2=80=99ish=E2=80=9D features while another document or updates t= o RFC8214 could address the other (more generic gaps) to RFC8077 and other = T-LDP RFCs.

Regards
Christian=C2=A0

On 31.05.2022, at 18:52, Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
+ 1 to Sasha and Jorge

The feature gaps to be addressed in BGP EVPN VPWS should be based on o= perators' feedback so we add only those that are relevant.

Thanks,
Ketan


On Tue, May 31, 2022 at 4:59 PM Alexa= nder 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:

  1. All the non-Ethernet PW types (28 such types= can be found in the IANA registry)
    1. Not sure if all these types are relevant for= the industry today
    2. AFAIK, TDM and SONET over packet are still w= idely deployed
  2. Differentiation between Raw and Tagged Ether= net PW types (not sure it is needed, but still)
    3. All Interface Attributes listed in the IANA = registry with the following exclusions:
    1. Interface MTU=C2=A0 (EVPN VPWS supports a st= andard way to ignore it which IMHO is one great advantage over LDP-based si= gnaling)
    2. Flow Label (support is defined in 7432bis)
  3. Full-blown PW status signaling
  4. FCS retention =E2=80=93 not sure it is used = these days
  5. PW fragmentation and reassembly - not sure i= t is used these days.

=C2=A0<= /span>

Regards,

Sasha

=C2=A0<= /span>

Office: +972-39266302=

Cell:=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0 Alexander.Vainshtein@rbbn.com

=C2=A0<= /span>

From: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.rabadan@nok= ia.com>
Sent: Monday, May 30, 2022 1:02 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Stewart = Bryant <st= ewart.bryant@gmail.com>; Andrew Alston - IETF <andrew-ietf=3D40liquid.tech@dmarc.ietf.org>; mpls-c= hairs <mpls-ch= airs@ietf.org>
Cc: SPRING WG <spring@ietf.org>; pals@ietf.org; bess@ietf.org
Subject: Re: [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and = SR

=C2=A0

I concur with Sasha.

We=E2=80=99ve 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 t= o discuss at least why EVPN VPWS is not an option.

=C2=A0

Thanks,

Jorge

=C2=A0

=C2=A0

From: Pals <pals-bounces@ietf.org> on behalf of Alexander Vainshtein <Alexan= der.Vainshtein@rbbn.com>
Date: Monday, May 30, 2022 at 10:58 AM
To: Stewart Bryant <stewart.bryant@gmail= .com>, Andrew Alston - IETF &l= t;andrew-ietf=3D40liquid.tech@dm= arc.ietf.org>, mpls-chairs <mpls-chairs@ietf.org>
Cc: SPRING WG <spring@ietf.org>, pals@ietf.org <<= /span>pals@ietf.org>, bess@ietf.org <<= /span>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 a= n SR-based environment is quite problematic for the operators.

=C2=A0

One alternative is transition to setup of PWs using MP BGP based on t= he EVPN-VPWS mechanisms (RFC 8214). =C2=A0

=C2=A0

These mechanisms probably require some extension to support PWs that = carry non-Ethernet customer traffic as well as support of some features tha= t can be signaled via LDP for Ethernet PWs but cannot be signaled today with EVPN-VPWS (e.g., FCS retent= ion =E2=80=93 = RFC 4720).

=C2=A0

My guess is that, once the basic EVPN-VPWS signaling is supported, mi= gration of LDP-signaled PWs to EVPN-VPWS would be simple enough.<= /u>

=C2=A0

This work, if approved, would require intensive cooperation between P= ALS WG and BESS WG.

=C2=A0

My 2c,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0 <= span style=3D"font-size:11pt">Alexander.Vainshtein@rbbn.com

=C2=A0

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=3D40liquid.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

=C2=A0

Including the PALS and MPLS WGs in the discussion.

=C2=A0

In the case of PWs, LDP runs directly between the T-PEs to provide th= e 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 necessa= rily need a standard.

=C2=A0

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.

=C2=A0

Stewart

=C2=A0

=C2=A0

=C2=A0

Sent from my iPad



On 30 May 2022, at 07:22, Andrew Alston - IE= TF <andrew-ietf=3D40liquid.te= ch@dmarc.ietf.org> wrote:

=EF=BB=BF

Hi All,

=C2=A0

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

=C2=A0

One of the things that our network uses, and is used by so many netwo= rks out there, are martini based pseudowires (which for clarity are general= ly 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 m= eans that standard martini pseudowires no longer function.=C2=A0 This gets = even more complicated when you want to do martini based pseudowires over an IPv6 only network, particularly considering the lack o= f widespread support for LDP6.

=C2=A0

This is also relevant in cases where networks wish to 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 co= mpatible with IPv4 and IPv6 =E2=80=93 that simply exists to 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 doing and, call this= a call for expressions of interest in those who may be willing to work towards something like this.=C2=A0 Hap= py to take emails on list or off list and see if we can find 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://clicktime.symantec.com/3Dg1AP6= FnSDeshweMg29hXi7GS?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring


Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. and its Affiliates that is confidential and/or= proprietary for the sole use of the intended recipient. Any review, disclo= sure, 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 a= nd then delete all copies, including any attachments.<= /p>


Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. and its Affiliates that is confidential and/or= proprietary for the sole use of the intended recipient. Any review, disclo= sure, 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 a= nd then delete all copies, including any attachments.<= /p>


Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. and its Affiliates that is confidential and/or= proprietary for the sole use of the intended recipient. Any review, disclo= sure, 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 a= nd then delete all copies, including any attachments.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/bess


_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
--
--000000000000c327ef05e8afb2e5--