Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).

[Alexander Azimov <[e-mail]>]

Dear colleagues,

Thank you for your feedback!

I agree with Job, that every new technology should be suitable for both
"big" carriers and smaller ISPs. And in field of route leaks it is even
more crucial. The work on this draft is in process, and IMO, the current
version of draft is not ready for WGLC. I hope, that if this draft is
adopted, it will result in more comments, more feedback and will speed up
the process.

At the same time I disagree with proposal of movement toward BCP. BGP
already have all one need to prevent network from leaking routes. Still the
problem is here and it becomes even worse. Here are few noteble examples of
route leaks that took place during May:

   1. Route leak by Rostelekom (AS12389), the biggest ISP in Russia, more
   then 1k prefixes leaked from HKIX to NTT;
   2. Rote leak by Incapsula (AS19551), DDoS mitigation provider, more then
   1.5k prefixes in multiple directions;
   3. Route leak by Onlanta Ltd (AS56631), small stub ISP which leaked more
   then 50k prefixes between its providers.

While first two anomalies were short lived and affected only network
latency, the last one lasted more then two hours and resulted in channel
exhaustion and partial DoS for a number of networks. Please, correctly
understand me, this is not wall of blame, this is wall of BGP problem
itself. And a significant change in protocol design is required to avoid
existence of such mistakes.

PS: There was a comprehensive comparison between communities and path
attributes usages by Brian Dickson. While iOTC MUST not be propagated
outside ISP border, eOTC/RLP MUST not be dropped by some AS in the path.
For me it seems that in both scenarios path attributes are more preferable.

2017-06-04 19:28 GMT+03:00 David Monosov <[e-mail]>:

> On 6/4/17 1:59 PM, Job Snijders wrote:
> >
> > On Fri, 2 Jun 2017 at 20:06, Ruediger Volk, Deutsche Telekom Technik -
> FMED-41..
> > <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >       > This begins a 2 week WG Adoption call for
> draft-ymbk-idr-bgp-open-policy
> >       > (5/20 to 6/3/2017)
> >     I strongly support adoption,
> >     and consider it a worthy candidate for the being progressed quickly.
> >
> >
> >
> > Unfortunately, as it's currently specified, I still cannot see my
> affiliation
> > deploying this technology in a meaningful way.
>
> Concur. Despite a laudable goal, in its current form this technology would
> significantly constrain the flexibility afforded by community based
> policies,
> which are widely deployed.
>
> Attempting to "codify" the nature of relationships between autonomous
> systems
> into 4 broad categories is an oversimplification that has limited overlap
> with
> operational reality (as demonstrated by increasingly broad and expressive
> selection of policy communities implemented by sophisticated networks).
>
> Having to firmly constrain the nature of each relationship in advance, on a
> session level rather than prefix level, requires the operators to make a
> choice
> between two less than ideal alternatives:
>
> - Correctly select a conservative definition of their current relationship,
> reducing the operational agility if the nature changes in the future - as
> now
> both operators must agree in advance and implement a change in the
> definition of
> this relationship, flapping the session, prior to modifying policy.
>
> - Err on the side of caution and tag all sessions as "complex" to maintain
> that
> agility, eliminating the benefit of this technology.
>
> Regardless of the alternative initially chosen, it seems plausible that an
> autonomous system with an evolving set of roles and interconnects will find
> itself over time drifting toward ever more of them marked "complex" as its
> policy sophistication requirements evolve.
>
> Perhaps a better direction for this initiative, in lieu of BGP extension,
> would
> be toward a BCP outlining a checklist for defining the nature of each
> relationship as part of the on-boarding process for new interconnects - and
> providing some policy implementation examples for various cases.
>
> --
> Sincerely yours,
>
> David Monosov
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>



-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: [phone]
| mob.: [phone]
| skype: mitradir
| mailto: [e-mail]
| visit: www.qrator.net