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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>:
>>
>>>
>>>
>>> On Thu, Jun 11, 2020 at 11:14 AM Sriram, Kotikalapudi (Fed) <
>>> [e-mail]> 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