[Idr] draft-ymbk-idr-bgp-open-policy

[Robert Raszuk <[e-mail]>]

Dear Authors and WG,

I would like to share few observations on this proposal.

Let me start with comment that hardcoded automation is a good thing and
this does provide for automate filtering so it is very good direction which
I support.

Observations:

1. What role would be assign to peering to route server ?

2. This proposal to twick session capabilites looks very innocent on the
surface till we have seen proposal to leak local pref or send med based on
those capabilities. I am sure just around the corner there would be
proposals to stop next hop self on ebgp or to ignore extended community
transitive bit when sending to internal (even if internal is another AS).

So here I would propose to instead to hide this under the table clearly
define new types of BGP sessions with clear semantics on what is expected
from said new types of BGP sessions: to peers, to same admin peer AS, to
customers, to complex or to providers etc ...

3. It has been suggested that the default should be "customer" I think this
would be very bad idea deployment wise as it will take ages for all
customers to upgrade their routers. Instead I would propose that customers
sessions would be exactly what we have today as basic eBGP. The new
attribute imposition may be associated with current customers peerings.

Many thx,
R.