Re: [Pals] IP-VPN without IP/UDP header transportation

["Andrew G. Malis" <[e-mail]>]

Jeffrey,

Thanks for the update! After having read the new draft, I completely agree.

Cheers,
Andy


On Mon, Jul 11, 2022 at 8:19 AM Jeffrey (Zhaohui) Zhang <zzhang=
[e-mail]> wrote:

> [changing subject]
>
>
>
> Hi,
>
>
>
> After filling in the signaling procedures for
> draft-zzhang-pals-pw-for-ip-udp-payload, we feel that BESS is a better home
> for the draft, so we rehomed it to BESS:
> https://datatracker.ietf.org/doc/draft-zzhang-bess-ipvpn-payload-only/.
>
>
>
> Of course, it still benefits discussions in PALS/MPLS WG.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Jeffrey (Zhaohui) Zhang
> *Sent:* Wednesday, June 22, 2022 4:30 PM
> *To:* Christian Schmutzer (cschmutz) <cschmutz=[e-mail]>;
> mpls-chairs <[e-mail]>; [e-mail]; [e-mail]; SPRING
> WG <[e-mail]>
> *Cc:* '[e-mail]' <[e-mail]>
> *Subject:* RE: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires
> and SR
>
>
>
> 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 <[e-mail]> *On Behalf Of *Christian Schmutzer
> (cschmutz)
> *Sent:* Saturday, June 4, 2022 1:35 AM
> *To:* mpls-chairs <[e-mail]>; [e-mail]; [e-mail];
> SPRING WG <[e-mail]>
> *Subject:* Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires
> and SR
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> <Resending with trimmed to/cc list to try to pass the BESS recipient
> restriction>
>
>
>
> On 01.06.2022, at 09:42, Christian Schmutzer (cschmutz) <
> [e-mail]> 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 <[e-mail]> 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 <
> [e-mail]> 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$>
>    )
>
>
>    1. Not sure if all these types are relevant for the industry today
>       2. 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:
>
>
>    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)
>
>
>    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: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]>
> *Sent:* Monday, May 30, 2022 1:02 PM
> *To:* Alexander Vainshtein <[e-mail]>; Stewart
> Bryant <[e-mail]>; Andrew Alston - IETF <andrew-ietf=
> [e-mail]>; mpls-chairs <[e-mail]>
> *Cc:* SPRING WG <[e-mail]>; [e-mail]; [e-mail]
> *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 <[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://urldefense.com/v3/__https:/clicktime.symantec.com/3Qviu2KUub4f1w6MeHVbgcu6H4?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8214__;JSUlJSUl!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7Ro3QiEqc$>).
>
>
>
>
> 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://urldefense.com/v3/__https:/clicktime.symantec.com/32Jf7wnYMxKQPc3r3RR9Cy96H4?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc4720__;JSUlJSUl!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7RrpsbXYX$>
> ).
>
>
>
> 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
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3Dg1AP6FnSDeshweMg29hXi7GS?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7RmTzmP3Q$>
>
>
> 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.
>
>
> 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.
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7RoJPjo72$>
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!DlYfLfhLreAoyF1YRUnoLvSQMd3DO8AOA4GFDdsQmL4gqY9Q3BySRnQHgGTXedeK_UEpQvd1hOyKvv0AF1V4NR_7RoJPjo72$>
>
>
>
>
> _______________________________________________
> Pals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pals
>