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

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 11 Jun 2020 15:14:49 +0000

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'.

Great to hear that.

Sriram

> https://tools.ietf.org/html/rfc7908 

>Kind regards

>Gyan

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 12 Jun 2020 13:27:38 -0400

> 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?

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Alexander Azimov <[email-masked]>
Date: Tue, 16 Jun 2020 23:47:58 +0300

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.

-- 
Best regards,
Alexander Azimov

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Jun 2020 17:54:50 -0400

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 <[email-masked]>
wrote:

>>  So the two implementations that were done and interoperability which
>> were the vendors?
>>
>> *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
>
-- 

*Gyan Mishra*

---

From: Pavel Lunin <[email-masked]>
Date: Thu, 18 Jun 2020 00:05:30 +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 <[email-masked]> wrote:

> Hi Alexander
>
> Thank you for responding as far as vendor implementation status and compatibility.
>
> 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 <[email-masked]> 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.
>>
>>> On Thu, Jun 11, 2020 at 11:14 AM Sriram, Kotikalapudi (Fed) <[email-masked]> wrote:
>>>
>>>> Hi Gyan,
>>>>
>>> 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
>>>>
>>> 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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Jun 2020 22:40:16 -0400

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 <[email-masked]> wrote:

> 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
>
> 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.
>

-- 

*Gyan Mishra*

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 18 Jun 2020 18:46:56 +0000

Hi Andrei,

>I read the latest version (draft-ietf-idr-bgp-open-policy-11) and agree
>that is it ready for publication.
>
>The only suggestion I may make it to be even more explicit about how
>roles and OTC are supposed to be set or not when announcing routes
>internally (e.g. iBGP). I am referring to the issue that Pavel Lunin
>brought up. I think a sentence in the Introduction explaining the scope
>would help.

Thank you for your comments. Per your suggestion, we (authors) can plan
to include the following text in the introduction:

The new path attribute -- Only to Customer (OTC) -- is intended to be set or utilized
at ingress/egress of eBGP connections. OTC is an optional transitive attribute
and once it has been set, it is subsequently carried unaltered in iBGP and eBGP. 

Sriram

---

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 19 Jun 2020 09:50:28 +0200

Thank you, Sriram, this works for me.

Andrei