Re: [Idr] 答复: WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.

Randy Bush <> Thu, 11 June 2020 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E26A3A0943 for <>; Thu, 11 Jun 2020 07:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S6bj0NrtZ2g3 for <>; Thu, 11 Jun 2020 07:31:44 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BD1E3A095F for <>; Thu, 11 Jun 2020 07:31:44 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.90_1) (envelope-from <>) id 1jjOF1-00031x-RY; Thu, 11 Jun 2020 14:31:40 +0000
Date: Thu, 11 Jun 2020 07:31:39 -0700
Message-ID: <>
From: Randy Bush <>
To: Aijun Wang <>
Cc: Interminable Discussion Room <>
In-Reply-To: <007801d63fc5$d02e49d0$708add70$>
References: <005901d63ab5$d6003e00$8200ba00$> <007801d63fc5$d02e49d0$708add70$>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-2022-JP
Archived-At: <>
Subject: Re: [Idr] =?gb2312?b?tPC4tDogV0cgTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWJn?= =?gb2312?b?cC1vcGVuLXBvbGljeS0xMC50eHQgKDYvNCB0byA2LzE4KSgu?=
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, 11 Jun 2020 14:31:46 -0000

> Can the authors give more explanation on the following description in
> ion-8:
>    There are peering relationships that are 'complex', i.e., both
>    parties are intentionally sending prefixes received from each other
>    to their non-transit peers and/or transit providers.  If multiple BGP
>    peerings can segregate the 'complex' parts of the relationship, the
>    complex peering roles can be segregated into different normal BGP
>    sessions, and BGP Roles MUST be used on each of the resulting normal
>    (non-complex) BGP sessions.
> Some figures or more detailed explanations will be helpful to get the
> description of “complex”.  Is there any situation that the multiple BGP
> peering can’t be segregated?

we call such relationships complex because they have been quite varied.
so i am not sure how far down this rabbit hole alexander wants to go.

but let me give you an example.  i can use this one because the
relationship was publicly discovered and then disclosed.

back in the day, i think it was PSInet and AboveNet were in a peering
war.  it was causing actual damage to a significant population.  so
verio, which peered with both, configured to transit them to eachother
through verio in the middle note that this was an intermediate party
giving partial (only some routes) transit to two other parties.

now this is but one example, trying to get folk to think about how large
and complex the space of complex relationships is.  so i am not too
supportive of trying to describe the space in any formal sense.  while
gao rexford has been well demonstrated not to always hold, it is a
wonderfully simplifying assumption which lets us think about things and
then say that the rest is complex. :)