IETF Logo Mail Archive

Re: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.txt

Job Snijders <job@fastly.com> Thu, 17 June 2021 11:54 UTC

Return-Path: <job@fastly.com>
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 090183A1C99 for <idr@ietfa.amsl.com>; Thu, 17 Jun 2021 04:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 hrOYgDujjX-q for <idr@ietfa.amsl.com>; Thu, 17 Jun 2021 04:54:45 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 1BFAE3A1C97 for <idr@ietf.org>; Thu, 17 Jun 2021 04:54:44 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id g20so9500162ejt.0 for <idr@ietf.org>; Thu, 17 Jun 2021 04:54:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=URdvBBaFtayOygyjzTlPFFfnaxzHPmNFDTLRbP9pxa8=; b=WKZ4ofjIvpbadYo8n1VyHCEFi2zsUsplgN2ABgeRsVaXeMwG0ekd6KkOQYeUnTwoGe HNtUIp3bJlsKpN+LZSF51w7ESZjCNCChCIer7be3XVArafeyZw259U2tERvB8xIWlsFa 1J/tey6JkM6RbbfEBX7Q0WQg2lwC2itwUs/Kw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=URdvBBaFtayOygyjzTlPFFfnaxzHPmNFDTLRbP9pxa8=; b=ofD/Xq5jFeOIW661WJ8I8JYtlvE748Y5qe5NdQTcLsLxD0RQxC91DjIoc2fo9Tt+Sh Nfr8vwHteK0nXrdmOZbhv5t56ZHjcvZ/oFq7EToIfIAuBxw/kqYIj5RW+xYZbB2Y2Jj8 xTjC/87FR27QJhIsjUuDjAbm4WrJmkCV4CzlT6ojFKVl6O3zXN5prx3E3YudevfIFsJz MBkCNUV2gT/yvC8FJ3/7/bMHC3u9bmdtFPNC7YmctO80wdiMFD2aQK4WKecTwIcm/q8l qM8O6Orny/kllR0u1X9HdTDZOpgHqvv1SIsjwwMhBxgE89cABso72m/UgV0PyvuaJ116 qkow==
X-Gm-Message-State: AOAM532U6EBvswROVumtIjPdNWGdMTpka6nUhWD9HFkjfLBjIUYHHpeM jYM6b/3aqAxMkQshvjckLGHWbw==
X-Google-Smtp-Source: ABdhPJzmB8W9e8lkmaclc3ks1ZZ5DN+L8vJ0QcXJjbj5qwaejrGTIfSb4+Etg/svYIAXWm7ul3L6pQ==
X-Received: by 2002:a17:906:3ed0:: with SMTP id d16mr4712138ejj.16.1623930883075; Thu, 17 Jun 2021 04:54:43 -0700 (PDT)
Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id m7sm4043522edc.46.2021.06.17.04.54.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Jun 2021 04:54:42 -0700 (PDT)
Date: Thu, 17 Jun 2021 13:54:11 +0200
From: Job Snijders <job@fastly.com>
To: Melchior Aelmans <melchior@aelmans.eu>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, heasley <heas@shrubbery.net>, "idr@ietf. org" <idr@ietf.org>, Melchior Aelmans <maelmans@juniper.net>, Robert Raszuk <robert@raszuk.net>
Message-ID: <YMs349ANruT8tvhh@snel>
References: <CAOj+MMHDPGt30deY6KtC+E-5eD9Q8cRtrL-xydLhsNic7KBdSw@mail.gmail.com> <CALxNLBi5Borzgr6ntRZHu0P6dnEcoZ8pk7=JKKfRhNcUbv873w@mail.gmail.com> <CABNhwV2mUP2f8sKdqOEde35U6a5idY+XGWNf0G2rzheRULhmmw@mail.gmail.com> <BYAPR11MB3207A318E89779FDBE4F1EDFC0529@BYAPR11MB3207.namprd11.prod.outlook.com> <CAOj+MMGpsLcdPynRWOiUK6-8Gx+MtwtPyOBLJDW8EsXknWXJ1w@mail.gmail.com> <CABNhwV3d0OXUurMkcbB-hC1LT-dtRTV464p_9v84SdBcH_FbNQ@mail.gmail.com> <YJ1IfGrUylekt2xk@shrubbery.net> <CAH1iCioH8X-r12P=m=Bg8b5s+GHuJth-2MAw_tmsZz=caS_B8Q@mail.gmail.com> <CABNhwV0-_rGgDuQbrrStcDM_-_wUb828FWWN57Jn5KO+WSPvrQ@mail.gmail.com> <CALxNLBj2U=pi1NmEP9zxYnfKFhsyUt-Y2nn4Kag8ASgpE_Xt3Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CALxNLBj2U=pi1NmEP9zxYnfKFhsyUt-Y2nn4Kag8ASgpE_Xt3Q@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YVBJMrEYNT2oPn8rsoS1Za0cZtw>
Subject: Re: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jun 2021 11:54:50 -0000

Hi Melchior,

I believe 'soft-reconfiguration inbound' is a vendor-specific term which
we should try to avoid in Internet-Drafts.
See https://mailarchive.ietf.org/arch/msg/idr/X0_eoWM_v-LOmfPA23_ydZb_Ucc/

If the implementation supports 'Adj-RIB-In' (either through a command,
or enabled out off the box), then the implementation can offer
'pre-policy limit' functionality.

I also don't think the threshold SHOULD be higher, they could also be
equal :-)

Kind regards,

Job

On Wed, Jun 16, 2021 at 11:11:54PM +0200, Melchior Aelmans wrote:
> Dear WG, commenters,
> 
> Thanks for all the suggestions and great discussion.
> 
> I have just uploaded -03  (
> https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound)
> version which includes the following statement:
> 
> Operators SHOULD take special care when applying soft-
>          reconfiguration inbound, as it could still expose control plane
>          to exhaustion if no pre-policy limits are available or are not
>          configured.  Implementations SHOULD provide means to configure
>          two thresholds for inbound limits.  One before soft-
>          reconfiguration inbound and one after soft-reconfiguration
>          inbound.  This is to prevent soft-reconfiguration inbound to
>          exhaust control plane resources.  The threshold before soft-
>          reconfiguration inbound SHOULD be higher than the limit
>          configured after soft-reconfiguration inbound.
> 
> 
> Does that make sense and addresses the issue? Please advise.
> 
> Thanks!
> Melchior
> 
> On Fri, May 14, 2021 at 1:13 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:
> 
> >
> > I understand for documentation purposes being in the draft.  I am in
> > agreement as highlighted by Jacob & Robert.
> >
> > Gyan
> >
> > On Thu, May 13, 2021 at 4:13 PM Brian Dickson <
> > brian.peter.dickson@gmail.com> wrote:
> >
> >>
> >>
> >> On Thu, May 13, 2021 at 8:44 AM heasley <heas@shrubbery.net> wrote:
> >>
> >>> Wed, May 12, 2021 at 11:14:51PM -0400, Gyan Mishra:
> >>> > +1 more for implementation not for draft
> >>>
> >>> I disagree; that has helped create the inconsistencies among impls.
> >>> Document
> >>> it.
> >>>
> >>
> >> I also disagree, for the reasons highlighted by Jakob and Robert.
> >> It needs to be in the draft.
> >>
> >> Brian Dickson
> >>
> >
> >
> > --
> >
> > <http://www.verizon.com/>
> >
> > *Gyan Mishra*
> >
> > *Network Solutions A**rchitect *
> >
> > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
> >
> >
> >
> > *M 301 502-1347*
> >
> > _______________________________________________
> > 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

v2.23.0 | Report a Bug | By Email