Re: [Idr] BGP autodiscovery design team

Robert Raszuk <> Thu, 05 December 2019 13:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4BAA1200C4 for <>; Thu, 5 Dec 2019 05:59:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ONDKQ82HqV7z for <>; Thu, 5 Dec 2019 05:58:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD24412004A for <>; Thu, 5 Dec 2019 05:58:58 -0800 (PST)
Received: by with SMTP id c124so3411557qkg.0 for <>; Thu, 05 Dec 2019 05:58:58 -0800 (PST)
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=UHE5pHTMDQZWxDLhNWc1CNfEl7gTj0dQ+Yu+bptJYJc=; b=as/Bm74LBG0FOxyFKbGeyz9/X/oO+pSUoonYrvSN8OYH64ABkw3AKMpfEXUMj8r7bt 9zfyF3GAJkxqhfe3FAMtja2zYDt29o2/2BbnwYhiFBsVdqPXvzzjyp9NLcbhrHWKhGud rNhfJ4pVsV8MNjpjKvepD9SZnOMjwDLdU/pzXsCXSRg6ONpSv92CyN61l+uiex4cSR7J K3fBCJY9cQe1p9HIiVuXlAGLQFMAC5/gbDYiSm1H/7mgcDujKElJ6w/BC/fzKaGI45LI r61RMD5T9OqZ8MiCphPnrerRqX8ZtLKLBz3322eBgCQVWXgpO0s6/q7WBFQ+6AlESY7K 62eQ==
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=UHE5pHTMDQZWxDLhNWc1CNfEl7gTj0dQ+Yu+bptJYJc=; b=rbw59VLzsIYZdIZlrx6u5Z0U8xNp/ZS2JjpBq5mDk/TD9mjoLwaH4iPABb67c3HS1R Mx6HeIToiC3CzBeHl8kR0aAmDTCOVjxfoBYus8ptWeP7u1MY8Ez3ct2RieytJTPsjAdh gg9V5Qovp+nNZWBAjTQqATyLEPX8ODbiIhyaoDt4/4XwvVA8D4bUEG+pMh9x/l1rCNkQ aFg19lgJVSQMiK4I1/YIgH19jABS3fL9IU2qFbo1nTHz2raNDcI9ooWasMGKsr3sEscp Pjlm3l6509rJlDIuOWwko4cFzOaeaaj2UZN7475COVwDxgWgJQd1wonEcWXhTMTgQGQU ssDw==
X-Gm-Message-State: APjAAAXM/TkVHdN5dUBICxUesImzP3rK7ZN8+Yor5AK/7QSRIl8UMBAT aFVU4we9MVVoN8rLTtSI6wwh5Y84fkcSDHJ2wF85LtaYjSQ=
X-Google-Smtp-Source: APXvYqwFITiXQi4nUMKJU+aa0ARmiaHzppwn50TDGlQsFu0E7rk6rjr/81zgSFuHGfpxj1xisdACt8ajbknWpEy8X44=
X-Received: by 2002:a37:62d2:: with SMTP id w201mr7931553qkb.445.1575554337700; Thu, 05 Dec 2019 05:58:57 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Thu, 05 Dec 2019 14:58:43 +0100
Message-ID: <>
To: Job Snijders <>
Cc: "UTTARO, JAMES" <>, John Scudder <>, idr wg <>
Content-Type: multipart/alternative; boundary="0000000000009f98a00598f554b4"
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:59:01 -0000

Hi Job,

>  Perhaps the design team’s mailing list should be

Indeed !

I do not understand why there is any need for "design team" if required
functionality is about one of the core protocol functionality. What are we
trying to achieve - if someone on IDR is not interested given mail thread
can be easily moved to trash.

Hi Jim,

Many thx for your opinion. Very much appreciated here.

Also as we see from some proposals the core DC auto peering (also called by
some as "autodiscovery") can be done with the assistance of existing L2
protocols. So I think the fundamental first question is if this work even
belongs to IDR.


On Thu, Dec 5, 2019 at 2:50 PM Job Snijders <> wrote:

> On Thu, Dec 5, 2019 at 14:46 UTTARO, JAMES <> wrote:
>> *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.*
> I think the above is good feedback.
> Also, it appears the entire working groep is interested to be part of the
> design team. Perhaps the design team’s mailing list should be
> :-)
> Kind regards,
> Job