Re: [Idr] Request to adopt draft-heitz-idr-large-community

When we discussed this in the WG, and I discussed it offline with Job, I
was in favour of a more generic TLV-based community encoding. The reasoning
being that it seems (to me) that we are creating a new attribute which
suffers from the exact issue that has prompted its creation (that is to
say, a fixed length, which we'll subsequently then want to change the
format of).

However, there is also a pressing operational need, as per the folks
replying to this thread, so the question really becomes, should we allow
perfect to be the enemy of "shipped"? It seems a shame to me that we should
proceed with a solution that is not particularly future-proof, but then the
cost of creating new attributes is also not particularly high. It's also
noteworthy that, as Job noted, there seem to be zero implementations of the
alternate solutions to this problem that have been around in the WG for a
long time. If those alternate solutions would like to progress, then
AFAICS, there is no reason that they could not do so in parallel to this
work - with their longer implementation cycle, and additional complexity.

I'd also remind folks of something I mentioned in Berlin - standardised by
IDR does not equate to there being widely available, stable code that
actually supports a feature.

So, given these reasons - I'd support this progressing (quickly) through WG
adoption, and if sufficient implementations exist, almost immediately to
last call.

r.

On Wed, Sep 7, 2016 at 6:41 AM, Kay Rechthien <kre@ecix.net> wrote:

> Hi IDR,
>
> > On 06 Sep 2016, at 13:39, Job Snijders <job@ntt.net> wrote:
> >
> > Dear IDR, fellow network operators,
> >
> > I would like to request that the IDR Working Group adopts
> > draft-heitz-idr-large-community [1] as a working group document.
> >
> > ...
> >
> > Kind regards,
> >
> > Job Snijders
> > (co-author draft-heitz-idr-large-community)
> >
> > [1]: https://tools.ietf.org/html/draft-heitz-idr-large-community
>
> we, ECIX, support this proposal.
> We run IXPs with BGP community based controllable route-servers, where the
> peer has the ability to block announcements to certain other peers based on
> the ASN. As we use 65000:XXX, where XXX is the ASN which should not receive
> the route, this proposal would give us the option to also extend the
> control-mechanisms towards 32-bit ASNs and not just 16-bit ASNs anymore.
>
> Best Regards
> Kay
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>