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

[Gyan Mishra]

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)  wrote:

>  restriction>
>
>
> On 01.06.2022, at 09:42, Christian Schmutzer (cschmutz) <
> cschm...@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  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.vainsht...@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
>>
>> 
>>)
>>   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.vainsht...@rbbn.com
>>
>>
>>
>> *From:* Rabadan, Jorge (Nokia - US/Sunnyvale) 
>> *Sent:* Monday, May 30, 2022 1:02 PM
>> *To:* Alexander Vainshtein ; Stewart
>> Bryant ; Andrew Alston - IETF > 40liquid.t...@dmarc.ietf.org>; mpls-chairs 
>> *Cc:* SPRING WG ; p...@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  on behalf of Alexander Vainshtein <
>> alexander.vainsht...@rbbn.com>
>> *Date: *Monday, May 30, 2022 at 10:58 AM
>> *To: *Stewart Bryant , Andrew Alston - IETF <
>> andrew-ietf=40liquid.t...@dmarc.ietf.org>, mpls-chairs <
>> mpls-cha...@ietf.org>
>> *Cc: *SPRING WG , p...@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 

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

[Gyan Mishra]

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  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  *On Behalf Of * Gyan Mishra
> *Sent:* Monday, May 30, 2022 10:15 AM
> *To:* Rabadan, Jorge (Nokia - US/Sunnyvale) 
> *Cc:* Alexander Vainshtein ; Andrew Alston
> - IETF ; SPRING WG <
> spr...@ietf.org>; Stewart Bryant ; bess@ietf.org;
> mpls-chairs ; 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  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  on behalf of Alexander Vainshtein <
> alexander.vainsht...@rbbn.com>
> *Date: *Monday, May 30, 2022 at 10:58 AM
> *To: *Stewart Bryant , Andrew Alston - IETF
> , mpls-chairs <
> mpls-cha...@ietf.org>
> *Cc: *SPRING WG , p...@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 

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

[Susan Hares]

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  On Behalf Of Gyan Mishra
Sent: Monday, May 30, 2022 10:15 AM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) 
Cc: Alexander Vainshtein ; Andrew Alston - IETF 
; SPRING WG ; 
Stewart Bryant ; bess@ietf.org; mpls-chairs 
; 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 develop
External (hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>)
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzMzMmI5YzMyNGYyYzFlOWE5OWJkNTQ2NzBjZDdkZjViLzE2NTM5MjAxMjIuMjY=#key=b487f5e33b3e71ad7a5ea7c093bbbe1e>
  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, 
Powered by INKY<https://www.inky.com/protection-by-inky>

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<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org=h.eJwdjkkSgyAUBa9isQ4yOAVXXuUzOJSgFnwWSSp3j2T7ul5Xf0iOnowVWRGvNDJmAQEjmN3FenM412dcmD0NWzF4ZiPMSMtOtUuJ6uWiIXvcDCSknJNHRfaiOxzeR8G7Z6-EZGmF6NJ02PdamzOwppFamUa2szTCKVBK267tB27sYOdOM9F3jZJcSFnLvljdPxJeoHOCJYVpCbD5IivU3vTI3n9_7tZBqQ.MEYCIQDfhOOcv9FhhdL2wFs1ZW8PQJ1KCM5D9k0UtnGntLsorgIhAM84VHp_cXWEe0KSfNLOlybWeUZwJkeDb5_AgR2n0BGS>


BGP Multicast Controller

https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-3.1.1<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org=h.eJwdjsuuAiEQBX_F4PYCAzijuPJXGuh5RB4GehZX478rbk8lVefF9hrZ9cBWoke7ShmAgCr4O1axIc2i1EWG4uVKKcpQYSbed-6wNe6WB097pM1DI-5LplpixMoHe2zoaSuZG6GEYn8Hdu-djPQ1qmG8TFZp2Vao2G45PFfhS5LGaGe90adZe4UWrHVhPE3nwYdzmEcn1TQaqweltdBTt-LvPfyD2xssLd2WBFvssk7Dl-Y9xvcHl25KWQ.MEUCIH6-JwGuxYLr0U1jJqAga1x40O7lToI2S2frDHepEXpgAiEAtM5_58EI06bGnhjzUcNJGGjNvO-JdOanWfex6-_NcmU>



Kind Regards

Gyan

On Mon, May 30, 2022 at 9:56 AM Gyan Mishra 
mailto: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<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org=h.eJwdzk0OgyAYRdGtNIwbEBAojtzKx58YQRvAQdt075WOT97N-6CzJDTdUGztWSdCHDRoBezmC159C_goC3GHJbHlREqwalQc3W9o66vdt8vpIB5SU0ZqhOLrvLt3xPbIhHNmtOVsDMxSr0Fr48Qo1WCdckEYQqXgmg2UMcxkr_r_F3iBOSssNc9LhjX1WFd36X6m9P0BtEE4Aw.MEUCIQCJrSZ8izU747PiiOjZCrMN6-1EwgcwJVO0fMvalJKv5wIgKq-MUg37KTH6DlpVt6EFO-LGQ94ykGiaks-MQ6KWtq4>


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) 
mailto: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 anythin

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

[Jeffrey (Zhaohui) Zhang]

Regarding feature gaps, I’d like to point to 
https://datatracker.ietf.org/doc/html/draft-zzhang-pals-pw-for-ip-udp-payload-01
 for a new kind of PW.
I had not got to socialize it in PALS/MPLS WG and will fill in the signaling 
details in the next revision (yes, EVPN-VPWS type of signaling is what I am 
thinking of).
Looks like this is a good email thread to tag on for my topic.

Appreciate your comments.

Thanks.
Jeffrey



Juniper Business Use Only
From: BESS  On Behalf Of Christian Schmutzer (cschmutz)
Sent: Saturday, June 4, 2022 1:35 AM
To: mpls-chairs ; p...@ietf.org; bess@ietf.org; SPRING WG 

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

[External Email. Be cautious of content]



On 01.06.2022, at 09:42, Christian Schmutzer (cschmutz) 
mailto:cschm...@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<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple__;!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7RvgObuTe$>.

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<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple-vpws-signalling__;!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7Rn59D532$>.
 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 
mailto:ketant.i...@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 
mailto:alexander.vainsht...@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://urldefense.com/v3/__https:/www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml*pwe3-parameters-2__;Iw!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7Rqbfe_ps$>)

 *   Not sure if all these types are relevant for the industry today
 *   AFAIK, TDM and SONET over packet are still widely deployed

  1.  Differentiation between Raw and Tagged Ethernet PW types (not sure it is 
needed, but still)
  2.  All Interface Attributes listed in the IANA registry with the following 
exclusions:

 *   Interface MTU  (EVPN VPWS supports a standard way to ignore it which 
IMHO is one great advantage over LDP-based signaling)
 *   Flow Label (support is defined in 7432bis)

  1.  Full-blown PW status signaling
  2.  FCS retention – not sure it is used these days
  3.  PW fragmentation and reassembly - not sure it is used these days.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>

From: Rabadan, Jorge (Nokia - US/Sunnyvale) 
mailto:jorge.raba...@nokia.com>>
Sent: Monday, May 30, 2022 1:02 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; Stewart 
Bryant mailto:stewart.bry...@gmail.com>>; Andrew 
Alston - IETF 
mailto:40liquid.t...@dmarc.ietf.org>>;
 mpls-chairs mailto:mpls-cha...@ietf.org>>
Cc: SPRING WG mailto:spr...@iet

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

[Christian Schmutzer (cschmutz)]

On 01.06.2022, at 09:42, Christian Schmutzer (cschmutz) 
mailto:cschm...@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 
mailto:ketant.i...@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 
mailto:alexander.vainsht...@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)
 *   Not sure if all these types are relevant for the industry today
 *   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:
 *   Interface MTU  (EVPN VPWS supports a standard way to ignore it which 
IMHO is one great advantage over LDP-based signaling)
 *   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.vainsht...@rbbn.com

From: Rabadan, Jorge (Nokia - US/Sunnyvale) 
mailto:jorge.raba...@nokia.com>>
Sent: Monday, May 30, 2022 1:02 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; Stewart 
Bryant mailto:stewart.bry...@gmail.com>>; Andrew 
Alston - IETF 
mailto:40liquid.t...@dmarc.ietf.org>>;
 mpls-chairs mailto:mpls-cha...@ietf.org>>
Cc: SPRING WG mailto:spr...@ietf.org>>; 
p...@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 mailto:pals-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, May 30, 2022 at 10:58 AM
To: Stewart Bryant mailto:stewart.bry...@gmail.com>>, 
Andrew Alston - IETF 
mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>,
 mpls-chairs mailto:mpls-cha...@ietf.org>>
Cc: SPRING WG mailto:spr...@ietf.org>>, 
p...@ietf.org mailto:p...@ietf.org>>, 
bess@ietf.org mailto: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 

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

[Jeff Tantsura]

+1 Jorge at all. I don’t foresee significant additions to RFC 8214, most legacy PALS stuff doesn’t need to be resurrected.  However - If there’s appetite for IGP extensions for signaling PW (in spirit of SR)) and  (rather than using LDP)  there’s that – “Method and apparatus for pseudo-wire setup and maintenance using intermediate system to intermediate system (IS-IS)” – US patent 10454819  Cheers,Jeff From: Ketan TalaulikarSent: Tuesday, May 31, 2022 9:52 AMTo: Alexander VainshteinCc: Rabadan, Jorge (Nokia - US/Sunnyvale); Andrew Alston - IETF; mpls-chairs; Stewart Bryant; SPRING WG; p...@ietf.org; bess@ietf.orgSubject: Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR + 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.vainsht...@rbbn.com> wrote:Jorge and all,Here is a (admittedly incomplete) list of things that, AFAIK, today are not supported with EVPN VPWS:All the non-Ethernet PW types (28 such types can be found in the IANA registry)Not sure if all these types are relevant for the industry todayAFAIK, TDM and SONET over packet are still widely deployedDifferentiation between Raw and Tagged Ethernet PW types (not sure it is needed, but still)All Interface Attributes listed in the IANA registry with the following exclusions:Interface MTU  (EVPN VPWS supports a standard way to ignore it which IMHO is one great advantage over LDP-based signaling)Flow Label (support is defined in 7432bis)Full-blown PW status signaling FCS retention – not sure it is used these daysPW fragmentation and reassembly - not sure it is used these days. Regards,Sasha Office: +972-39266302Cell:  +972-549266302Email:   alexander.vainsht...@rbbn.com From: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com> Sent: Monday, May 30, 2022 1:02 PMTo: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Stewart Bryant <stewart.bry...@gmail.com>; Andrew Alston - IETF 40liquid.t...@dmarc.ietf.org>; mpls-chairs <mpls-cha...@ietf.org>Cc: SPRING WG <spr...@ietf.org>; p...@ietf.org; bess@ietf.orgSubject: 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-boun...@ietf.org> on behalf of Alexander Vainshtein <alexander.vainsht...@rbbn.com>Date: Monday, May 30, 2022 at 10:58 AMTo: 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 SRStewart, 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).   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). 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-39266302Cell:  +972-549266302Email:   alexander.vainsht...@rbbn.com From: Pals <pals-boun...@ietf.org> On Behalf Of Stewart BryantSent: Monday, May 30, 2022 11:10 AMTo: 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=40liqui

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

[Ketan Talaulikar]

+ 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.vainsht...@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
>
> 
>)
>   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.vainsht...@rbbn.com
>
>
>
> *From:* Rabadan, Jorge (Nokia - US/Sunnyvale) 
> *Sent:* Monday, May 30, 2022 1:02 PM
> *To:* Alexander Vainshtein ; Stewart
> Bryant ; Andrew Alston - IETF  40liquid.t...@dmarc.ietf.org>; mpls-chairs 
> *Cc:* SPRING WG ; p...@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  on behalf of Alexander Vainshtein <
> alexander.vainsht...@rbbn.com>
> *Date: *Monday, May 30, 2022 at 10:58 AM
> *To: *Stewart Bryant , Andrew Alston - IETF <
> andrew-ietf=40liquid.t...@dmarc.ietf.org>, mpls-chairs <
> mpls-cha...@ietf.org>
> *Cc: *SPRING WG , p...@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
> ).
>
>
>
>
> 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
> 
> ).
>
>
>
> 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  *On Behalf Of *Stewart Bryant
> *Sent:* Monday, May 30, 2022 11:10 AM
> *To:* Andrew Alston - IETF ;
> p...@ietf.org; mpls-chairs 
> *Cc:* SPRING WG 
> *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 

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

[Alexander Vainshtein]

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)
 *   Not sure if all these types are relevant for the industry today
 *   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:
 *   Interface MTU  (EVPN VPWS supports a standard way to ignore it which 
IMHO is one great advantage over LDP-based signaling)
 *   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.vainsht...@rbbn.com

From: Rabadan, Jorge (Nokia - US/Sunnyvale) 
Sent: Monday, May 30, 2022 1:02 PM
To: Alexander Vainshtein ; Stewart Bryant 
; Andrew Alston - IETF 
; mpls-chairs 
Cc: SPRING WG ; p...@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 mailto:pals-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, May 30, 2022 at 10:58 AM
To: Stewart Bryant mailto:stewart.bry...@gmail.com>>, 
Andrew Alston - IETF 
mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>,
 mpls-chairs mailto:mpls-cha...@ietf.org>>
Cc: SPRING WG mailto:spr...@ietf.org>>, 
p...@ietf.org mailto:p...@ietf.org>>, 
bess@ietf.org mailto: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).

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).

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 mailto:pals-boun...@ietf.org>> On Behalf Of 
Stewart Bryant
Sent: Monday, May 30, 2022 11:10 AM
To: Andrew Alston - IETF 
mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>;
 p...@ietf.org; mpls-chairs 
mailto:mpls-cha...@ietf.org>>
Cc: SPRING WG mailto: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 
mailto: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 

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

[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 option for replacing mLDP 
without a serious overhaul of the existing networks while at the same time 
being forward-compatible with the external controller if/when such a controller 
is deployed.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com

From: Gyan Mishra 
Sent: Monday, May 30, 2022 5:15 PM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) 
Cc: Alexander Vainshtein ; Andrew Alston - IETF 
; SPRING WG ; 
Stewart Bryant ; bess@ietf.org; mpls-chairs 
; p...@ietf.org
Subject: Re: [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 
mailto: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) 
mailto: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 mailto:pals-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, May 30, 2022 at 10:58 AM
To: Stewart Bryant mailto:stewart.bry...@gmail.com>>, 
Andrew Alston - IETF 
mailto:40liquid.t...@dmarc.ietf.org>>,
 mpls-chairs mailto:mpls-cha...@ietf.org>>
Cc: SPRING WG mailto:spr...@ietf.org>>, 
p...@ietf.org mailto:p...@ietf.org>>, 
bess@ietf.org mailto: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).

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

[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 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  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  on behalf of Alexander Vainshtein <
>> alexander.vainsht...@rbbn.com>
>> *Date: *Monday, May 30, 2022 at 10:58 AM
>> *To: *Stewart Bryant , Andrew Alston - IETF
>> , mpls-chairs <
>> mpls-cha...@ietf.org>
>> *Cc: *SPRING WG , p...@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
>> ).
>>
>>
>>
>> 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
>> ).
>>
>>
>>
>> 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  *On Behalf Of *Stewart Bryant
>> *Sent:* Monday, May 30, 2022 11:10 AM
>> *To:* Andrew Alston - IETF ;
>> p...@ietf.org; mpls-chairs 
>> *Cc:* SPRING WG 
>> *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

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

[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 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  on behalf of Alexander Vainshtein <
> alexander.vainsht...@rbbn.com>
> *Date: *Monday, May 30, 2022 at 10:58 AM
> *To: *Stewart Bryant , Andrew Alston - IETF
> , mpls-chairs <
> mpls-cha...@ietf.org>
> *Cc: *SPRING WG , p...@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
> ).
>
>
>
> 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
> ).
>
>
>
> 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  *On Behalf Of *Stewart Bryant
> *Sent:* Monday, May 30, 2022 11:10 AM
> *To:* Andrew Alston - IETF ;
> p...@ietf.org; mpls-chairs 
> *Cc:* SPRING WG 
> *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.
>

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

[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 EVPN VPWS is not an option.

Thanks,
Jorge


From: Pals  on behalf of Alexander Vainshtein 

Date: Monday, May 30, 2022 at 10:58 AM
To: Stewart Bryant , Andrew Alston - IETF 
, mpls-chairs 
Cc: SPRING WG , p...@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).

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).

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  On Behalf Of Stewart Bryant
Sent: Monday, May 30, 2022 11:10 AM
To: Andrew Alston - IETF ; 
p...@ietf.org; mpls-chairs 
Cc: SPRING WG 
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 
mailto: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