Re: [Idr] BGP autodiscovery design team

"UTTARO, JAMES" <> Thu, 05 December 2019 13:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F464120020 for <>; Thu, 5 Dec 2019 05:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.073, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mxx0fU03I9kn for <>; Thu, 5 Dec 2019 05:46:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB38A12004A for <>; Thu, 5 Dec 2019 05:46:48 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id xB5Da1I2003039; Thu, 5 Dec 2019 08:46:47 -0500
Received: from ( []) by with ESMTP id 2wq1w6sjj0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Dec 2019 08:46:47 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id xB5Dkjhs002647; Thu, 5 Dec 2019 08:46:45 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id xB5DkcqW002492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Dec 2019 08:46:38 -0500
Received: from ( []) by (Service) with ESMTP id 0F1794030709; Thu, 5 Dec 2019 13:46:38 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id EC5E1403070F; Thu, 5 Dec 2019 13:46:37 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0468.000; Thu, 5 Dec 2019 08:46:37 -0500
From: "UTTARO, JAMES" <>
To: Robert Raszuk <>, John Scudder <>
CC: idr wg <>
Thread-Topic: [Idr] BGP autodiscovery design team
Thread-Index: AQHVqtmqrRq1UF+NcE2nCZoCamlAGKeqyAgAgADEnYA=
Date: Thu, 05 Dec 2019 13:46:36 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F4DA2809DMISOUT7MSGUSRCD_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-05_03:2019-12-04,2019-12-05 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 spamscore=0 impostorscore=0 mlxlogscore=999 clxscore=1011 phishscore=0 bulkscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912050115
Archived-At: <>
Subject: Re: [Idr] BGP autodiscovery design team
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: Thu, 05 Dec 2019 13:46:51 -0000

I agree with Roberts’ point. Prior to crafting or selecting a draft as the basis for a proposal the design team should clearly articulate the scope, use cases and requirements that need to be addressed. IMO stating that in an informational RFC is a good way to ensure that all stakeholders are in agreement as to what the eventual specification/draft addresses, and as important does not address. When creating EVPN we first crafted an informational RFC that specified Active/Active Multi-homing, flooding and multicast optimization etc… which formed the basis for the RFC 7432. This focused the design team on realizing the requirements articulated there.

              Jim Uttaro

From: Idr <> On Behalf Of Robert Raszuk
Sent: Wednesday, December 04, 2019 3:54 PM
To: John Scudder <>
Cc: idr wg <>
Subject: Re: [Idr] BGP autodiscovery design team

Hi John,

When this was announced I asked if this design team scope is to work on discovering your BGP peers in DC space or also in WAN and IX environments.

As you know I have been focusing on the latter for a number of years and I can share that discovering p2p eBGP peers requires a very different solutions as compared with discovering your iBGP peers or IX members.

So please kindly clarify the scope of this effort here.

Just stating BGP autodiscovery IMHO is too broad at this point. Likewise working on the DC space and declaring we are done with BGP autodiscovery all together would not be in the best interest of the protocol.

I suggest that this effort be called BGP DC or p2p autodiscovery.

Many thx,

On Wed, Dec 4, 2019 at 8:33 PM John Scudder <<>> wrote:
Hi All,

I realized this morning that although we announced in the last meeting that we’re forming this design team, we never announced it on the list. This is to correct that mistake. Here’s the text of the slide we presented at the meeting (<>)


• Clear interest in WG to work on this topic.
• No clear consensus on a specific approach.
• Proposals (four of them) progressively closer semantically, seems likely convergence can happen.
• But, important differences remain.
        • At least: transport (L2, L3), liveness, security, maybe multihop.
• Chairs propose to charter a design team to close on a single proposal, by next meeting.
        • Might build on one of the existing drafts, might be a new draft, up to the design team.
        • Emphasis on pragmatism, OK to limit applicability (for example, to a single administrative domain).
• Questions? Comments? Volunteers?

We are in the process of forming the team and hope to announce it soon. We have many good volunteers already but if you didn’t know and do want to volunteer, please contact Sue and me.

Note that the design team will not make any binding decisions: as with all WG work, the WG has the final word, so any output of the DT will serve as input to the WG as a whole. (So even if you aren’t part of the DT, that doesn’t mean you won’t have a chance to be part of the process.)


Idr mailing list<><>