From nobody Sat Apr 1 10:54:11 2023 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 DA429C14F748; Sat, 1 Apr 2023 10:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 AW3vKKoHKzIp; Sat, 1 Apr 2023 10:54:04 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 4DD1DC14EB17; Sat, 1 Apr 2023 10:54:04 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id c1so21907170vsk.2; Sat, 01 Apr 2023 10:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680371643; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=43eluOWeNM04EW82jmsI2csAxXhmZDHxJEjD0oAHhZM=; b=bULMeIa1smSqtetGoemaP4zuXVxVDM5SM1rCDzXJ1i/G0LFVZFGjm9oGPLhsswzVeW 0Dxdeh5jaBS8BiPcePFf8L/JW5qGTGiLqioIzUjQ9DDYRg0cG0FwpJpytbELdncc8vPM CNJfZ6hQ/a2LEXgljdte+pIfkEfB9xUAeuCWALWRz+4IT0YHZfMIFPDvTMf7FtM5oMKR kzMBcipYy0uTQE/hRVDpHJ0rpyz7Y3vz/ZekbYErCQdWk7FbPs+GPZunQlaMETuh3wOF dEUbxsgzXYGMRAoOE7wXLX0XBxiCDmLAG55SoXGWXgFss9y3zDzzBBEhI/y4xtEzQqqh Bpqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680371643; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=43eluOWeNM04EW82jmsI2csAxXhmZDHxJEjD0oAHhZM=; b=tx6fhv4UrHNRNLLvRt60CyrKyYY1RyeN7mL2elbzwjZ1czIreba52KQxCbrCszyaDm U2zSSCcwx9KMfzVL7K3wwFuEp/+ev6+9HWdx3lAG7Qu9M6Zmfn5LH19OC17ll5DwivZe E4w4tjnqMNjiy58RYYq5T4Yr6aFyHLLbfBWAoOnXFpEyISJcDEQXlfyb5bkf8kq3qEtH aRNI29qSJnTUmwxbTKYdzFlfafGke/VmRyhtbjGnGjB8HeveTUr204PkoYuAMFaAaLqc 6sqBsYWL5Ohg3XrfSmsuV341a0iQjT0Qy27PQaAoOzfX24FuHPrTN7SoyNKW4cY57985 T/yQ== X-Gm-Message-State: AAQBX9eanraGDckMf0rtq4Z+oHWKs/MJQM8dg386DmUyjS55yiiAV97+ /7Ndnj6mujAEDCRVFN0chxPQ9leffsn5J43KLfE4/645Dvg= X-Google-Smtp-Source: AKy350bbKN8i9UaDxHvoVb8I/ZBq6Tkrma8mzl0jOffNp5YrMbj2cKzvKxeYWwEL+Usk90IaaQX+LWUMGcloRZXXwQM= X-Received: by 2002:a67:d38a:0:b0:425:f1d7:79f7 with SMTP id b10-20020a67d38a000000b00425f1d779f7mr15983398vsj.1.1680371643269; Sat, 01 Apr 2023 10:54:03 -0700 (PDT) MIME-Version: 1.0 References: <072001d9611c$622fd220$268f7660$@olddog.co.uk> <6F3EACD5-5AAC-477A-BB26-F50C4C115BB7@juniper.net> <63276c1a-33d7-7cdc-28ad-6c627ae75a67@gmail.com> In-Reply-To: <63276c1a-33d7-7cdc-28ad-6c627ae75a67@gmail.com> From: Tony Przygienda Date: Sat, 1 Apr 2023 19:53:26 +0200 Message-ID: To: Brian E Carpenter Cc: Ron Bonica , Krzysztof Szarkowicz , Kireeti Kompella , "spring@ietf.org" , "int-area@ietf.org" , Andrew Alston - IETF Content-Type: multipart/alternative; boundary="000000000000e349fd05f84a0228" Archived-At: Subject: Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt 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: Sat, 01 Apr 2023 17:54:09 -0000 --000000000000e349fd05f84a0228 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ? I heard the argument that IPv6 address space is large and "easy to carve up to mean other things" since about as long IPv6 started to gain traction. The wisdom of that has been thankfully so far questioned. BIER was also approached by people who hoped we would create a precedent by taking a /8 or /16 or something and use the rest of bits to stick bitmasks in. Expediency overriding architecture and all that usual jazz ... Yes, it's easy to "quickly deploy" and taken to the bitter conclusion we'll stop having a decently economic, secure and debuggable IP forwarding path, instead we end up building IP host address firewall scanning things into layer 4 to find violations in complex constructs masquerading under addresses and IP "extension headers" and build lots of "kind of limited but not so limited and kind of secur'ish domains". Firewalls have their place but routers are not firewalls. -- tony On Fri, Mar 31, 2023 at 9:00=E2=80=AFPM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 01-Apr-23 06:18, Ron Bonica wrote: > > On second thought, if we had the new ethertype, we wouldn=E2=80=99t nee= d the new > /16! > > > > They serve the same function > > However, a new special-purpose prefix is rather trivial to deploy compare= d > with a new Ethertype. > > Brian > > > > > > Ron > > > > *From:* Ron Bonica > > *Sent:* Friday, March 31, 2023 1:05 PM > > *To:* Krzysztof Szarkowicz = ; > Kireeti Kompella > > *Cc:* Adrian Farrel ; Andrew Alston - IETF > ; int-area@ietf.org; > spring@ietf.org; Dr. Tony Przygienda > > *Subject:* RE: [spring] [Int-area] FW: New Version Notification for > draft-raviolli-intarea-trusted-domain-srv6-00.txt > > > > +1 > > > > If we allocate a /16 for SRv6 USIDs, as proposed in > https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt < > https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt>, > > > > we can allow that prefix only when the new ethertype is used. > > > > > > Ron > > > > *From:* spring > > *On Behalf Of *Krzysztof Szarkowicz > > *Sent:* Wednesday, March 29, 2023 5:30 AM > > *To:* Kireeti Kompella kireeti.ietf@gmail.com>> > > *Cc:* Adrian Farrel >; > Andrew Alston - IETF andrew-ietf=3D40liquid.tech@dmarc.ietf.org>>; int-area@ietf.org int-area@ietf.org>; spring@ietf.org ; Dr. Tony > Przygienda > > > *Subject:* Re: [spring] [Int-area] FW: New Version Notification for > draft-raviolli-intarea-trusted-domain-srv6-00.txt > > > > *[External Email. Be cautious of content]* > > > > SRv6 packet might have SRH, but might not have SRH. Especially with > uSID, you can craft a decent SR-TE SRv6 packet without SRH. So I think, > Kireetis=E2=80=99 comments should apply to all SRv6 packets (with/without= SRH). > > > > =E2=80=94 > > > > Krzysztof > > > > On 2023 -Mar-29, at 17:57, Tony Przygienda > wrote: > > > > Though I would like to cheer for Kireeti's 2. as well I think the > point of SHOULD is more realistic (for now) as Joel points out ... > > > > As to ethertype, I think grown-ups in the room were since long time > drily observing that a new IP version would have been appropriate after > enough > contortions-of-it's-an-IPv6-address-sometimes-and-sometimes-not-and-somet= imes-only-1/4 > were performed with drafts whose authors' list length sometimes rivaled > pages of content ;-) I think this ship has sailed and that's why after > some discussions with Andrew we went the ether type route as more > realistic. Additionally, yes, lots encaps (not encodings) carrying SRv6 > should get new codepoints if we are really serious about trusted domains > here. > > > > And folks who went the MPLS curve know that none of this is new, > same curve was walked roughly (though smoother, no'one was tempted to "hi= de > label stack in extension headers" ;-) and it would go a long way if > deploying secure SRv6 becomes as simple as *not* switching on "address > family srv6" on an interface until needed and then relying on BGP-LU (oop= s > ;-) to build according lookup FIBs for SRv6 instead of going in direction > of routers becoming massive wildcard matching and routing header processi= ng > firewalls ... > > > > --- tony > > > > On Wed, Mar 29, 2023 at 4:33=E2=80=AFPM Kireeti Kompella < > kireeti.ietf@gmail.com > wrote: > > > > On Mar 28, 2023, at 11:24, Adrian Farrel > wrote: > > > > [Spring cc=E2=80=99ed because, well, you know, SR. I wonder= whether > 6man and 6ops should care as well.] > > > > SPRING cc=E2=80=99ed because, you know, replying to Adrian=E2= =80=99s email. > Agree that 6man and 6ops [sh|w]ould be interested. > > > > tl;dr > > > > I think this is a good initiative and worth discussion. > Thanks > > > > for the draft. > > > > Agree. In particular: > > > > 1. There is an acknowledged security problem. Might be worth > summarizing, as it is central to this draft, but an example is in rfc > 8402/section 8. Section 3 of this draft (=E2=80=9CThe SRv6 Security Probl= em=E2=80=9D) > doesn=E2=80=99t actually describe the security problem; Section 5 does, b= riefly. > > > > 2. The solution (using a new EtherType, SRv6-ET) is a good one. > It=E2=80=99s sad that this wasn=E2=80=99t done from the get-go, as the so= lution is a bit > =E2=80=9Cevil bit=E2=80=9D-ish. I=E2=80=99d prefer to see ALL SRv6 packe= ts (i.e., those containing > SRH) use SRv6-ET. Boundary routers SHOULD drop packets with SRv6-ET that > cross the boundary in either direction; all routers MUST drop packets wit= h > SRH that don=E2=80=99t have SRv6-ET. Yeah, difficult, but the added secur= ity is > worth it. > > > > 3. Ease of secure deployment is a major consideration; this > draft is a big step in that direction. > > > > 4. As Adrian said, several nits. Will send separately to > authors. > > > > Kireeti > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring < > https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__= ;!!NEt6yMaO-gk!GGgCymh1gmvxc7ibG9cWpBOm73ewlZbNJjAA4xw8KNZFBMd9ROvcdT5tCSoo= D-OCMYFWheicbBfDrzfTkoY7bGn7W65rg0E$ > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring < > https://www.ietf.org/mailman/listinfo/spring> > > > > > > Juniper Business Use Only > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > --000000000000e349fd05f84a0228 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
?

I heard the argument = that IPv6 address space is large and "easy to carve up to mean other t= hings" since about as long IPv6 started to gain traction. The wisdom o= f that has been thankfully so far questioned. BIER was also approached by p= eople who hoped we would create a precedent by taking a /8 or /16 or someth= ing and use the rest of bits to stick bitmasks in. Expediency overriding ar= chitecture and all that usual jazz ...

Yes, i= t's easy to "quickly deploy" and taken to the bitter conclusi= on we'll stop having a decently economic, secure and debuggable IP forw= arding path, instead we end up building IP host address firewall scanning t= hings into layer 4 to find violations in complex constructs masquerading un= der addresses and IP "extension headers" and build lots of "= kind of limited but not so limited and kind of secur'ish domains".= Firewalls have their place but routers are not firewalls.=C2=A0
=

-- tony

On Fri, Mar 31, 2023 at 9:00=E2=80= =AFPM Brian E Carpenter <= brian.e.carpenter@gmail.com> wrote:
On 01-Apr-23 06:18, Ron Bonica wrote:
> On second thought, if we had the new ethertype, we wouldn=E2=80=99t ne= ed the new /16!
>
> They serve the same function

However, a new special-purpose prefix is rather trivial to deploy compared = with a new Ethertype.

=C2=A0 =C2=A0 Brian

>
>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron
>
> *From:* Ron Bonica
> *Sent:* Friday, March 31, 2023 1:05 PM
> *To:* Krzysztof Szarkowicz <kszarkowicz=3D40juniper.net@dmarc.ietf.org&g= t;; Kireeti Kompella <kireeti.ietf@gmail.com>
> *Cc:* Adrian Farrel <adrian@olddog.co.uk>; Andrew Alston - IETF <andrew-ie= tf=3D40li= quid.tech@dmarc.ietf.org>; int-area@ietf.org; spring@ietf.org; Dr. Tony Przygienda <tonysietf@gmail.com>
> *Subject:* RE: [spring] [Int-area] FW: New Version Notification for dr= aft-raviolli-intarea-trusted-domain-srv6-00.txt
>
> +1
>
> If we allocate a /16 for SRv6 USIDs, as proposed in https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt= <https://www.ietf.org/archive/id/= draft-ietf-6man-sids-02.txt>,
>
> we can allow that prefix only when the new ethertype is used.
>
>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron
>
> *From:* spring <spring-bounces@ietf.org <mailto:spring-bounces@ietf.org>> *O= n Behalf Of *Krzysztof Szarkowicz
> *Sent:* Wednesday, March 29, 2023 5:30 AM
> *To:* Kireeti Kompella <kireeti.ietf@gmail.com <mailto:kireeti.ietf@gmail.com>><= br> > *Cc:* Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>>; Andrew Alston= - IETF <andrew-ietf=3D40liquid.tech@dmarc.ietf.org <mailto:andrew-ietf=3D40liquid.tech@dmarc.ietf.org>>; int-area@= ietf.org <mailto:int-area@ietf.org>; spring@ietf.org <mailto:spring@ietf.org>; Dr. Tony Przygienda <tonysietf@gmail.com &= lt;mailto:tonysiet= f@gmail.com>>
> *Subject:* Re: [spring] [Int-area] FW: New Version Notification for dr= aft-raviolli-intarea-trusted-domain-srv6-00.txt
>
> *[External Email. Be cautious of content]*
>
> SRv6 packet might have SRH, but might not have SRH. Especially with uS= ID, you can craft a decent SR-TE SRv6 packet without SRH. So I think, Kiree= tis=E2=80=99 comments should apply to all SRv6 packets (with/without SRH).<= br> >
> =E2=80=94
>
> Krzysztof
>
>=C2=A0 =C2=A0 =C2=A0On 2023 -Mar-29, at 17:57, Tony Przygienda <tonysietf@gmail.com <mailto:tonys= ietf@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Though I would like to cheer for Kireeti's 2. a= s well I think the point of SHOULD is more realistic (for now) as Joel poin= ts out ...
>
>=C2=A0 =C2=A0 =C2=A0As to ethertype, I think grown-ups in the room were= since long time drily observing that a new IP version would have been appr= opriate after enough contortions-of-it's-an-IPv6-address-sometimes-and-= sometimes-not-and-sometimes-only-1/4 were performed with drafts whose autho= rs' list length sometimes rivaled pages of content ;-)=C2=A0 I think th= is ship has sailed and that's why after some discussions with Andrew we= went the ether type route as more realistic. Additionally, yes, lots encap= s (not encodings) carrying SRv6 should get new codepoints if we are really = serious about trusted domains here.
>
>=C2=A0 =C2=A0 =C2=A0And folks who went the MPLS curve know that none of= this is new, same curve was walked roughly (though smoother, no'one wa= s tempted to "hide label stack in extension headers" ;-) and it w= ould go a long way if deploying secure SRv6 becomes as simple as *not* swit= ching on "address family srv6" on an interface until needed and t= hen relying on BGP-LU (oops ;-) to build according lookup FIBs for SRv6 ins= tead of going in direction of routers becoming massive wildcard matching an= d routing header processing firewalls ...
>
>=C2=A0 =C2=A0 =C2=A0--- tony
>
>=C2=A0 =C2=A0 =C2=A0On Wed, Mar 29, 2023 at 4:33=E2=80=AFPM Kireeti Kom= pella <kiree= ti.ietf@gmail.com <mailto:kireeti.ietf@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Mar 28, 2023, at 11:24, Adrian Far= rel <adrian@old= dog.co.uk <mailto:adrian@olddog.co.uk>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Spring cc=E2=80=99ed b= ecause, well, you know, SR. I wonder whether 6man and 6ops should care as w= ell.]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SPRING cc=E2=80=99ed because, you kno= w, replying to Adrian=E2=80=99s email.=C2=A0 Agree that 6man and 6ops [sh|w= ]ould be interested.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tl;dr
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think this is a good = initiative and worth discussion. Thanks
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for the draft.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Agree.=C2=A0 In particular:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. There is an acknowledged security = problem. Might be worth summarizing, as it is central to this draft, but an= example is in rfc 8402/section 8. Section 3 of this draft (=E2=80=9CThe SR= v6 Security Problem=E2=80=9D) doesn=E2=80=99t actually describe the securit= y problem; Section 5 does, briefly.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. The solution (using a new EtherTyp= e, SRv6-ET) is a good one.=C2=A0 It=E2=80=99s sad that this wasn=E2=80=99t = done from the get-go, as the solution is a bit =E2=80=9Cevil bit=E2=80=9D-i= sh.=C2=A0 I=E2=80=99d prefer to see ALL SRv6 packets (i.e., those containin= g SRH) use=C2=A0SRv6-ET.=C2=A0 Boundary routers SHOULD drop packets with=C2= =A0SRv6-ET that cross the boundary in either direction; all routers MUST dr= op packets with SRH that don=E2=80=99t have=C2=A0SRv6-ET. Yeah, difficult, = but the added security is worth it.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. Ease of secure deployment is a maj= or consideration; this draft is a big step in that direction.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04. As Adrian said, several nits.=C2= =A0 Will send separately to authors.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Kireeti
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.o= rg/mailman/listinfo/spring <https://urldefense.com/v3/__htt= ps:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!GGgCymh1gmvxc7ibG9= cWpBOm73ewlZbNJjAA4xw8KNZFBMd9ROvcdT5tCSooD-OCMYFWheicbBfDrzfTkoY7bGn7W65rg= 0E$>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0spring mailing list
>=C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/spring <https://www.ietf.org/mailman/listin= fo/spring>
>
>
> Juniper Business Use Only
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/int-area
--000000000000e349fd05f84a0228--