Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)

[Brian Dickson <[e-mail]>]

On Mon, Nov 7, 2016 at 9:40 AM, t.petch <[e-mail]> wrote:

> ----- Original Message -----
> From: "Peter Hessler" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, November 07, 2016 10:23 AM
>
> > In OpenBGPD our default is to propagate communities; normal, extended,
> > and large.
> >
> > We have no intention on changing that default.
> >
> [snip]
> > This is implementation specific, and has nothing to do with the
> > standardization process.
>
> Peter
>
> I think that that is spot on.
>
> Customers will expect consistent behaviour from a supplier (and equally
> should be prepared for change if and when they change supplier).
>
> Of course, it may not always be that straightforward as implementations
> need to interoperate, first and foremost; but if they have been doing
> that, albeit not following the precise specification of a transitive
> attribute, then I think that consistency is what is needed.
>
>
What I think need to be (re-)emphasized, and which is the reason I started
this thread:
Interoperability is an issue, both INTRA-ASN as well as INTER-ASN.

Incremental deployability in a heterogenous environment, of an incremental
method for supporting an existing function, is something that requires
operator control.

So, while defaults matter, knobs to control those behaviors matter more.

Say someone has a network with vendors X, Y, and Z. Say they use RFC1997
communities substantially, and want to deploy LC.

Doing so requires incrementally upgrading some subset of routers, with
several iterations. Some of those upgrades are likely to be "some of X
only", etc.

Without a knob to disable (or possibly enable) propagation of LC, when
doing an upgrade to a version where LC is understood (on a single router),
the behavior will depend entirely on what vendor X's upgraded code does.

I don't consider that sufficiently constrained behavior for an incremental
upgrade. Not having a knob means either "random behavior", or "flag day"
(requiring simultaneous upgrades to all routers of all vendors).

What matters to me, as an operator, is that I can control all my routers,
especially if the default behavior of each router "flavor" differs, and
most especially if that behavior differs across software versions.

Most of the discussion has presumed homogenous ASNs, which is not
universally the case (and in my experience is seldom the case these days.)

The fact that LC will be incrementally deployed alongside 1997, makes the
issue much more significant, IMHO.

Maybe folks from various vendors (including open source implementations)
could chime in on the availability of knobs for changing global (default)
behavior on 1997 and LC, and whether those traditionally have the same
default and/or are controlled by one knob (versus two)?

Brian