From nobody Thu Jul 7 20:15:09 2022 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7C1C15AB4B; Thu, 7 Jul 2022 20:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIy3IuyNE1FV; Thu, 7 Jul 2022 20:14:57 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95A9C15AB40; Thu, 7 Jul 2022 20:14:57 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id x184so9067221pfx.2; Thu, 07 Jul 2022 20:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X2aCFiHWdJOI5lNxqkdFo0B4ymkJN5oZwGqk/QGwyhw=; b=KS2SBBmeglKdrLzI+inMpNNIpiGKQ4Mi5W8LlFSznXNuJcJfCQLCZ2q6uJMtJMGJTn wNOwFpuUHjnBOvQumzPvV96LnFNnSUZqss3E1ib4HqasP7WbxaR7EbLUkhiDpGTv48Gu zGsLqiL/k6kV984tXZgI1AScQwc5vP6ZROV1uuMfaSq+oaPwHwK5s+f3bOcz4KYrUH/H lF7+m2N8iY/qz31hzoXN/tTBZhkr8HlH81+gs833HfiI3KacUPrqFkKkQ8BlQfc5u+K9 tmJMIZwcctqwSVzaTokzom+22tJnTaPmBCZJmJP1CPbDxiBLSLy/+fxF/zCp79wcSRA4 KWIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X2aCFiHWdJOI5lNxqkdFo0B4ymkJN5oZwGqk/QGwyhw=; b=y8WoJiQarOAh4O76w4yqdoswhO4lOvh4WxvS7X5Zb2Wpy00cjG9wE5tifOZyuy3WkU C352/IkiZZN2nAqAY4BAOmHYd1C+nbL20YD4rC17GhcZ4uGkUjIij+OWAnLd5de14L4f DZC5rTt/46spbqRThs8og3yt8QihEgj0zXlhbDE1+gmiP7kcgugC0YO6MSGiy46/jjck Pm1aUBU0dK8Hf0z6V7GsoXPcjDBBFvMJwU+49q5IveEVO5Ne7+0+NEC+H56RVbU7lYRE U0uTzk/6sLckmUS+DSLJGOJO+I2+uMZITYxBw1DS89A8TNUhpxaR4N/5RFDZNO5XyqLe cgWA== X-Gm-Message-State: AJIora+pb9NdKyBC/tzkc7OY0qb1xKP/oVbYGXUBSV0F8Wuok7xczA0I N0SIFv+y97Prw3y2R5HfMBpFXQtQ4bHTtO0/HL1oiyzn X-Google-Smtp-Source: AGRyM1vHKW80og2zedOwmbGmlHmgGxIBLywNFJte+whhRRXNLDlCmpHui8siQRhhylwd5zq4ITOBgelWiudBKtKl4DA= X-Received: by 2002:a63:1843:0:b0:412:6ea5:ac5c with SMTP id 3-20020a631843000000b004126ea5ac5cmr1277158pgy.366.1657250096859; Thu, 07 Jul 2022 20:14:56 -0700 (PDT) MIME-Version: 1.0 References: <51706C42-15E2-442D-916E-627769062F22@gmail.com> In-Reply-To: From: Gyan Mishra Date: Thu, 7 Jul 2022 23:14:45 -0400 Message-ID: To: Susan Hares Cc: Alexander Vainshtein , Andrew Alston - IETF , "Rabadan, Jorge (Nokia - US/Sunnyvale)" , SPRING WG , Stewart Bryant , "bess@ietf.org" , mpls-chairs , "pals@ietf.org" Content-Type: multipart/alternative; boundary="00000000000053d3c305e3429be7" Archived-At: Subject: Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini Pseudowires and SR X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2022 03:15:02 -0000 --00000000000053d3c305e3429be7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 > > > > > 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 < > spring@ietf.org>; Stewart Bryant ; bess@ietf.or= g; > mpls-chairs ; pals@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 o= n > 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 ba= nd > 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-contr= oller-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 an= y > 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=E2=80=99s no longer used for Unicast application flows once all unicas= t is > migrated to Segment Routing and selectively allows the per application SA= C > capabilities know to keep the applications requiring LDP to continue to u= se > 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 fro= m > the network. > > > > Thanks > > > > Gyan > > > > On Mon, May 30, 2022 at 6:02 AM Rabadan, Jorge (Nokia - US/Sunnyvale) < > jorge.rabadan@nokia.com> wrote: > > I concur with Sasha. > > We=E2=80=99ve 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.Vainshtein@rbbn.com> > *Date: *Monday, May 30, 2022 at 10:58 AM > *To: *Stewart Bryant , Andrew Alston - IETF > , mpls-chairs < > mpls-chairs@ietf.org> > *Cc: *SPRING WG , pals@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 carr= y > non-Ethernet customer traffic as well as support of some features that ca= n > be signaled via LDP for Ethernet PWs but cannot be signaled today with > EVPN-VPWS (e.g., FCS retention =E2=80=93 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.Vainshtein@rbbn.com > > > > *From:* Pals *On Behalf Of *Stewart Bryant > *Sent:* Monday, May 30, 2022 11:10 AM > *To:* Andrew Alston - IETF ; > pals@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 tha= t > you end up going through the PW development cycle again as old requiremen= ts > re-emerge. > > > > Stewart > > > > > > > > Sent from my iPad > > > > On 30 May 2022, at 07:22, Andrew Alston - IETF < > andrew-ietf=3D40liquid.tech@dmarc.ietf.org> wrote: > > =EF=BB=BF > > 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=E2=80=99t 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 =E2=80=93 both compat= ible with > IPv4 and IPv6 =E2=80=93 that simply exists to setup and tear down the ser= vice > labels for point to point services. A form of targeted LDP without all t= he > other complexities involved in LDP =E2=80=93 that could potentially run a= t 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 thi= s > 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 an= d > see if we can find a solution. > > > > Looking forward to hearing from you all > > > > Thanks > > > > Andrew > > > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > > https://clicktime.symantec.com/3Dg1AP6FnSDeshweMg29hXi7GS?u=3Dhttps%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 copie= s, > 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 copie= s, > including any attachments. > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000053d3c305e3429be7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Susan

Thanks for the heads up.

I will look out for the WG LC in IDR and BESS.
<= br>
Kind Regards=C2=A0

Gyan

On Thu, Jul 7, 2022 at 7:40 PM Susan Hares &= lt;shares@ndzh.com> wrote:

Gyan:

=C2=A0

IDR WG have also adopted

=C2=A0

= draft-ietf-idr-sr-p2mp-policy-00

=C2=A0

Jeffrey Zhang has joined as co-author.=

Work is undergoing in the author group

To help align it to other work.

=C2=A0

It will be WG LC in IDR and BESS.

=C2=A0

Cheers, Sue

=C2=A0

=C2=A0

Fro= m: BESS <= bess-bounces@ietf.org> On Behalf Of Gyan Mishra
Sent: Monday, May 30, 2022 10:15 AM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.rabadan@nokia.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Andrew A= lston - IETF <andrew-ietf=3D40liquid.tech@dmarc.ietf.org>; SPRING WG <<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org>= ; Stewart Bryant <stewart.bryant@gmail.com>; bess@ietf.org; mpls-chairs <mpls-chairs@ietf.org>; pals@ietf.org
Subject: Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowir= es and SR

=C2=A0

=C2=A0

Other options for operators migrating to SR for Mult= icast P-Tree which is still being developed by vendors is BIER which is sta= teless.

=C2=A0

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 =C2=A0for P2P Tree PTA enco= ding.=C2=A0 This is based on BGP MCAST TREE SAFI defined in BGP Multicast draft. This draft provides a more general so= lution and as well supports both mLDP inband and out of band signaling as w= ell as non mLDP based =C2=A0SR use cases.

=C2=A0

BIER RFC 8296 & RFC 8279

=C2=A0

BGP Multicast=C2=A0

=C2=A0

=C2=A0

BGP Multicast Controller=C2=A0

=C2=A0

=C2=A0

=C2=A0

Kind Regards=C2=A0

=C2=A0

Gyan

=C2=A0

On Mon, May 30, 2022 at 9:56 AM Gyan Mishra <hayabusagsm@gmail.co= m> wrote:

I agree with Saha and Jorge as I stated in my respon= se that the directional choice for use cases VPLS =C2=A0E-Line, E-LAN, E-Tr= ee signaling is to transition off LDP to BGP based signaling processing usi= ng EVPN for any L2 VPN use cases when migrating to Segment Routing both SR-MPLS and SRv6.

=C2=A0

As I mentioned in my initial response, part of the t= ransition 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 =C2=A0customers using T-DP for signaling and MVPN PTA application P= TA mLDP P2MP and MP2MP. =C2=A0

=C2=A0

This knob allows the ability to create a slimmed dow= n profile of LDP so it=E2=80=99s no longer used for Unicast application flo= ws once all unicast is migrated to Segment Routing and selectively allows t= he per application SAC capabilities know to keep the applications requiring LDP to continue to use until the applicati= on has migrated off LDP.

=C2=A0

For multicast solutions operators have the option of= TREE SID which uses the Replication SID in SR P2MP policy which has been i= mplemented by most vendors.

=C2=A0

RFC 7473 SAC knob=C2=A0

=C2=A0

Once all applications are migrated off LDP, LDP can = be safely removed from the network.

=C2=A0

Thanks=C2=A0

=C2=A0

Gyan

=C2=A0

On Mon, May 30, 2022 at 6:02 AM Rabadan, Jorge (Noki= a - US/Sunnyvale) <jorge.rabadan@nokia.com> wrote:

I concur with Sasha.

We=E2=80=99ve 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 VP= WS (if needed). If not an option, it would good to discuss at least why EVP= N VPWS is not an option.

=C2=A0

Thanks,

Jorge

=C2=A0

=C2=A0

From: Pals <pals-bounces@ietf.org> on behalf of Alex= ander Vainshtein <Alexander.Vainshtein@rbbn.com>
Date: Monday, May 30, 2022 at 10:58 AM
To: Stewart Bryant <stewart.bryant@gmail.com>, Andrew Alston - IETF <= ;andrew-ietf=3D40liquid.tech@dmarc.ietf.org>, mpls-chairs <mpls-chairs@ietf.org>
Cc: SPRING WG <spring@ietf.org>, pals@ietf.org <pa= ls@ietf.org>, bess@ietf.org <be= ss@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-b= ased environment is quite problematic for the operators.

=C2=A0

One alternative is transition to setup of PWs using MP BGP based on the EVP= N-VPWS mechanisms (RFC 8214). =C2=A0

=C2=A0

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 =E2=80=93 RFC 4720).

=C2=A0

My guess is that, once the basic EVPN-VPWS signaling is supported, migratio= n of LDP-signaled PWs to EVPN-VPWS would be simple enough.

=C2=A0

This work, if approved, would require intensive cooperation between PALS WG= and BESS WG.

=C2=A0

My 2c,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0 Alexander.Vainshtein@rbbn.com

=C2=A0

From: Pals <pals-bounces@ietf.org> On Behalf Of Stewart Bryant
Sent: Monday, May 30, 2022 11:10 AM
To: Andrew Alston - IETF <andrew-ietf=3D40liquid.tech@dmarc.ietf.org&g= t;; pals@ietf.org; mpls-= chairs <mpls-c= hairs@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: [EXTERNAL] Re: [Pals] [spring] Martini Pseudowires and SR

=C2=A0

Including the PALS and MPLS WGs in the discussion.

=C2=A0

In the case of PWs, LDP runs directly between the T-PEs to provide the cont= rol 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, bu= t this does not necessarily need a standard.

=C2=A0

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 e= nd up going through the PW development cycle again as old requirements re-e= merge.

=C2=A0

Stewart

=C2=A0

=C2=A0

=C2=A0

Sent from my iPad



On 30 May 2022, at 07:22, Andrew Alston - IETF <andrew-ietf=3D40liq= uid.tech@dmarc.ietf.org> wrote:

=EF=BB=BF

Hi All,

=C2=A0

Sending this email wearing only the hat of a working group participant.<= /u>

=C2=A0

One of the things that our network uses, and is used by so many networks ou= t there, are martini based pseudowires (which for clarity are generally set= up using what is described in RFC8077).=C2=A0 In an SR world however, this = creates a problem, because typically you don=E2=80=99t want to run LDP in an SR context.=C2=A0 This means that = standard martini pseudowires no longer function.=C2=A0 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.

=C2=A0

This is also relevant in cases where networks wish to run SR-MPLS in the ab= sence of SRv6 for whatever reason.

=C2=A0

So, my question to the working group is this:

=C2=A0

Is it worth looking at creating a form of LDP light =E2=80=93 both compatib= le with IPv4 and IPv6 =E2=80=93 that simply exists to setup and tear down t= he service labels for point to point services.=C2=A0 A form of targeted LDP= without all the other complexities involved in LDP =E2=80=93 that could potentially run at a lower preference than LDP itself (so if LD= P is there, use it, if not use this)

=C2=A0

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 cal= l for expressions of interest in those who may be willing to work towards s= omething like this.=C2=A0 Happy to take emails on list or off list and see if we can find a solution.

=C2=A0

Looking forward to hearing from you all

=C2=A0

Thanks

=C2=A0

Andrew

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org h= ttps://clicktime.symantec.com/3Dg1AP6FnSDeshweMg29hXi7GS?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring


Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. and its Affiliates that is confidential and/or= proprietary for the sole use of the intended recipient. Any review, disclo= sure, 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 a= nd then delete all copies, including any attachments.


Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. and its Affiliates that is confidential and/or= proprietary for the sole use of the intended recipient. Any review, disclo= sure, 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 a= nd then delete all copies, including any attachments.

_______________________________________________
Pals mailing list
Pals@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pals

--

<= /span>

Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishr= a@verizon.com

M 301 = 502-1347

=C2=A0

--

<= /span>

Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishr= a@verizon.com

M 301 = 502-1347

=C2=A0

--
--00000000000053d3c305e3429be7--