Subject: [Idr] draft-ietf-idr-bgp-open-policy -- discussion

From: Alexander Azimov <[email-masked]>
Date: Thu, 29 Jun 2017 00:48:50 +0300

Dear IDR members!

We would like to try to start a discussion before committing actual changes
to the draft. I've tried to aggregate questions that were raised during WG
adoption call, hope this will be helpful.

It was mentioned that while mandatory status of roles is effective way to
speed up deployment process, it may also bring problems with backward
compatibility. Imagine that after software update you will get errors for
your configuration file, that was working fine. For me it seems like a
design problem that should be solved. Our current plan is to make next
changes in the draft:

   1. Remove mandatory status of roles: so, roles SHOULD be set on each BGP
   session instead of MUST. We are also going to make reference to bgp-reject
   draft, so that there will be no route exchange if there is no import/export
   policy or roles;
   2. Remove complex roles. For those who is still looking for more
   flexibility, absence of roles will provide a walk around;
   3. Clarify that iOTC MUST NOT be transmitted through
   *Customer/Provider/Pee*r sessions or unmarked eBGP sessions.

There are also few minor questions such as:

   1. We have two situations when Notification is sent: when there is
   conflict pair of roles and when strict mode is set by one side and other
   side has no roles. Should we use two different subcodes or one is enough?
   2. Proper naming of attribute: iOTC vs iOtC.

We are looking forward your comments and feedback. I'm planning to push
these changes during weekend.

PS: We would like to ask IDR chairs to give us a slot during meeting at
Prague.

-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: [email-masked]
| visit: www.qrator.net

---

From: Brian Dickson <[email-masked]>
Date: Wed, 28 Jun 2017 15:24:34 -0700

Hi, Alexander,

Please do remember, that the route-leaks draft is referencing the -open
draft, and using it for assignment of roles.

While I don't currently speak for all my co-authors, I'm pretty sure this
will be a problem.

The issue of upgrades, is something which will need to be addressed by
implementors, but one which does NOT require standardization.

So, specifically, we (IDR) would probably be best served by calling out the
need for support for upgrades, without dictating (either way) how that
should be handled.

My personal opinion is that vendors should offer a knob for how unspecified
BGP neighbors are treated (as a global item), which would be over-ridden by
per-peer config elements.

Something like: bgp default-neighbor-role FOO, and then "neighbor X
local-role FOO", "neighbor X remote-role BAR" (to the degree to which the
open spec handles local vs remote sides of a given peering session).

I disagree that removing complex and removing mandatory are either wise, or
equivalent. Recall that "complex" is something that turns off "all the
safeties", and permits EXPLICITLY all routing advertisements regardless of
relationship to "leaks".

I'm fine with #3 (MUST NOT).

I'm happy to discuss further offline with anyone who would like to chat or
needs to understand the relationship between "role" and "route-leaks".

Brian

On Wed, Jun 28, 2017 at 2:48 PM, Alexander Azimov <[email-masked]> wrote:

> Dear IDR members!
>
>
> We would like to try to start a discussion before committing actual
> changes to the draft. I've tried to aggregate questions that were raised
> during WG adoption call, hope this will be helpful.
>
>
>    1. Remove mandatory status of roles: so, roles SHOULD be set on each
>    BGP session instead of MUST. We are also going to make reference to
>    bgp-reject draft, so that there will be no route exchange if there is no
>    import/export policy or roles;
> | tel.: +7 499 241 81 92 <+7%20499%20241-81-92>
> | mob.: +7 915 360 08 86 <+7%20915%20360-08-86>
> | skype: mitradir
> | mailto: [email-masked]
> | visit: www.qrator.net
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 29 Jun 2017 17:07:10 +0300

Hi Brian,

Thank you for your feedback!

I was keeping in mind route leak mitigation issue. And for me it seems that
this update should not bring any problem to this field. We are only moving
toward simplification:
we'll have support for 'complex' behaviour without complex role itself.
We'll have no need of default role value, and it's IMO a good thing.

I agree with you that 'mandatory' status makes things different. At the
same time I've got several private feedbacks from network engineers, and
they shared concerns about possible upgrade scenario. I think that breaking
POLA should be treated very carefully. At the same time there will be still
at least four reasons to setup roles:

   - simplification of configuration process and automatic leak prevention;
   - opportunity to control your neighbor configuration;
   - strict mode on other side;
   - automatic route leak detectoin and mitigation.

Do you think it will not be enough to motivate deployment?

2017-06-29 1:24 GMT+03:00 Brian Dickson <[email-masked]>:

> So, specifically, we (IDR) would probably be best served by calling out
> the need for support for upgrades, without dictating (either way) how that
> should be handled.
>
> My personal opinion is that vendors should offer a knob for how
> unspecified BGP neighbors are treated (as a global item), which would be
> over-ridden by per-peer config elements.
>
> I disagree that removing complex and removing mandatory are either wise,
> or equivalent. Recall that "complex" is something that turns off "all the