Re: [Idr] BGP Auto-Discovery Protocol State Requirements

Robert Raszuk <> Fri, 19 March 2021 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A9893A0B02 for <>; Fri, 19 Mar 2021 02:54:38 -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 8WDnFYRLX2ly for <>; Fri, 19 Mar 2021 02:54:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8290B3A0ADF for <>; Fri, 19 Mar 2021 02:54:35 -0700 (PDT)
Received: by with SMTP id 75so9047232lfa.2 for <>; Fri, 19 Mar 2021 02:54:35 -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=+ZIQJkLqC8aB901GI0H3hNbzqLkTFZTWZsS7Z1irZ00=; b=F7+J31MxQZV2Vt6EN9ux6FJq+/z2ZhQMbUIbGKSZRRtVTS25TEmAqvRvz+U1dT8jwT DWttynPg0llDP/7OpkuDe4892lvzXXWJ190miBPoBxm0oL0plBcKmKkpI1xugUiLhhwM X95Oilb0WibdQfRBXOzvkkfE6UaIoE20UuCO/BJy3lF/m4SwCwCZG8pGE1QXMhgEJ7Xo zeM7xPbnCh80Btl22lFhPZQoOq/xUyJ+0GSIi2CN52kzFIlnGLX9EC5yb6vFlZZxZOut ku1MGPN/9q8PEJ1jAe1Wl+Ug1PnHsNkrxzsSbhY3zixnn+uCDQMKU//c6JOdL4daF2mH va7Q==
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=+ZIQJkLqC8aB901GI0H3hNbzqLkTFZTWZsS7Z1irZ00=; b=PD38psJHy0F/a5MUGVT7XfgrSo+P/aXssi/I12n1SZlrBOCzk4HWQiEmXX0j08HkqY RUAbRYSd6crEJVUxFY4tLOXBY00mufcLuSKS8V/QS+NaDfZN36whzav2/eHTXqCoxI8M Xi7aXObLIBCiCM2TTRM2KV6z1eUU25iLe6Er4GRiDAsBWL1hwXmdN2wBKHknS7RLHoZB 0jPIC4ghE1Jg6/GZSprppeK//rEmfeA1U3jZgO3CIyRShP6oizB/VkIPjHohJrBwLweo a0e9VweRiTDCD2UtSmgEI9Gs7j1zZvJeSV4ZutVEl7e2ePE4mhkl6CV39uppVRsQJnkJ DhgQ==
X-Gm-Message-State: AOAM533bDI9f8RHvkmopuG50YkDqvE100uZuK/1MgcPRMmNcd2uQHXk9 2Ts0aUYhl234NFnbHzLbVwnipRBme2SWEqNB9Q6WjZ/7OFuSi3vD
X-Google-Smtp-Source: ABdhPJy+eYQpFHynEsubeafU1vDvLWfHNticljnPBWbbb6UfeGr4l6jaCTSsOODDcaTAF+fQDpf12QqiHUTn8jIkyfY=
X-Received: by 2002:a19:651b:: with SMTP id z27mr308775lfb.517.1616147668438; Fri, 19 Mar 2021 02:54:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Fri, 19 Mar 2021 10:54:19 +0100
Message-ID: <>
To: Jeffrey Haas <>
Cc: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000aea1ad05bde0b390"
Archived-At: <>
Subject: Re: [Idr] BGP Auto-Discovery Protocol State Requirements
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: Fri, 19 Mar 2021 09:54:38 -0000


I am not sure if by "discover at OPEN" you mean just convention to be used
in the draft or some flag/field.

If this is just the convention it is fine. Discover at OPEN is exactly what
I had in mind writing

If however you think about signalling it as part of auto-discovery then I
think we do need to keep in mind that BGP4 MUST continue to operate fine
without auto discovery. That means that all negotiation and checks still
MUST happen natively in BGP - so they will happen anyway.

Or maybe you wanted to relax this and say if lots of things have been
already auto discovered we can send OPEN-lite ?

Of course down the road we may reach conclusion that configuration of BGP
session is the thing of the past and bump BGP version to operate in the
"modern" style but this moment I think still a bit ahead of us.


On Thu, Mar 18, 2021 at 7:58 PM Jeffrey Haas <> wrote:

> Further off-list conversation with Tony Przygienda offer a related
> observation on the BGP Session State: They serve as the "offer", and the
> management of its lifetime is to a large extent the critical detail covered
> by the "retry" behavior.
> This potentially creates an option between 1 and 2 below.  A BGP
> Auto-Discovery listener that is implementing "discover at OPEN" mostly
> needs
> the hint that "something has changed" for the parameters that may be
> discovered at OPEN.
> A version/generation or similar field in the auto-discovery protocol would
> suit this purpose and permit a "discover at OPEN" BGP Speaker to minimize
> the load upon the auto-discovered device.
> This would permit the entire set of BGP Session Protocol State to be
> omitted
> from the protocol, as long as "discover at OPEN" was acceptable.  It also
> addresses the consistency issue noted in section 3.6 of the
> autconf-considerations draft.
> ---
> Note that the majority of proposals analyzed for BGP auto-configuration in
> Appendix A published some subset of the state in the BGP Session Protocol
> State requirements.  Authors of those proposals may wish to comment on
> their
> reasoning for that state in their protocol.
> -- Jeff
> On Tue, Mar 16, 2021 at 05:02:03PM -0400, Jeffrey Haas wrote:
> > Once you have the capability of bringing up a BGP session, you have to
> > decide if you even want to.  There are at least two design choices, each
> > with specific consequences:
> >
> > 1. The implementation is willing to determine if a peer is acceptable or
> not
> >    based on the information exchanged in the BGP OPEN message.  Call this
> >    "discover at OPEN".  A further implication of this mode is the
> >    implementation must be willing to service incoming sessions that may
> drop
> >    just so they can figure out if they find each other mutually
> agreeable.
> >    This becomes a scaling discussion.
> >
> > 2. The implementation wants to know the properties of its potential peer
> to
> >    decide if it wants even try to bring up a session.  This enables "peer
> >    selection".
> >
> >    The good property is that the peer sending such messages doesn't have
> to
> >    service sessions only to immediately drop them.
> >
> >    The bad property is that this increases disclosure of some BGP
> >    information to parties that may not eventually be permitted to peer.
> >    (Security consideration.)
> _______________________________________________
> Idr mailing list