Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A86C12946C for ; Mon, 24 Apr 2017 11:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_enOLhI7uP5 for ; Mon, 24 Apr 2017 11:55:37 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC1812778D for ; Mon, 24 Apr 2017 11:55:37 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id y63so96508806qkd.1 for ; Mon, 24 Apr 2017 11:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=o6gZDQPLOdhw79PJN2NbgVFUcpOoWf3QqSL431MZ7Xs=; b=cgjxmZeohiW9J7tBhFC2vyMdDWM4krp466CqHCHYFauZK49rfescLcEYMyRXpewucQ xfYe7JjdHUxzbf6rHF0XtTqFz7sgNT5RAxVEOVK/LaGc5gKEP0K8Tx6WEgEOuIGTXeqz lHLempyO0rvVBnX7r6V0JddXbGdjeNyvlfwOA8WqA5Uf04oUxxz4pAXVZkr80NAtSrpH e887EzOgxpFQko5cI8YPqzAJyHeph+GxJWAyMzsuvre368NG8OtY4E6omhbw0AEPuDTp Evjo0SEa9iO91g3XGyG+myGXKXWEHFHuSHC4uqi8QTqNSpqtSYjvsqk8lQcIu7pXIqHT VMfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=o6gZDQPLOdhw79PJN2NbgVFUcpOoWf3QqSL431MZ7Xs=; b=T28spIZNOFKvr5v1wgXPg6fFsUH5delIJQ8iO0wJNd0Km/mk+PX7QlS5qLlhpxJKP5 8P7NrwjQD8DF121IX+EJDo+KP85KWpeORqifrBs9f6/K4rtG69xSgRPpRs29ZETbi9F3 9en42PAbkN5XR6ues1dPjONEXeX41VCrIA3bw5ZBhwjSjyfMRR6HyQjqA86FVdJ+rQSs W0dC4ub+CaF6bjpQ+tCQvUWQJP4kUILTTHx4rgCPG7N2twnOlNHSwbIcvWjIDEqWEgWU aZmtVbsYcJMunTD9CoB+lVkeoeibcfYsXcM2tpfSMZMnQX+Gp51vFKcLi4+gGYQBeGJL IkLA== X-Gm-Message-State: AN3rC/7cl7li9AecB2pZzsYi9EPKS4xGETkUOVP5phhVzk/fXszfHFwG ROUOpvFsztyDgWCgb90jmQXdqz6qTqyg X-Received: by 10.55.148.194 with SMTP id w185mr24917921qkd.58.1493060136585; Mon, 24 Apr 2017 11:55:36 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.93.5 with HTTP; Mon, 24 Apr 2017 11:55:35 -0700 (PDT) In-Reply-To: References: <9047A5A0-ED12-43C2-B2C5-D2A71CBB4373@arrcus.com> <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net> From: Christopher Morrow Date: Mon, 24 Apr 2017 14:55:35 -0400 X-Google-Sender-Auth: 1KYq073eMFc-6j0VpO35xDYdPHg Message-ID: To: Robert Raszuk Cc: Keyur Patel , "idr@ietf.org" , Hares Susan Content-Type: multipart/alternative; boundary=94eb2c08503c11d564054dee27aa Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:55:40 -0000 --94eb2c08503c11d564054dee27aa Content-Type: text/plain; charset=UTF-8 (catching up from ... not reading a 100 message thread) On Wed, Apr 19, 2017 at 6:26 PM, Robert Raszuk wrote: > Keyur, > > You can not set "insecure mode" before you reload the OS as current OS > does not have such knob. Unless you delay the deployment across N releases > and enforce sequenced upgrade. > > isn't this a well known, common practice for software upgrades though? 1) is this software fixing something broken? (or necessary for some feature we need) 2) does the OS boot/load on a lab/test device (don't laugh, often this fails!) 3) does the current golden config for this sort of device load on new OS? 4) does expected behavior for device continue to be in effect? 5) are there configuration changes required to get back to the proper operating state? I think for a bunch of software upgrades 'make configlet changes' is required, so ... this doesn't seem out of scope for normal ops work. > The only way to prevent massive reachability failure upon reload due to > complete silent bgp prefix drop is to configure inbound policy for all EBGP > sessions before the reload and run with new image. > > Of course this is all assuming that someone will read carefully the > release notes :) > > and test before loading on their whole network of revenue relevant infrastructure. > If they do not the troubleshooting of this will be really painful ! CE > will see EBGP session as UP, will get all the routes and will send his > routes. CE will have no clue if PE dropped or accepted his routes. Likewise > on the other end .. Only imagine a network which has 10s of thousands of > VPN CEs as Bruno mentioned and their provider not following all releases > CEs are running. > > it's concerning that people have networks with no filtering/conditioning/etc on their bgp sessions... > At least doing it as part of OPEN msg will be immediately indicated to > both ends. > > //R > > > On Thu, Apr 20, 2017 at 12:16 AM, Keyur Patel wrote: > >> And that would be good enough if that would allow exemptions of DC >> networks and any other networks that may need exemption. >> >> In that case I support the publication. >> >> Regards, >> Keyur >> >> On 4/19/17, 2:08 PM, "Jared Mauch" wrote: >> >> If someone sets insecure mode they can e as promiscuous as they want. >> >> That mode can have a very low bar IMO. >> >> Jared Mauch >> >> > On Apr 19, 2017, at 4:58 PM, Acee Lindem (acee) >> wrote: >> > >> > I would agree with Keyur, For better or worse, our Cisco NX-OS BGP >> > implementation does not require configuration of a peer policy. >> > >> > In fact, this requirement is contrary to some of the auto-discovery >> > mechanisms we are exploring where only knowledge of the mutual >> address >> > families is required. >> > >> > Thanks, >> > Acee >> > >> > On 4/19/17, 4:43 PM, "Idr on behalf of Keyur Patel" < >> idr-bounces@ietf.org >> > on behalf of keyur@arrcus.com> wrote: >> > >> >> Thank you John for bringing it on IDR. >> >> >> >> As an update to RFC4271, I am not sure if I agree with the EBGP >> policy >> >> configuration. There are lot of DC networks (for example) that use >> EBGP >> >> within their CLOS. This extension may not be applicable in such >> networks. >> >> >> >> I would request authors to consider refining text to include >> appropriate >> >> EBGP use cases and not make it generic for EBGP sessions (defined >> in >> >> 4271). >> >> >> >> Regards, >> >> Keyur >> >> >> >> >> >> On 4/19/17, 9:49 AM, "Idr on behalf of John G. Scudder" >> >> wrote: >> >> >> >> IDR folks, >> >> >> >> As many of you have already noticed, >> draft-ietf-grow-bgp-reject-05 >> >> has completed GROW WGLC and is now in IETF LC. >> >> >> >> As nobody other than Alvaro noticed (thank you for noticing, >> Alvaro!) >> >> draft-ietf-grow-bgp-reject-05 represents an update to RFC 4271, in >> that >> >> it mandates what a BGP implementation MUST do. See section 2 of >> the draft >> >> for the details. It's short and easy to read. >> >> >> >> If we had noticed this earlier, we would have either chosen to >> home >> >> the document in IDR, or explicitly made an exception to have GROW >> do the >> >> work. Given that we didn't, though, the plan is to continue >> progressing >> >> the draft as a GROW document. However: >> >> >> >> - As I understand it, the authors will add the Updates: 4271 >> header >> >> in addition to potentially taking in other comments from AD review. >> >> - If anyone has a strong objection to the unusual procedure, >> please >> >> say so (either on-list, or to the chairs + AD). >> >> - Please send any last call comments to the IETF LC (see below) >> >> although it's also OK to discuss here on the IDR list of course. >> >> >> >> Many IDR participants are also active in GROW and have had their >> say, >> >> but if you haven't, now's your chance. >> >> >> >> Thanks, >> >> >> >> --John >> >> >> >>> Begin forwarded message: >> >>> >> >>> From: The IESG >> >>> Subject: Last Call: (Default >> >> EBGP Route Propagation Behavior Without Policies) to Proposed >> Standard >> >>> Date: April 18, 2017 at 5:16:05 PM EDT >> >>> To: "IETF-Announce" >> >>> Cc: grow-chairs@ietf.org, grow@ietf.org, >> >> draft-ietf-grow-bgp-reject@ietf.org, christopher.morrow@gmail.com >> >>> Reply-To: ietf@ietf.org >> >>> >> >>> >> >>> The IESG has received a request from the Global Routing Operations >> >> WG >> >>> (grow) to consider the following document: >> >>> - 'Default EBGP Route Propagation Behavior Without Policies' >> >>> as Proposed Standard >> >>> >> >>> The IESG plans to make a decision in the next few weeks, and >> >> solicits >> >>> final comments on this action. Please send substantive comments to >> >> the >> >>> ietf@ietf.org mailing lists by 2017-05-02. Exceptionally, >> comments >> >> may be >> >>> sent to iesg@ietf.org instead. In either case, please retain the >> >>> beginning of the Subject line to allow automated sorting. >> >>> >> >>> Abstract >> >>> >> >>> This document defines the default behavior of a BGP speaker when >> >>> there is no import or export policy associated with an External >> BGP >> >>> session. >> >>> >> >>> >> >>> The file can be obtained via >> >>> https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-reject/ >> >>> >> >>> IESG discussion can be tracked via >> >>> https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-reject/ >> ballot/ >> >>> >> >>> This IETF LC, which originally concluded on 2017-04-18, is being >> >>> extended to allow for additional input to be provided. Ops AD (for >> >> GROW) >> >>> and Routing AD (for IDR) wish to ensure that cross WG discussions >> >> have >> >>> had a chance to occur. >> >>> >> >>> No IPR declarations have been submitted directly on this I-D. >> >> >> >> _______________________________________________ >> >> Idr mailing list >> >> Idr@ietf.org >> >> https://www.ietf.org/mailman/listinfo/idr >> >> >> >> >> >> _______________________________________________ >> >> Idr mailing list >> >> Idr@ietf.org >> >> https://www.ietf.org/mailman/listinfo/idr >> > >> > _______________________________________________ >> > Idr mailing list >> > Idr@ietf.org >> > https://www.ietf.org/mailman/listinfo/idr >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --94eb2c08503c11d564054dee27aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(catching up from ... not reading a 100 message thread)
On Wed, Apr 19, 2017= at 6:26 PM, Robert Raszuk <robert@raszuk.net> wrote:
Keyur,

You can not set "i= nsecure mode" before you reload the OS as current OS does not have suc= h knob. Unless you delay the deployment across N releases and enforce seque= nced upgrade.


isn't th= is a well known, common practice for software upgrades though?
1) is this software fixing something broken? (or necessary for= some feature we need)
2) does the OS boot/load on a lab/test dev= ice (don't laugh, often this fails!)
3) does the current gold= en config for this sort of device load on new OS?
4) does expecte= d behavior for device continue to be in effect?
5) are there conf= iguration changes required to get back to the proper operating state?
=

I think for a bunch of software upgrades 'make conf= iglet changes' is required, so ... this doesn't seem out of scope f= or normal ops work.
=C2=A0
The only way to prevent massive reachability failure upon reload= due to complete silent bgp prefix drop is to configure inbound policy for = all EBGP sessions before the reload and run with new image.=C2=A0

Of c= ourse this is all assuming that someone will read carefully the release not= es :)=C2=A0


and test befor= e loading on their whole network of revenue relevant infrastructure.
<= div>=C2=A0
If they do not= the troubleshooting of this will be really painful ! CE will see EBGP sess= ion as UP, will get all the routes and will send his routes. CE will have n= o clue if PE dropped or accepted his routes. Likewise on the other end .. O= nly imagine a network which has 10s of thousands of VPN CEs as Bruno mentio= ned and their provider not following all releases CEs are running.=C2=A0

it's concerning that peo= ple have networks with no filtering/conditioning/etc on their bgp sessions.= ..=C2=A0
=C2=A0
<= /div>
= At least doing it as part of OPEN msg will be immediately indicated to both= ends.=C2=A0

//R
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small">

On Thu, Apr 20, 2017 at 12:= 16 AM, Keyur Patel <keyur@arrcus.com> wrote:
And that would be good enough if that would allow exempti= ons of DC networks and any other networks that may need exemption.

In that case I support the publication.

Regards,
Keyur

On 4/19/17, 2:08 PM, "Jared Mauch" <jared@puck.nether.net> wrote:

=C2=A0 =C2=A0 If someone sets insecure mode they can=C2=A0 e as promiscuous= as they want.

=C2=A0 =C2=A0 That mode can have a very low bar IMO.

=C2=A0 =C2=A0 Jared Mauch

=C2=A0 =C2=A0 > On Apr 19, 2017, at 4:58 PM, Acee Lindem (acee) <acee@cisco.com> wrot= e:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I would agree with Keyur, For better or worse, our Cisco= NX-OS BGP
=C2=A0 =C2=A0 > implementation does not require configuration of a peer = policy.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > In fact, this requirement is contrary to some of the aut= o-discovery
=C2=A0 =C2=A0 > mechanisms we are exploring where only knowledge of the = mutual address
=C2=A0 =C2=A0 > families is required.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thanks,
=C2=A0 =C2=A0 > Acee
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On 4/19/17, 4:43 PM, "Idr on behalf of Keyur Patel&= quot; <idr-bou= nces@ietf.org
=C2=A0 =C2=A0 > on behalf of keyur@arrcus.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> Thank you John for bringing it on IDR.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> As an update to RFC4271, I am not sure if I agree wi= th the EBGP policy
=C2=A0 =C2=A0 >> configuration. There are lot of DC networks (for exa= mple) that use EBGP
=C2=A0 =C2=A0 >> within their CLOS. This extension may not be applica= ble in such networks.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I would request authors to consider refining text to= include appropriate
=C2=A0 =C2=A0 >> EBGP use cases and not make it generic for EBGP sess= ions (defined in
=C2=A0 =C2=A0 >> 4271).
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Regards,
=C2=A0 =C2=A0 >> Keyur
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> On 4/19/17, 9:49 AM, "Idr on behalf of John G. = Scudder"
=C2=A0 =C2=A0 >> <idr-bounces@ietf.org on behalf of jgs@juniper.net> wrote:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0IDR folks,
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0As many of you have already noticed, dra= ft-ietf-grow-bgp-reject-05
=C2=A0 =C2=A0 >> has completed GROW WGLC and is now in IETF LC.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0As nobody other than Alvaro noticed (tha= nk you for noticing, Alvaro!)
=C2=A0 =C2=A0 >> draft-ietf-grow-bgp-reject-05 represents an update t= o RFC 4271, in that
=C2=A0 =C2=A0 >> it mandates what a BGP implementation MUST do. See s= ection 2 of the draft
=C2=A0 =C2=A0 >> for the details. It's short and easy to read. =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0If we had noticed this earlier, we would= have either chosen to home
=C2=A0 =C2=A0 >> the document in IDR, or explicitly made an exception= to have GROW do the
=C2=A0 =C2=A0 >> work. Given that we didn't, though, the plan is = to continue progressing
=C2=A0 =C2=A0 >> the draft as a GROW document. However:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0- As I understand it, the authors will a= dd the Updates: 4271 header
=C2=A0 =C2=A0 >> in addition to potentially taking in other comments = from AD review.
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0- If anyone has a strong objection to th= e unusual procedure, please
=C2=A0 =C2=A0 >> say so (either on-list, or to the chairs + AD).
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0- Please send any last call comments to = the IETF LC (see below)
=C2=A0 =C2=A0 >> although it's also OK to discuss here on the IDR= list of course.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0Many IDR participants are also active in= GROW and have had their say,
=C2=A0 =C2=A0 >> but if you haven't, now's your chance.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0Thanks,
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0--John
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>> Begin forwarded message:
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> From: The IESG <iesg-secretary@ietf.org>
=C2=A0 =C2=A0 >>> Subject: Last Call: <draft-ietf-grow-bgp-reje= ct-05.txt> (Default
=C2=A0 =C2=A0 >> EBGP Route Propagation Behavior Without Policies) to= Proposed Standard
=C2=A0 =C2=A0 >>> Date: April 18, 2017 at 5:16:05 PM EDT
=C2=A0 =C2=A0 >>> To: "IETF-Announce" <ietf-announce@ietf.org>= ;
=C2=A0 =C2=A0 >>> Cc: grow-chairs@ietf.org, grow@ietf.org,
=C2=A0 =C2=A0 >> draft-ietf-grow-bgp-reject@ietf.org, christopher.morr= ow@gmail.com
=C2=A0 =C2=A0 >>> Reply-To: ietf@ietf.org
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> The IESG has received a request from the Global = Routing Operations
=C2=A0 =C2=A0 >> WG
=C2=A0 =C2=A0 >>> (grow) to consider the following document:
=C2=A0 =C2=A0 >>> - 'Default EBGP Route Propagation Behavior W= ithout Policies'
=C2=A0 =C2=A0 >>> <draft-ietf-grow-bgp-reject-05.txt> a= s Proposed Standard
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> The IESG plans to make a decision in the next fe= w weeks, and
=C2=A0 =C2=A0 >> solicits
=C2=A0 =C2=A0 >>> final comments on this action. Please send subst= antive comments to
=C2=A0 =C2=A0 >> the
=C2=A0 =C2=A0 >>> ietf@ietf.org mailing lists by 2017-05-02. Exceptionally, comments =C2=A0 =C2=A0 >> may be
=C2=A0 =C2=A0 >>> sent to iesg@ietf.org instead. In either case, please retain the =C2=A0 =C2=A0 >>> beginning of the Subject line to allow automated= sorting.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Abstract
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> This document defines the default behavior of a = BGP speaker when
=C2=A0 =C2=A0 >>> there is no import or export policy associated w= ith an External BGP
=C2=A0 =C2=A0 >>> session.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> The file can be obtained via
=C2=A0 =C2=A0 >>> https://datat= racker.ietf.org/doc/draft-ietf-grow-bgp-reject/
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> IESG discussion can be tracked via
=C2=A0 =C2=A0 >>> https:= //datatracker.ietf.org/doc/draft-ietf-grow-bgp-reject/ballot/=
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> This IETF LC, which originally concluded on 2017= -04-18, is being
=C2=A0 =C2=A0 >>> extended to allow for additional input to be pro= vided. Ops AD (for
=C2=A0 =C2=A0 >> GROW)
=C2=A0 =C2=A0 >>> and Routing AD (for IDR) wish to ensure that cro= ss WG discussions
=C2=A0 =C2=A0 >> have
=C2=A0 =C2=A0 >>> had a chance to occur.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> No IPR declarations have been submitted directly= on this I-D.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0___________________________________= ____________
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0Idr mailing list
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0Idr@ietf.org
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0https://www.ietf.org/mai= lman/listinfo/idr
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> _______________________________________________=
=C2=A0 =C2=A0 >> Idr mailing list
=C2=A0 =C2=A0 >> Id= r@ietf.org
=C2=A0 =C2=A0 >> https://www.ietf.org/mailman/li= stinfo/idr
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Idr mailing list
=C2=A0 =C2=A0 > Idr@ie= tf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listin= fo/idr


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--94eb2c08503c11d564054dee27aa--