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

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.com@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) <
> 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’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.ietf@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.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
>>    <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.Vainshtein@rbbn.com
>>
>>
>>
>> *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 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.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.
>>
>> 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
>>
> _______________________________________________
> 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
>
-- 

<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*