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

[ TL;DR - I support adoption ]

On Wed, Sep 7, 2016 at 11:33 AM, Rob Shakir <rjs@rob.sh> wrote:
> 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).

I was also part of these offline discussions - I'd really really
prefer this to be a (simple) TLV (or even just prefixed with a version
number ) so that when we realize that we want 9 local bytes[0]  we can
simply bump a version / TLV and not have this whole discussion again.

But, A: we can have that discussion once adopted and / or B: this is
good enough.
So, support adoption, want to see it move along...

>
> 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 - standardized by
> IDR does not equate to there being widely available, stable code that
> actually supports a feature.
>

What?! Mind blown -- you've shaken my entire world view...

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

Yup, what he said.

W

[0]: I want 4 bytes to stuff the peer AS in, 4 bytes to carry the RID
of the receiving router, and, um, a flavor... or preferred animal....
or region... no-idea, but I'm sure we'll come up with an important
thingie to carry in a few months...

>
> 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
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf