Re: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt

2022-05-30 Thread Dikshit, Saumya
Hi Loa, >>> Can you please explain what it means. It implies any re-use of the values from allocated via [I-D.draft-ietf-bess-evpn-lsp-ping] when the same-parameter is referred to in [I-D.draft-saum-evpn-lsp-ping-extension]. >>>. I would be appreciated if you notified the wg when you

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

2022-05-30 Thread Alexander Vainshtein
Gyan, I fully agree with your suggestions – with a couple of comments: * Replication SID inherently requires usage of an external controller for setup and maintenance of P2MP SR Policies * BIER inherently requires new forwarding HW. As a consequence, BGP multicast looks as the only

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

2022-05-30 Thread Gyan Mishra
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

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

2022-05-30 Thread Gyan Mishra
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

Re: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt

2022-05-30 Thread Loa Andersson
Authors, the IANA section of this draft says: This document inherits all the IANA considerations discussed in [I-D.draft-ietf-bess-evpn-lsp-ping]. Can you please explain what it means. WG Chairs The MPLS working group have put in quite a bit of effort to keep the LSP Ping parameter

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

2022-05-30 Thread Rabadan, Jorge (Nokia - US/Sunnyvale)
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

Re: [bess] FW: New Version Notification for draft-saum-bess-dampening-backoff-00.txt

2022-05-30 Thread Dikshit, Saumya
Any thoughts on below. ? Regards, Saumya. From: Dikshit, Saumya [mailto:saumya.diks...@hpe.com] Sent: Friday, April 1, 2022 5:30 PM To: Rabadan, Jorge (Nokia - US/Sunnyvale) ; Luc André Burdet ; Sergey Fomin ; bess@ietf.org Cc: draft-saum-bess-dampening-back...@ietf.org Subject: RE: [bess] FW:

[bess] New Version Notification for draft-saum-bess-dampening-backoff-03.txt

2022-05-30 Thread Dikshit, Saumya
Hello All, New version of this draft is published, on the basis of comments received in the Vienna meeting. Kindly review it further for its readiness to be WG draft. Regards, Saumya. -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Monday,

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

2022-05-30 Thread Alexander Vainshtein
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

Re: [bess] A new draft for MVPN in IPv6-only network.

2022-05-30 Thread duanfanghong
Hi Jeffrey, I have read your draft carefully, as you mentioned in this draft, it is a less optimal solution for PE to PE C-Multicast signaling. In the draft I just published, we describe IPv6-only infrastructure and dual-stack infrastructure issues and solutions for regular option B scenario