Re: [spring] Martini Pseudowires and SR

Hi Andrew

The workaround today for operators migrating to SR would migrate all
unicast to SR-MPLS or SRv6 and any services using LDP  signaling such as L2
VPN VPLS targeted LDP or MVPN PTA mLDP would keep LDP enabled in parallel
until L2 VPNs can be migrated to EVPN BGP based signaling and mLDP migrated
to SR P2MP policy using Tree SID solution.

Once migrated, LDP can be eliminated from the network.

RFC 7473 Controlling the state advertisement of non negotiated LDP
Applications.

With this knob labels are NOT allocated for unicast applications and are
only allocated for L2VPN or mLDP applications providing that streamlined
LDP light style functionality you are asking about that is crucial for
operators migrating to SR.

https://datatracker.ietf.org/doc/html/rfc7473

Most vendors support this SAC capability knob when deploying SR.

Kind Regards

Gyan

On Mon, May 30, 2022 at 2:22 AM 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://www.ietf.org/mailman/listinfo/spring
>
-- 

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