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) <cschmutz= 40cisco....@dmarc.ietf.org> wrote: > <Resending with trimmed to/cc list to try to pass the BESS recipient > restriction> > > > On 01.06.2022, at 09:42, Christian Schmutzer (cschmutz) < > cschm...@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’t 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 “why not EVPN-VPWS > instead of T-LDP?” 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 “pipes” such as > 10GE, 100GE, OC192/STM64 and various FibreChannel variants in a transparent > 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-signalling. > 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 “TDM’ish” > 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 <ketant.i...@gmail.com> 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.vainsht...@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 >> >> <https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-2> >> ) >> 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 – 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.vainsht...@rbbn.com >> >> >> >> *From:* Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com> >> *Sent:* Monday, May 30, 2022 1:02 PM >> *To:* Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Stewart >> Bryant <stewart.bry...@gmail.com>; Andrew Alston - IETF <andrew-ietf= >> 40liquid.t...@dmarc.ietf.org>; mpls-chairs <mpls-cha...@ietf.org> >> *Cc:* SPRING WG <spring@ietf.org>; p...@ietf.org; b...@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-boun...@ietf.org> on behalf of Alexander Vainshtein < >> alexander.vainsht...@rbbn.com> >> *Date: *Monday, May 30, 2022 at 10:58 AM >> *To: *Stewart Bryant <stewart.bry...@gmail.com>, Andrew Alston - IETF < >> andrew-ietf=40liquid.t...@dmarc.ietf.org>, mpls-chairs < >> mpls-cha...@ietf.org> >> *Cc: *SPRING WG <spring@ietf.org>, p...@ietf.org <p...@ietf.org>, >> b...@ietf.org <b...@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://clicktime.symantec.com/3Qviu2KUub4f1w6MeHVbgcu6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8214>). >> >> >> >> >> 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://clicktime.symantec.com/32Jf7wnYMxKQPc3r3RR9Cy96H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4720> >> ). >> >> >> >> 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.vainsht...@rbbn.com >> >> >> >> *From:* Pals <pals-boun...@ietf.org> *On Behalf Of *Stewart Bryant >> *Sent:* Monday, May 30, 2022 11:10 AM >> *To:* Andrew Alston - IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org>; >> p...@ietf.org; mpls-chairs <mpls-cha...@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.t...@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. >> >> 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 >> b...@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > _______________________________________________ > BESS mailing list > b...@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > > > _______________________________________________ > BESS mailing list > b...@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
