Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

[Brian Dickson <[e-mail]>]

On Fri, Oct 21, 2016 at 12:51 PM, Robert Raszuk <[e-mail]> wrote:

>
> Please let operators worry about their own filtering policies (or lack
>> thereof) and leave such recommendations to the BCP/GROW document.
>>
> ​This is IETF WG and I find such comment inappropriate. This discussion is
> about extending BGP protocol and we all should be worried how to apply
> effective policy on something which is being defined here.
>
> So triggered by the above let me ask a very simple question. You and
> others expressed very clearly that LCs should traverse N-ASes and be
> executed somewhere remotely. Great.
>
> Let's also assume that you talk to everyone in the path and convince them
> to let your LC go through.
>

This is not how communities (large or RFC1997) work, generally.

The general flow of BGP announcements is;
originator -> (0 or more transit hops "upward" toward the DFZ) -> (across 0
or 1 peering connections) -> (0 or more hops "downward" from provider to
customer, away from the DFZ)

When flowing "upward", if communities are sent, the are generally
propagated. AS hops in the middle may add additional communities (large or
RFC1997 or both).

When crossing a "peer" connection, some filtering and/or evaluation may
occur, on either the sending side or the receiving side, or both.

When flowing "downward", whether communities are sent AT ALL is typically a
local configuration thing, but if they are sent, typically they are sent
unmodified.

Other than local agreements between peers, or between transit providers and
their customers, NO TALKING OCCURS, and it is unreasonable and unscalable
to assume or require that activity.



>
> Question:
>
> If you choose to inject LC in the format TARGET_ASN:ACTION:PARAMETER based
> on what field is anyone in the BGP propagation path supposed to let's your
> LCs go and stop all other 1000s of LCs injected by anyone else ?
>

(I assume you meant "stomp" not stop.)

Based on no field. Everyone in the BGP propagation path is expected to pass
it or not, based only on local policy for the incoming or outgoing peering
session, and NOT BASED ON THE LC.
The exception is when the local ASN of the particular BGP hop, is the
TARGET_ASN.

The decision by any ASN will generally be one of:
- I don't send communities to neighbor X (where X can be upstream transit,
downstream client, or peer), so I strip ALL communities (or more correctly,
don't send the communities)
- I do send communities to neighbor Y (and pass the communities untouched,
or with an injection of my own set of configured communities per local
policies)
- I am TARGET_ASN, and do something special to the specific LC that starts
with TARGET_ASN, but DO NOT touch any other LC's attached to the prefix

LC are transitive, opaque, and additive; injecting an LC does not "stomp"
on any other LC in the sequence of LCs.

There is a possibility that the number of LCs exceed the capacity of the
UPDATE, in which case something has to happen according to the general RFCs
dictating error handling for this prefix.

The AS_PATH or AS4_PATH observed on the internet (excluding AS-path padding
via AS prepends) is typically on the order of 4-10, including the up, peer,
and down hops. This does not reach "1000s", as those are per-prefix counts.


>
> Today RFC1997 don't go far as they have no way to apply per their
> originator permit or deny statements.
>

Correct, and that is all that is being asked here - parity with RFC1997.

There is no requirement or demand for originator -anything-.

Brian