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

Alexander Azimov <a.e.azimov@gmail.com> Thu, 11 June 2020 20:07 UTC

Return-Path: <a.e.azimov@gmail.com>
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 AAE5F3A0CBA for <idr@ietfa.amsl.com>; Thu, 11 Jun 2020 13:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 nhDUbK1drRMn for <idr@ietfa.amsl.com>; Thu, 11 Jun 2020 13:07:10 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3123A0CB7 for <idr@ietf.org>; Thu, 11 Jun 2020 13:07:09 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id 25so6547746oiy.13 for <idr@ietf.org>; Thu, 11 Jun 2020 13:07:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=naJ5G+NHm8GIwcF4Ok63dmfhCBjMc7bYHW7NkUqHJBE=; b=p/gal2/PVJcy2xqcWOAfWF5OPddX4dDP67kD1LpZ2cQO+IkMaBoCXvuMlF35iM7rtp TvRe8zQi6QVQpgHye/8J5bFCu3hoWo1qVCgwbUDn9pwaYwxRq/MFpY8ZRB8InqmhgbYF uxbgJzKx2Wo+x+2VioW2SHvwCyL5/pkZ0voSXfDxIwjiWVEHIz4qe8qx6NhkHmY7xXos E9FIfa1PHHZ3v5ylpjA+5uDYVR/iPnW7BkuAXhkoqhQ0NzNY1VgQ0lSQUSUL3a3fCTqN l0T/KbWTcr9wTYQNvyQgY0OOjwSe67dDxngPfzkCFL1WknVJr7QuiY/xxxqDdMNPURRM UkTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=naJ5G+NHm8GIwcF4Ok63dmfhCBjMc7bYHW7NkUqHJBE=; b=aBUfHdrYgDI8HlWj86kDdrc3IiyswLxeS54ri0E5pni3dVe8/21756GfrwJVAHDaO+ rVjoqS/u4EGxBsiyCwHY/rxhmeNoySplwAu6aTzrcMLFYVrOIYT4bn7LxtRWE2U19i9H ROGuDjOtXFrEyL6gMrrARWGq1ZEqgJoFlTKfLVk0sqioSwqgqDTBFONOrmZUHwyoNdAw b+Hs63eYlzFjcmYQCKJssG0GLBlwc4Cp071AIFOctUWGfeU5Fuy/fYSv4I3HS1dyjtuk lynAq0WBrLLZoQAbYjqvJdNzoidvrJKLyrPz4vOwZNLOvMLQhsFrFpSzOrzkkzZzMJZo ZomQ==
X-Gm-Message-State: AOAM533VG9lqZzrGhp/QkzuTua7d7BYfPrpZNVXYEva8sc8eRQgZ1qRf kynuoMI0NGUxEOUiiuD/cbJsMi/HtItQVxdCzvbHQ5j1
X-Google-Smtp-Source: ABdhPJwVi7vGtq7QecyV3XMQJjLzWtmhz6vTWPEZ20DUKQVfLsPJFSCo7QMoqXdZxljSR/hDDfPPpieyNcxJSlMt9+Q=
X-Received: by 2002:aca:4b91:: with SMTP id y139mr7623547oia.128.1591906029012; Thu, 11 Jun 2020 13:07:09 -0700 (PDT)
MIME-Version: 1.0
References: <005901d63ab5$d6003e00$8200ba00$@ndzh.com> <007801d63fc5$d02e49d0$708add70$@tsinghua.org.cn> <m2a719r7w4.wl-randy@psg.com> <M4M19tYJetwyBHYfRvz3CeOh6I-NMLchYe82KkJWpaQMLxLOKJZxc75yTjPwls4fOB0BywzXQetHuH4xvV3gIa8Djc61aCd1GkUoYrTyJKA=@plunin.net>
In-Reply-To: <M4M19tYJetwyBHYfRvz3CeOh6I-NMLchYe82KkJWpaQMLxLOKJZxc75yTjPwls4fOB0BywzXQetHuH4xvV3gIa8Djc61aCd1GkUoYrTyJKA=@plunin.net>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Thu, 11 Jun 2020 23:06:57 +0300
Message-ID: <CAEGSd=Dx5XkhAASnHjrvafTcY+4kKsXToZytoV-vx_HARDss5Q@mail.gmail.com>
To: Pavel Lunin <plunin@plunin.net>
Cc: Randy Bush <randy@psg.com>, Interminable Discussion Room <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000600ccf05a7d481b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ThCOB34YrnAMNxVcpW3Zie29tz8>
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 20:07:12 -0000

Dear colleagues,

Thank you for your comments. I'll try to clarify questions regarded to
complex relations and applicability of roles to iBGP sessions.

In the majority of cases in the document and especially for the 'BGP Role
is a new configuration option that SHOULD be configured on each BGP
session.' was meant eBGP session between ISPs. The wrong wording grows from
the old version of the drafts where we had an additional 'Internal' role.
It was removed because it had no use for the route leak prevention and
detection while adding additional complexity. This confusing wording will
be fixed.

The 'complex' cover cases where peering relation between parties is a
combination of c2p/p2p/p2c relations. Here are a few examples:

   - Two ISPs provide transit service to each other - it may be paid
   transit or free, it just exists. In some works, this relation is called
   siblings;
   - Two ISPs have customer-to-provider relation in one region peer for
   free in another region.

The point of the draft that was quoted by Aijun suggests that different
peering relations can be separated in different BGP sessions thus giving a
way to keep full beauty of automation that is provided by BGP roles. For
the second example - it works out of the box.

чт, 11 июн. 2020 г. в 18:42, Pavel Lunin <plunin@plunin.net>et>:

>
>
> 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
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>


-- 
Best regards,
Alexander Azimov