[Idr] draft-heitz-idr-large-community

[Robert Raszuk <[e-mail]>]

/* Renaming this conversation as this is no longer about accepting it as WG
doc, but rather general discussion about this proposal. */


>
​
Q2. If your ISP offers the service to transit communities,

The point was that we have learned since RFC1997 published 10 years back
that there is no trust in the Internet any longer. But this is perhaps more
of an SIDR issue so let's talk about it when this draft becomes WG doc.

But how to assure integrity and correctness of originating AS intention via
untrusted transit ASes ...

The security aspect of wide communities have been discussed in the past. I
am interested in this as will be very glad to use the same solution as we
accept for large communities in the wide community document. Both are
transitive via multiple ASes hence the issue.


> Q3. The spec must not enforce any stripping.

I respectfully disagree.

Sending community containing in the first 4 octets of an AS outside of a
given AS over eBGP session to me is a clear and direct indication that such
community is meaningless any longer. If so why then to allow to send it ?

Local policy of send-all would not help. Would we need soon another draft
along the lines of draft-mauch-bgp-reject to deal with large community
default pollution ?

If you rename this entire text into 4:4:4 all being of mutual agreement
between parties then my point is gone ... but till that happen I am willing
to understand the rationale.

> ​
BTW, this all works the same way as it does with regular communities.

Is that supposed to be a feature or a bug ? ;-)

Cheers,
R.


On Thu, Sep 8, 2016 at 3:08 AM, Jakob Heitz (jheitz) <[e-mail]>
wrote:

> Q1. My implementation as it stands uses ios-regex to filter, so you can
> filter whatever you want. I have an optimization in mind that will make it
> easier to match on each field individually, but it's not done yet.
> Your example: delete largecommunity not in (ios-regex '^2914:')
>
> ​​
> Q2. If your ISP offers the service to transit communities, then that ISP
> will be able to transmit the large communities unchanged with my
> implementation.
>
> Q3. The spec must not enforce any stripping. It is up to a receiver to
> strip whatever it does not want to receive. In my implementation, large
> communities are dropped by default by EBGP senders. You must
> configure send-community-ebgp if you want it to send large communities. You
> can use the delete statement of Q1 in a neighbor outbound route-policy if
> you want to selectively remove large communities.
>
> ​​
> BTW, this all works the same way as it does with regular communities.
>
> Thanks,
> Jakob.
>