Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

[Robert Raszuk <[e-mail]>]

I must admit that you are right to say that true skill is in finding some
way to help address the problem for vast majority of deployments.

I also agree that while best protocol design skills are in addressing
corner cases here no loop will form and no harm to routing would be done if
say 5% disable that capability.

However my honest observation is that this approach would work well when
operators would only operate on binary BGP code with such functionality
enabled as mandatory capability and be always ON by default with no option
to disable it.   Said this we all have to admit that such times are long
gone and as soon as NOC have a business case and chance to disable it their
marketing folks will force them to do so.

So the real question comes to the point if IDR is in position to issue RFCs
to test ISP marketing guys in their level of power to enforce big vendors
to add knobs disabling such capabilities or speeding up shifting to open
source BGP ....

Tx,
r.



On Sat, Jun 11, 2016 at 4:04 AM, Randy Bush <[e-mail]> wrote:

> >> In spite of your concerns RS is a perfect place to deploy roles: RS does
> >> not provide IP-transit (if there are no leaks!) but it *provides* local
> >> connectivity. So, RS is provider for all its neighbors.
> > You mean other then FT's OpenTransit ?
>
> welcome to the kinky internet, where every thinkable and unthinkable act
> is done; after all, it was invented in california. :)
>
> if you are planning something kinky, do not bring a straight friend to
> the party.  that is, as i said to job, if you intend to violate valley
> free or peer-peer, do not run mechanisms designed to detect these as
> errors.
>
> perhaps we should design for the norm.  with things this complex, we can
> always find corner cases.  though i guess one can make a career out of
> finding them; it's a target rich environment.  true skill is in finding
> the simple middle path.
>
> randy
>