Re: [Idr] Adoption Call on DT document (draft-ietf-idr-bgp-autoconf-considerations-00.txt) [3/10/2021 to 3/31/2021]

Robert Raszuk <> Tue, 16 March 2021 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D48D3A0936 for <>; Tue, 16 Mar 2021 05:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Status: No, score=-7.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hq3VB85JGFd5 for <>; Tue, 16 Mar 2021 05:20:46 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC5263A093D for <>; Tue, 16 Mar 2021 05:20:45 -0700 (PDT)
Received: by with SMTP id f26so20181272ljp.8 for <>; Tue, 16 Mar 2021 05:20:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gj4BUbBj5P3G46yBZhIfZHw0ndvE/lImuhwKkBMO4hg=; b=DeW/bKBXl97K28xkKYja4WNvonfl1NV5hpw8lAf/Nd19fNxAMWCi+An4sQPNq1Z6mZ 9vboDsoC30Yl9FQwfgWjrR737J2fE2QEIOJe4VP4cAdccoTMQ1PlOx3e/0IlbXJiVbjX 4H8R4ydk0vq6C0itvQRULiSeTuE7eJjLAk4yMklbp2yq/6CxJXiO+NQkb+THrMLXv6jk prNzCL9bM4XJIqoU33Rc1CsRgIJi+ZVt1woBlC8RRaaCmkYiZSdYLNs4dkkqO0ZSWSvo sdRXukECySVN7bWHWjiLYhJS5XnjzMCLOzyd+uMBGQgswMrdE0umjzMXgAyodlq1cyVg 2Hrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gj4BUbBj5P3G46yBZhIfZHw0ndvE/lImuhwKkBMO4hg=; b=ow+vU1Dcb3j81mGl1NB9b5GJSmuZsfv2Dx2RA6Ps3VSwpGsINDE7KTglKk+MHiLO6B nHOEuRuxsTqzkojHdUEMZMoVcxjALPVhAPk2kPRxFBlCXWlJavHn/KZ9C7ZcoshCxJ6w ftNpiCvKgZDHHZ0+oBdZicwQkZX7d20oUL8Flhf4yDiuU+S8/g3YWMnt1cysD7bmirOG r09wjfm8Nph1lpA7SSbIWM+gyfmKe8+8xMxaS0mkHPO+OKnLC5K+R8afY7vShZ+VeCvs KMJ/Yqxf8vdW42uuHCglyK4Z3zYCfqGrB6C2eq1IF69QWs0AT9/77RO7slkMU0GuC3d8 gwCg==
X-Gm-Message-State: AOAM533792AWcyDrZkgBUkX/at2ZsPci0Cd2HdaMkmscAYpZ2rp3wnof KT3de7ZBAgVWf5naiQf+h651oF2tnw3poMRFqGYcJQ==
X-Google-Smtp-Source: ABdhPJyc64UyTW5o+pfT+8ODjmvHMn+9a/85kvdYFKEgPu14Y6rfiqpewo4Ji7t+ktwFPuCJ/PB1X/bJMG0UWGJir88=
X-Received: by 2002:a2e:5cc7:: with SMTP id q190mr2445785ljb.37.1615897243140; Tue, 16 Mar 2021 05:20:43 -0700 (PDT)
MIME-Version: 1.0
References: <010401d715d7$b061cb70$11256250$>
In-Reply-To: <010401d715d7$b061cb70$11256250$>
From: Robert Raszuk <>
Date: Tue, 16 Mar 2021 13:20:33 +0100
Message-ID: <>
To: Susan Hares <>
Cc: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="0000000000002bd32a05bda665be"
Archived-At: <>
Subject: Re: [Idr] Adoption Call on DT document (draft-ietf-idr-bgp-autoconf-considerations-00.txt) [3/10/2021 to 3/31/2021]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Mar 2021 12:20:48 -0000

Hi Sue,

Ad 1-3)

As a contributor I do not support progressing the document in the
current form.

In my opinion set of requirements is too broad to what is required to
provide a simple discovery of BGP peer candidate. IMO single bit in LLDP
message or as proposed either BGP OPEN to link multicast or sort message to
link multicast should suffice.

Number of requirements already duplicate what is exchanged between peers in

Is a BGP speaker capable of autodiscovery supposed now to filter peers with
the same BGP_ID ?

Why are we stating something against RFC5082 which says:

   "If, however, dynamic negotiation of GTSM support
   is necessary, protocol messages used for such negotiation
*MUST be   authenticated* using other security mechanisms to prevent DoS

Why do we need to send a device role and what RFC defines the device role ?
You can't put requirements in place something which is today
nowhere deployed.

Support AFI/SAFI is already covered by BGP Capability negotiation. Do we
need to repeat those procedures here ?

Requirements list IPSec as one of transport security options .. and now
what if peer exchange such requirement ? Is this optional for a candidate
peer or mandatory ? What if list of transport security requirements is
exchanged ? Is there no requirement for preference order ?

Ad 4)

We have been working in IDR for many years on

So now perhaps more valuable would be to review this work instead of
creating a requirements document ?

Many thx,

On Wed, Mar 10, 2021 at 7:03 PM Susan Hares <> wrote:

> Greetings:
> This is an adoption/feedback call for the DT team document:
> This call for comments will run for 3 weeks.
> In your feedback please let us know:
> 1) do you think this represents a good set of requirements for bgp
> autoconf protocol in the data center?
> 2) Do you think the document should remove any requirements or add an
> requirements?
> 3) Do you think the review of the protocols should be moved to another
> document?
> 4) Should a IDR DT create the requirements for non-Data Center deployments
> prior to starting work on a BGP auto-configuration protocol? If so, should
> a DT start these requirements in parallel?
> Cheers, Sue Hares
> _______________________________________________
> Idr mailing list