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

I agree with all statements made by Rob S.

Kay's email however triggered the clarification question to the current -03
version.

What is the meaning of explicit AS number listed in the first 4 octets of
the community. I was under impression that originally it was the AS number
in which given community needs to be executed however it seems that this
sentence is no longer in the current version of the draft.

So it may be unclear if this is AS number inserting this community, if this
is target AS to execute it or perhaps like in the case of Route Server is
it AS acting as proxy for other ASes it peers with ?

The answer could be none of the above - it's all local significant - but
then shouldn't it rather use a 4:4:4 description.

Thx,
Robert.

On Wed, Sep 7, 2016 at 5:33 PM, 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).
>
> 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
>>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>