IETF Logo Mail Archive

Re: [Bgp-autoconf] Progress report of design team on IDR virtual meeting

Jeff Tantsura <jefftant.ietf@gmail.com> Tue, 24 March 2020 22:53 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: bgp-autoconf@ietfa.amsl.com
Delivered-To: bgp-autoconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21443A07EF for <bgp-autoconf@ietfa.amsl.com>; Tue, 24 Mar 2020 15:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 (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 mE9BaRYyMeAf for <bgp-autoconf@ietfa.amsl.com>; Tue, 24 Mar 2020 15:53:26 -0700 (PDT)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 3CE6C3A080B for <bgp-autoconf@ietf.org>; Tue, 24 Mar 2020 15:53:25 -0700 (PDT)
Received: by mail-pj1-x102e.google.com with SMTP id o12so190722pjs.2 for <bgp-autoconf@ietf.org>; Tue, 24 Mar 2020 15:53:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=EEA0P5qHO99t2eD+RnZ03q+zuppBGqtFiso/rP1esXY=; b=T+UD2oXRgACyrc6sJ6PVGLqTdAd/DqHVPb9E1j2GlgDfP1gT7QKzrfLJERs3SI6vXh Lbzoff39Y1XWCfO7wQISIWQopej7ZA2Ums8MqMB+KFDUpyEokPrAoPc1/hfif+is5/0N kmMggJbQ0x8aJE85M3/3dNRFcR1VhS17Q/g1qdvnRE4zJbkTwMuBRpL3q4fQys0Mreqe vY1SBAQ5zWrG1Czvtl1VOlEKxyZ6OLSlTL0Uv80dH6iVM0XJGbKyirk+bZFUR7zesS+g 78LduWT9d5lnFHKDYZ8VQ/aRhWdJrRsa+fFSDl5qDWEuLwg1TL0JOXQnN6WCwgtSf6XN cBeg==
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:message-id:in-reply-to :references:subject:mime-version; bh=EEA0P5qHO99t2eD+RnZ03q+zuppBGqtFiso/rP1esXY=; b=mlBd+UMNSGcbbaOMV9aQQ+fEuwExqgiGE856xDjkSkSbDbBJ3XVJV8fRKn64LQWFOt 7v0xbEAMVWqZ5wPQdKC7p2Rm6vOqtt1pg1U0BUaBdzgAQU4hyRJ+gFTKDS9rr2dKH3Qn IMS0z7BqVADmYklocfbc9cPCtompxRc2TIP7YRyay+Hultkn+i6INPJpr1pg0pv5EFUS c2XTQ38CCBJfwP4vRURUlwdlj30Ovnm8eYmnxLVSfvTzL97jzA6yCZSlDmiUodqx92ts j0IWVDscCBS3F3UjTucpdio8BeeWmFZkrjP5RVGdY3p0opXwACrFdtP+y7aMM/5Pe+zC SlWg==
X-Gm-Message-State: ANhLgQ0ZTLkG8Do4nJWEa2P2+MfVvQiaAA8mkvSijFIJ6G+ObsRvnjsv W1xbh2S/W/EYTe6XMVutxCc=
X-Google-Smtp-Source: ADFU+vtiGIDnzONeFFu/EoCrF/FL/o10dsk+XHOiSN1xAbXNnAbL6DQZmueQrdlDQapcO9srVNu5hw==
X-Received: by 2002:a17:902:b183:: with SMTP id s3mr313773plr.33.1585090404417; Tue, 24 Mar 2020 15:53:24 -0700 (PDT)
Received: from [2601:640:10b:8908:402a:8900:70:0] ([2601:640:10b:8908:2c27:4975:61cb:3414]) by smtp.gmail.com with ESMTPSA id k4sm17790318pfh.0.2020.03.24.15.53.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2020 15:53:23 -0700 (PDT)
Date: Tue, 24 Mar 2020 15:53:17 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Randy Bush <randy@psg.com>, Robert Raszuk <robert@raszuk.net>
Cc: "=?utf-8?Q?bgp-autoconf=40ietf.org?=" <bgp-autoconf@ietf.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>
Message-ID: <b3b259c0-46c8-4257-9956-bddebeda34ea@Spark>
In-Reply-To: <CAOj+MMHt+TyhoB3A5mR7BuXv7QFTtfN-DNrsa8=vEMecTDwG3Q@mail.gmail.com>
References: <b9c7b88960764dc4aa4454eac2310160@huawei.com> <m2blom1or0.wl-randy@psg.com> <f465f49f53534122aaffe4d651e08467@huawei.com> <m27dz9z8e6.wl-randy@psg.com> <CAOj+MMHt+TyhoB3A5mR7BuXv7QFTtfN-DNrsa8=vEMecTDwG3Q@mail.gmail.com>
X-Readdle-Message-ID: b3b259c0-46c8-4257-9956-bddebeda34ea@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5e7a8f62_4f0ceedb_16f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bgp-autoconf/FhaO9jhFcL269mr2_7fL19P6OK0>
Subject: Re: [Bgp-autoconf] Progress report of design team on IDR virtual meeting
X-BeenThere: bgp-autoconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP autoconfiguration design team discussion list <bgp-autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bgp-autoconf>, <mailto:bgp-autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bgp-autoconf/>
List-Post: <mailto:bgp-autoconf@ietf.org>
List-Help: <mailto:bgp-autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bgp-autoconf>, <mailto:bgp-autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 22:53:46 -0000

I’m with Robert here, autodiscovery meant to provide minimum necessary amount of data to establish peering relationship, the rest is done thought BGP.

Cheers,
Jeff
On Mar 24, 2020, 3:48 PM -0700, Robert Raszuk <robert@raszuk.net>et>, wrote:
> All,
>
> I completely agree with Randy on this part:
>
> " None of these example attributes are requirements, will be specified, given code points, etc. in the protocol design."
>
> On the rest I would actually go even further and say that such things should be out of scope of pure and simple auto discovery.
>
> Reason being that once you open a trunk - even if originally empty or containing only spare tire - folks will load it with junk beyond imagination making the interop nightmare, opportunity to keep old mantra alive fix one bug intro two etc ...
>
> And as I said in the other note - some of this stuff being proposed should be transitive and IMHO belongs in BGP not in autodiscovery.
>
> Thx
>
>
> > On Tue, Mar 24, 2020 at 11:38 PM Randy Bush <randy@psg.com> wrote:
> > > jimmy,
> > >
> > > my apologies for my poor communication.  let me try with text
> > >
> > >   Two prospective peers SHOULD be able to exchange arbitrary attributes
> > >   to communicate things such as position or role in a topology, link
> > >   speeds and/or loading, preferred time of day, favorite ice cream, etc.
> > >   None of these example attributes are requirements, will be specified,
> > >   given code points, etc. in the protocol design.  But there SHOULD be a
> > >   protocol provision for communicating arbitrary attributes so that the
> > >   operator may configure as needed for their environment.
> > >
> > > hope that helps.
> > >
> > > randy
> > >
> > >
> > > --
> > > Bgp-autoconf mailing list
> > > Bgp-autoconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/bgp-autoconf
> --
> Bgp-autoconf mailing list
> Bgp-autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/bgp-autoconf

v2.8.7 | Report a Bug | By Email