draft-keyur-idr-bgp-prefix-limit-orf

[Marco Marzetti]

Dear Developer of BIRD,

We're working on a draft called draft-keyur-idr-bgp-prefix-limit-orf that
you can find on IETF's website at this URL: https://tools.ietf.org/html/
draft-keyur-idr-bgp-prefix-limit-orf-02
Its goal is to allow BGP speakers to exchange maxprefix values in-band by
making use of the ORF capability.

We think the ideas expressed in the draft are very simple, but we would
like to hear from you how hard it would be to get them implemented in your
software.

Let me briefly explain how it is supposed to work.
Peer A and B set up a BGP session and set ORF as one of the active
capabilities.
Every time administrators of A change/set/remove maxprefix router A sends
an ORF message indicating to router B the new value along with the behavior
that router B must follow.

In case that the Match field is set to DENY router B will consider the
value as purely informational and will follow the usual behavior.
Else, in case Match is set to PERMIT, router B will not advertise any
prefix if that would cause the amount of advertised (non withdrawn)
prefixes to exceed router's A maxprefix value.

Please note that what described above is just a coarse summary of what is
stated within the draft.
We encourage you to read it to better understand what we're working on.

In case that you're wondering why draft-keyur-idr-bgp-prefix-limit-orf could
be useful here some real world cases:
1) Life safer for unplanned redistribution or fat fingers.
   In MPLS L3VPNs service providers often impose strict maxprefix limit as
those are commercial values discussed before of signing the contracts.
   An unplanned increment in the advertisements may break the VPN.
   In that case spokes may prefer to not to announce some routes and still
be able to reach the rest of the network from the larger part of the site
than loosing all connectivity.
   And hubs can advertise both default and more specific routes for traffic
engineering without the risk of breaking the network.

   Almost the same applies to FlowSpec where you could prefer to not to
advertise some "rules" than to get all of them withdrawn because of an
error.

 2) Easier and faster method to share maxprefix betweem peers.
   Maxprefix is one of the few protection mechanisms used by autonomous
systems when peering in the DFZ.
   When networks merge or transit providers get new large customers their
NOCs have to reach all the peering partners in an attempt to get maxprefix
updated.

  This is usually done by broadcasting the request by email to all peers
(maybe multiple times) a few weeks before of the increment.
  Then "cross the fingers" and send the additional advertisements.
  What often happens is emails got lost or unnoticed by the network
engineers of the receiving network and AS to AS connectivity breaks for
some hours or even days.

  With the proposed solution the NOCs would be able to verify if the change
has been executed before of touching anything.

At this very moment we're in the process of refining the draft before of
submitting it to the IETF community, but we do understand that internet
standards are useful only if they're supported by vendors.
For this reason we would like to hear from you how hard it could be to add
the features of draft-keyur-idr-bgp-prefix-limit-orf in BIRD.
In case that it would be too complicated please let us know how we could
make things easier.

Thank you in advance for the comments or the suggestions you would like to
make.

Regards

-- 
Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20171115/d354cd1d/attachment.html>