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

Pavel Lunin <plunin@plunin.net> Thu, 18 June 2020 00:05 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 A9DE63A0542; Wed, 17 Jun 2020 17:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level:
X-Spam-Status: No, score=-2.09 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 iRPkfy3mZg39; Wed, 17 Jun 2020 17:05:41 -0700 (PDT)
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (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 A6D953A0486; Wed, 17 Jun 2020 17:05:40 -0700 (PDT)
Date: Thu, 18 Jun 2020 00:05:30 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plunin.net; s=protonmail; t=1592438737; bh=tUWb9LaNEdmZMn9jwuzI7jY3Qn5jF9bJ2MgDEO8mR0E=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=ULOuyaft9ZFL+WgmwManzM9JJjMJvrkIaqi9Crw+XjZFBWrsvBBeA/FTVTvDS3ZK3 eFhZiBQB3ISuQP308mZvCCBf26Q9WEbrqxxkG6SgbIbQec/fXQcHoSPwRMlDokN/lp bqd5yLKzc9w5arRv+K8r06bYOXLl9dK40AWehE3Q=
To: Gyan Mishra <hayabusagsm@gmail.com>
From: Pavel Lunin <plunin@plunin.net>
Cc: Alexander Azimov <a.e.azimov@gmail.com>, "idr@ietf.org" <idr@ietf.org>, "Sriram, Kotikalapudi \\(Fed\\)" <kotikalapudi.sriram@nist.gov>, "draft-ietf-idr-bgp-open-policy@ietf.org" <draft-ietf-idr-bgp-open-policy@ietf.org>, Susan Hares <shares@ndzh.com>
Reply-To: Pavel Lunin <plunin@plunin.net>
Message-ID: <1I5kSYmFCnCUqB7qk3imIzKsvcG9YSlxnlGt2gFzkBOLXOeBiFxN_AuTZtLjscmeTuKr-CwR0goG0blkuOX6CuOTKFiPq40K82UX19VOm8I=@plunin.net>
In-Reply-To: <CABNhwV2-6aRek11bD0zjZ1wmbr+7So-M55wUbfk_m77D6wDxbg@mail.gmail.com>
References: <BL0PR0901MB3682A78982CD60BF5D8039A084800@BL0PR0901MB3682.namprd09.prod.outlook.com> <CABNhwV1e9nu336Y-WRB=d=8zo3Gyc4FB_-SeDf50NSRQCHOirQ@mail.gmail.com> <CAEGSd=DfKmpEqZuTHy=FuuWHiCViHC5Wm0HcyqSx4c72R9QNbQ@mail.gmail.com> <CABNhwV2-6aRek11bD0zjZ1wmbr+7So-M55wUbfk_m77D6wDxbg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_32hYFmTiCNvAY9XxmMj69I0myiZdY6uKxB7BorwPsXc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/qLdBahpC0N7DPDlGzpmdA_Zh1LQ>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.
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, 18 Jun 2020 00:05:44 -0000

Gyan,

Sorry for replying for the authors but it looks like there is a misunderstanding here:

>So this feature would need to support SAFI 128 for inter-as options or in SR case SR-TE binding sid policy.

As I understood, the current draft already implies such support. All BGP sessions can have role capability announced and consequently nothing prevents you to use roles for inter-as option C or any-other non unicast inet/inet6 eBGP sessions in accordance with the current edition.

However the draft says that it makes no assumption about such use cases. E. g. the question if this is practically useful or not is out of scope of this document and should be answered by the network operators individually.

And I think it is a good idea to keep it like this, as potentially you can have an unlimited number of such use cases. Option C inter-as L3 VPN is only one of them but I can easily imagine eBGP EVPN type5 in the DC applications, inter-domain flowspec eBGP, iner-as service controllers with eBGP injectors and all sorts of other things where roles could be potentially useful.

However if we try to describe all such cases in a single document, it's not going to be complete ever and the draft will become endless. So instead of trying to list them all in the same initial draft, it's probably a better idea to let people write separate documents explaining how such cases should work (probably new roles should be introduced for flowspec etc etc).

Also, as of my experience, it doesn't look like in the today's world "Internet over multi-as VPN" is a source of route leaks (in contrast to vanilla inter-domain eBGP). Technically nothing prevents us to use roles here, but in fact such use-cases almost everywhere imply granular routing policies at the AS borders, so the practical advantage of role-based policies here is potentially arguable. Don't get me wrong, I am not saying that it's useless, just it depends a lot on a context of a particular network.

I think, the best way to deal with this is not to advise anything here, just make the role capability be configurable for any BGP session and let network operators decide themselves if they want to go further than "classic" cross-domain eBGP unicast inet/inet6. If this "flies" for the basic use case, people will definitely invent fancier ways to use roles and write separate drafts for them.

--
Pavel

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, June 17, 2020 11:54 PM, Gyan Mishra <hayabusagsm@gmail.com> wrote:

> Hi Alexander
>
> Thank you for responding as far as vendor implementation status and compatibility.
>
> I mentioned this off list to one of the other authors
> Sriram.
>
> One aspect of this role feature that is critical to Verizon is if this feature can be used with SAFI 128.
>
> Verizon as well as most other Tier 1 / 2 providers carry the internet table in a separate IP VPN VRF over an MPLS or SR core and keep the global table clean of just operator IGP connected prefixes carrying topmost label FEC binding only and not cluttered with the internet BGP table.
>
> So this feature would need to support SAFI 128 for inter-as options or in SR case SR-TE binding sid policy.
>
> Kind Regards
>
> Gyan
>
> On Tue, Jun 16, 2020 at 4:48 PM Alexander Azimov <a.e.azimov@gmail.com> wrote:
>
>> Hi Gyan,
>>
>> As it was discussed in the mailing list the two of three current implementations are based on open source software: BIRD and FRR, they are compatible. We haven't yet tested intercompatibility with Microtik. There were also plans at the openbgpd community, but as far as I know, now results yet.
>>
>> From Yandex, we are planning to add Open Policy as a feature request for Juniper. I know that DTAG has already made these requests for its vendors. If Verizon will also ask for this feature it may get more momentum.
>>
>> пт, 12 июн. 2020 г. в 20:28, Gyan Mishra <hayabusagsm@gmail.com>om>:
>>
>>> On Thu, Jun 11, 2020 at 11:14 AM Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov> wrote:
>>>
>>>> Hi Gyan,
>>>>
>>>>>I support this draft and believe the specification is ready for publication.
>>>>
>>>>>I think the role capability for auto route leaking mitigation is very
>>>>>valuable for both service providers as well as very large enterprises.
>>>>
>>>> Thank you.
>>>>
>>>>>This WGLC draft along with below route leak detection of well known large
>>>>>BGP communities can help tremendously in automating route leak mitigation.
>>>>
>>>>> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02
>>>>
>>>> Appreciate the comment. We plan to request a WGLC in GROW for the above draft soon.
>>>>
>>>>>BGP Large Community
>>>>>https://tools.ietf.org/html/rfc8092
>>>>
>>>>>Speaking from the looking glass of a tier 1 provider Verizon we could
>>>>>definitely benefit from the role priority feature from the leak types
>>>>>described in RFC 7908.
>>>>
>>>> I think you meant '...definitely benefit from the role priority
>>>> feature [to protect] from the leak types described in RFC 7908'.
>>>
>>> Gyan> Yes that is what I meant
>>>
>>> So the two implementations that were done and interoperability which were the vendors?
>>>
>>> Also if the beta code feature is available do you have any operators testing the code?
>>>
>>>> Great to hear that.
>>>>
>>>> Sriram
>>>>
>>>>> https://tools.ietf.org/html/rfc7908
>>>>
>>>>>Kind regards
>>>>
>>>>>Gyan
>>>
>>> --
>>>
>>> http://www.verizon.com/
>>>
>>> Gyan Mishra
>>>
>>> Network Solutions Architect
>>>
>>> M 301 502-1347
>>> [13101 Columbia Pike](https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g)
>>> [Silver Spring, MD](https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g)
>>
>> --
>> Best regards,
>> Alexander Azimov
>
> --
>
> http://www.verizon.com/
>
> Gyan Mishra
>
> Network Solutions Architect
>
> M 301 502-1347
> 13101 Columbia Pike Silver Spring, MD