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

[Robert Raszuk <[e-mail]>]

Peter,

Who you control (who is the target of LC - can be expressed in the second 4
octets). And as such at least original discussions were about it.

So if you inject a large community it would have format:
SRC_ASN:DST_ASN:ACTION

In your specific case it would be: 1234:5678:ACTION

The comment was made that there is no way for implementation to insert
valid SRC_ASN .. well it clearly is.

But I am not suggesting spec should enforce it as it does limit use cases
for LC by not allowing to overload first 4 octets. On the other hand it
does provide more responsibility to whoever is injecting LCs so does
improve on BGP clarity and stability from protocol point of view.

Fixing on meaning on first 4 octets also provides very good tool to policy
filtering rules as you know what to expect there. For example you may have
policy allowing to pass any LC where first 4 octets contain any ASN also
listed in your AS_PATH - otherwise drop it. That may effectively help to
support LC global deployment much easier including the N-hops away
destinations.

Thx,
r.


On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler <[e-mail]> wrote:

> On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote:
> :Hi Martijn,
> :
> :> Secondly, there's literally no way for the vendor to check whether an
> :> ASN belongs to "the entity that defines the meaning of the rest of the
> :> Large Community"
> :
> :Why not ?
> :
> :If you do not make those 4 octets configurable by spec and always fill it
> :with AS number defined in your BGP instance you will have assurance it
> :is ASN of the entity that defines the rest 8 octets of the LC as otherwise
> :you will likely not establish any EBGP sessions to your peers.
> :
> :So there is very easy way to enforce it today in any BGP implementation.
>
> Say I am AS 1234, and I want to control AS 5678.  My transit ISP is AS
> 9876.
>
> If I set
>
> local-as 1234
> peer-as 9876
> set large-community 5678:666:1
>
> How is the implementation supposed to know to allow it?
>
> Limitations in the implementation completely defeat the purpose of this
> spec.
>
>
> :However the question is should it be enforced at all ?
> :
>
> MUST NOT is a very important part of this spec, and is enforced a few
> times in the document.
>
>
> :Best,
> :R.
> :
>
>
>
>
> --
> The moving cursor writes, and having written, blinks on.
>