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 <sha...@ndzh.com> 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 <bess-boun...@ietf.org> *On Behalf Of * Gyan Mishra > *Sent:* Monday, May 30, 2022 10:15 AM > *To:* Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com> > *Cc:* Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Andrew Alston > - IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org>; SPRING WG < > spr...@ietf.org>; Stewart Bryant <stewart.bry...@gmail.com>; bess@ietf.org; > mpls-chairs <mpls-cha...@ietf.org>; p...@ietf.org > *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 <hayabusa...@gmail.com> 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) < > jorge.raba...@nokia.com> 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 <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 <spr...@ietf.org>, p...@ietf.org <p...@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://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: +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 <spr...@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 > spr...@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. > > _______________________________________________ > Pals mailing list > p...@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > -- <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*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
