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

[Gyan Mishra <[e-mail]>]

Hi Susan

Thanks for the heads up.

I will look out for the WG LC in IDR and BESS.

Kind Regards

Gyan

On Thu, Jul 7, 2022 at 7:40 PM Susan Hares <[e-mail]> wrote:

> Gyan:
>
>
>
> IDR WG have also adopted
>
>
>
> draft-ietf-idr-sr-p2mp-policy-00
> <https://datatracker.ietf.org/doc/draft-ietf-idr-sr-p2mp-policy/>
>
>
>
> Jeffrey Zhang has joined as co-author.
>
> Work is undergoing in the author group
>
> To help align it to other work.
>
>
>
> It will be WG LC in IDR and BESS.
>
>
>
> Cheers, Sue
>
>
>
>
>
> *From:* BESS <[e-mail]> *On Behalf Of * Gyan Mishra
> *Sent:* Monday, May 30, 2022 10:15 AM
> *To:* Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]>
> *Cc:* Alexander Vainshtein <[e-mail]>; Andrew Alston
> - IETF <andrew-ietf=[e-mail]>; SPRING WG <
> [e-mail]>; Stewart Bryant <[e-mail]>; [e-mail];
> mpls-chairs <[e-mail]>; [e-mail]
> *Subject:* Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires
> and SR
>
>
>
>
>
> Other options for operators migrating to SR for Multicast P-Tree which is
> still being developed by vendors is BIER which is stateless.
>
>
>
> BGP Multicast Controller is a new solution which is being developed which
> uses TEA RFC 9012 for signaling encoding alternative to MVPN procedures
> defined in RFC 6513 and 6514  for P2P Tree PTA encoding.  This is based on
> BGP MCAST TREE SAFI defined in BGP Multicast draft. This draft provides a
> more general solution and as well supports both mLDP inband and out of band
> signaling as well as non mLDP based  SR use cases.
>
>
>
> BIER RFC 8296 & RFC 8279
>
>
>
> BGP Multicast
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00
>
>
>
>
>
> BGP Multicast Controller
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-3.1.1
>
>
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Mon, May 30, 2022 at 9:56 AM Gyan Mishra <[e-mail]> wrote:
>
> I agree with Saha and Jorge as I stated in my response that the
> directional choice for use cases VPLS  E-Line, E-LAN, E-Tree signaling is
> to transition off LDP to BGP based signaling processing using EVPN for any
> L2 VPN use cases when migrating to Segment Routing both SR-MPLS and SRv6.
>
>
>
> As I mentioned in my initial response, part of the transition in the
> migration is to be able to use RFC 7473 Controlling State Advertisements of
> Non Negotiated LDP Applications, which provides a vendor knob to turn off
> LDP advertisements for unicast and selectively only allow on a per
> application basis for both L2 VPN  customers using T-DP for signaling and
> MVPN PTA application PTA mLDP P2MP and MP2MP.
>
>
>
> This knob allows the ability to create a slimmed down profile of LDP so
> it’s no longer used for Unicast application flows once all unicast is
> migrated to Segment Routing and selectively allows the per application SAC
> capabilities know to keep the applications requiring LDP to continue to use
> until the application has migrated off LDP.
>
>
>
> For multicast solutions operators have the option of TREE SID which uses
> the Replication SID in SR P2MP policy which has been implemented by most
> vendors.
>
>
>
> RFC 7473 SAC knob
>
> https://datatracker.ietf.org/doc/html/rfc7473
>
>
>
>
>
> Once all applications are migrated off LDP, LDP can be safely removed from
> the network.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Mon, May 30, 2022 at 6:02 AM Rabadan, Jorge (Nokia - US/Sunnyvale) <
> [e-mail]> wrote:
>
> 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 <[e-mail]> on behalf of Alexander Vainshtein <
> [e-mail]>
> *Date: *Monday, May 30, 2022 at 10:58 AM
> *To: *Stewart Bryant <[e-mail]>, Andrew Alston - IETF
> <andrew-ietf=[e-mail]>, mpls-chairs <
> [e-mail]>
> *Cc: *SPRING WG <[e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> *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://datatracker.ietf.org/doc/html/rfc8214>).
>
>
>
> 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://datatracker.ietf.org/doc/html/rfc4720>).
>
>
>
> 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: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* Pals <[e-mail]> *On Behalf Of *Stewart Bryant
> *Sent:* Monday, May 30, 2022 11:10 AM
> *To:* Andrew Alston - IETF <andrew-ietf=[e-mail]>;
> [e-mail]; mpls-chairs <[e-mail]>
> *Cc:* SPRING WG <[e-mail]>
> *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=[e-mail]> 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
> [e-mail]
>
> 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.
>
> _______________________________________________
> Pals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pals
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*