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

Gyan Mishra <hayabusagsm@gmail.com> Thu, 18 June 2020 02:40 UTC

Return-Path: <hayabusagsm@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 D1E1A3A0C87; Wed, 17 Jun 2020 19:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 tFDJR7sacbqU; Wed, 17 Jun 2020 19:40:55 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 651D43A0C73; Wed, 17 Jun 2020 19:40:55 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id 9so4330602ilg.12; Wed, 17 Jun 2020 19:40:55 -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=pTu5znV6EJqJnpQrowUCQLjuQ6oWOpDlXNLTesNbmwg=; b=ELLEDULQ2X4qNzJ0tYP//Dom+NQt0ndjmFv+pDdxD6uRMCH0QeDIlPMdXvhMcRqHjc fFCfJuJYfimUjUpCzxiypQZGkFfxSXpCEOG4z//mk3QHtALbYRaDs9VvaF0ZXfY4rVXL EnqxH3UfaR4ywaV0bE3onwUyR5tdBiUJf6VkJv81kx3ivmIW7cHtDcEFRE6TMxkgfgRT REGSmB3gdQWtBhAnS10BAIRPDIBwlZ0aJ+FB33NTZ14UPbNraXSopf0L/M2lx11v9TeO CPpdGqmWsMleqRTMYaIXdeNcRPE/r3+nd3OrrM2AN+Ei2/wYNZB0Hxuqyv2U046g2tya jV9g==
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=pTu5znV6EJqJnpQrowUCQLjuQ6oWOpDlXNLTesNbmwg=; b=hGdQULJjw9GO+XrtHC1nyXMz4HwsxgqX+ektNbqXUA62+r9nn1ywyqLajZYggbIyLu SjgxPl5eZiJ53RXTPocvhK7Hu9cjbSEmJQBbQQGPdiVQ3S1O8ana5oWr2mno16Tlr5Gw iZzdBsOIT1MnU2VhXxSd4a16swe6UlCyEovLUjBYk4ddgRcsVr/qhp/TFYHCp5F78rLy uh+f/rcU3FJ1mcIed5g6LSklufjinyDzc32mlmKheO9tDSP5y22Z1B0imbl4uEuaKBOX P7Ay+SI5hVIe/y5zRNxeWN25ksdUzbMrjj4AHOUPWJfsI6thyvzzsh8AyKHNO/hvGQnK oXDA==
X-Gm-Message-State: AOAM531xD0GSpFcBfY1BEkpZHJ6rksLpAI14OtdTaKY88xjbYCqpSQWb sWLTxhkdlI79v9O1HNZ8vRwFrwTUi5lEIFaluqA=
X-Google-Smtp-Source: ABdhPJwbm2WEkDDfUPXctr2S209vMVSp8LsmNZ4nCa+mBGLoRkLVvNUeTQKd1ZQrpPcLLxELSvxvaemKL5cw35cEVh8=
X-Received: by 2002:a92:ab04:: with SMTP id v4mr2035472ilh.186.1592448054589; Wed, 17 Jun 2020 19:40:54 -0700 (PDT)
MIME-Version: 1.0
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> <1I5kSYmFCnCUqB7qk3imIzKsvcG9YSlxnlGt2gFzkBOLXOeBiFxN_AuTZtLjscmeTuKr-CwR0goG0blkuOX6CuOTKFiPq40K82UX19VOm8I=@plunin.net>
In-Reply-To: <1I5kSYmFCnCUqB7qk3imIzKsvcG9YSlxnlGt2gFzkBOLXOeBiFxN_AuTZtLjscmeTuKr-CwR0goG0blkuOX6CuOTKFiPq40K82UX19VOm8I=@plunin.net>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 17 Jun 2020 22:40:16 -0400
Message-ID: <CABNhwV3GJ5PaxxZx-_0pWYy=E2qiJq4H1V7=QXT182srTj7kjg@mail.gmail.com>
To: 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>
Content-Type: multipart/alternative; boundary="0000000000009e0e8705a852b405"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/y-qaizIWkXoYYqOp6Wx3nOscDhQ>
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 02:40:58 -0000

Makes sense as this is the introduction of the feature which can be built
on with as you said many unlimited use cases which can be addressed in
subsequent drafts.

Thank you

Gyan

On Wed, Jun 17, 2020 at 8:05 PM Pavel Lunin <plunin@plunin.net> wrote:

> 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 A**rchitect *
>>>
>>>
>>>
>>> *M 301 502-134713101 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 A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>
>

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD