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

[Job Snijders <[e-mail]>]

On Fri, 2 Jun 2017 at 20:06, Ruediger Volk, Deutsche Telekom Technik -
FMED-41.. <[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.

The word "peer" is extremely overloaded: it is a homonym which conflates
all kinds of concepts. The term appears in too many training courses to be
redefined to one specific meaning. On top of that, I all too often see that
provisioning- or customer engineers don't have clear insight as to who is
customer and who the supplier is. Even worse: a customer may assume the
supplier role as part of a larger deal. While in the hallways we easily
talk about simplified models on how the internet works, actually enforcing
that simplification in the context of EBGP to me is undesirable.

Any technology that is supposed to mitigate route leaks, should be
deployable both by the "big" carriers as well as stub network at the edge
and anything in between. If we end up with carriers flagging all relations
as "complex" or not even enabling the capability to enjoy backwards
compatible behavior, that would be no good.

Perhaps if the draft would focus on merely two classifications: "stub" and
"transit" networks, where the former would be an affirmation that neither
party expects the "stub" network to transit prefixes for any other ASN, and
transit networks would enjoy the same behavior as any ASN today, that would
give a different twist to this idea. Downside is that one needs to bounce
the session to become a transit provider.

Or perhaps we should look for other options: I'm interested in technology
that both myself and my customers can deploy. Preferably relationship
agnostic, and with per prefix granularity. Any proposal that avoids
explicit coordination between the two entities has a strong preference
compared to requiring agreement to which number we dial up a knob.

 I'm somewhat torn between adopting this document as a working group
document, to use it as a springboard to other ideas and hopefully end up
with something more deployable before WGLC; and opposing it and simply
encourage further research on what can be done (or should not be done) in
"OPEN" protocol space.

Secondly: the use of a path attribute vs well-known communities is still an
ongoing dilemma for me. Previously I've elaborated on some pros and cons
from my perspective. I'm not convinced the approach as chosen by this
specification is beneficial as it doesn't easily accommodate incremental
deployment within an autonomous system.

Kind regards,

Job

>