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

Pavel Lunin <plunin@plunin.net> Thu, 11 June 2020 15:41 UTC

Return-Path: <plunin@plunin.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B1E3A09D6 for <idr@ietfa.amsl.com>; Thu, 11 Jun 2020 08:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=plunin.net
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 bL6UUu1GXsuc for <idr@ietfa.amsl.com>; Thu, 11 Jun 2020 08:41:57 -0700 (PDT)
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930D83A07E1 for <idr@ietf.org>; Thu, 11 Jun 2020 08:41:57 -0700 (PDT)
Date: Thu, 11 Jun 2020 15:41:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plunin.net; s=protonmail; t=1591890113; bh=gzgXyPZYRyIKij2btBDsKig7KaXwMD0JJrW78agil3o=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=pewQVwWht7x4dOIlvaJKGIeatmow4AoNpeJjEAMjC8IjrFYDt8g5W5ErxT/L/ChC2 tBzLUeZ0iRCXlQiQ66YUJxb8BbEm9QNom6bLgl5D8GCDIL8+TDAVq2beJvMp0W5ph0 93gO6x9U1vuz+Ok/qlSmw7EXVcBqx65BYL9iNvy8=
To: Randy Bush <randy@psg.com>
From: Pavel Lunin <plunin@plunin.net>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, Interminable Discussion Room <idr@ietf.org>
Reply-To: Pavel Lunin <plunin@plunin.net>
Message-ID: <M4M19tYJetwyBHYfRvz3CeOh6I-NMLchYe82KkJWpaQMLxLOKJZxc75yTjPwls4fOB0BywzXQetHuH4xvV3gIa8Djc61aCd1GkUoYrTyJKA=@plunin.net>
In-Reply-To: <m2a719r7w4.wl-randy@psg.com>
References: <005901d63ab5$d6003e00$8200ba00$@ndzh.com> <007801d63fc5$d02e49d0$708add70$@tsinghua.org.cn> <m2a719r7w4.wl-randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Z989Zi2n6UJi_DBBmJraA35cEyg>
Subject: Re: [Idr] =?utf-8?b?562U5aSNOiBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItYmdw?= =?utf-8?q?-open-policy-10=2Etxt_=286/4_to_6/18=29=28=2E?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2020 15:42:00 -0000


Am I wrong in my understanding that virtually any iBGP session is 'complex' in terms of this document?

E. g. an MP-BGP session between an MPLS PE and route reflectors, is it 'complex'?

As I see no other special clause in the document to treat iBGP, as of my understanding, all iBGP is 'complex' so no roles needed.

Another kind of 'complex' peering might be some sort of 'non-Internet eBGP': leaf-spine eBGP fabrics for example. Or any VPN eBGP: inter-provider option C, eBGP over IPSec in the enterprise between hub site and branches etc etc.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, June 11, 2020 4:31 PM, Randy Bush <randy@psg.com> wrote:

> > Can the authors give more explanation on the following description in
>
> > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-10#sect
> > 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. :)
>
> randy
>
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr