Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival?

[Job Snijders <[e-mail]>]

Dear working group,

On Wed, Oct 12, 2016 at 09:54:24AM +0100, t.petch wrote:
> ----- Original Message -----
> From: "Rob Shakir" <[e-mail]>
> Sent: Wednesday, October 12, 2016 2:57 AM
> 
> > I am interested in the working group pursuing this draft. The
> > pressure behind large community seems (to me) to be very short-term
> > focused [0].  Operationally, I understand the requirement, but we
> > should also be improving the infrastructure that we have in BGP.
> > There are numerous use cases for BGP, many of which are not Internet
> > DFZ focused. As part of this infrastructure, I believe that in the
> > longer term, we need the ability to do attribute scoping in a more
> > robust way.
> >
> > The current definitions of non-transitive and transitive are overly
> > coarse for today's heterogeneous networks. It is particularly
> > important to me that we look beyond confederations as the only means
> > of grouping autonomous systems.
> 
> I agree; if we had a more flexible definition, something between
> transitive and non-transitive, then that could be an option for
> 'large'.

Tom, I disagree with your remark about 'large'. Large BGP Communities,
by design and definition, are transitive. Put differently: A 96 bit
opaque entity which is not transitive, is not a Large BGP Community. I
am sure there are some usecases for such a non-transitive tool, but call
it has to be called something different.

Rob makes an excellent observation in "we should be improving the
infrastructure", an example is that during the standardisation of the
BGP BLACKHOLE community, not everyone appreciated the transitivity of
the well known community, but non-transitive didn't cut it either for
the use case. No tools were readily available to do any better, so a
choice between the two coarse approaches had to be made. I am interested
in having non-confed-based grouping of ASNs.

Regarding draft-ietf-idr-bgp-attribute-announcement itself, I wonder if
there actually is a need to be able to define an optional transitive
extended path attribute. We already have a method to do optional
transitive attributes today, maybe there is no need to provide a new way
to perform that function.

> I also agree that 'large', while having strong consensus, is
> short-term and that we could be looking for something more in a year
> or two. (Which is a theme that recurs in the work of the IETF:-(

I am not sure if the 'short term' or 'long term' distinctions do justice
to any of the efforts. In fact, I find it somewhat insidious to call any
effort in IDR "short term". (Apologies if my interpretation is an
artifact of a language barrier)

For all of these efforts, we're often looking at multi-year projects:
huge periods of time between "draft"-phase and "widely deployed
code"-phase. Then comes the popularising phase and education phase in
which people have to be trained in how to use the new technology, etc.
Entire ecosystems need to be upgraded, this is like turning a
supertanker around.

Large is not "short-term", it exists to address a narrow use case.
draft-ietf-idr-bgp-attribute-announcement can exist to address other use
cases.

Kind regards,

Job