Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

Let's say I am AS49544 and I need to transmit a prepend instruction to
AS2914, I would add 2914:3320:2 or 2914:2:3320 or similar on my prefix.
Why is it important to allow me to specify any value in the Global
Administrator field? Well,

1) If we did REQUIRE people to use their own ASN when adding a new
community on a prefix, we'd essentially be back to the same amount of
opaque space as in RFC1997 (e.g. two fields, not three). This also
brings back the collision problem which we were trying to tackle, both
AS2914 and AS3356 might decide to act on a community tag like 49544:2:3320.

2) The actor ASN already knows who could have set the community tag
thanks to the AS_PATH, using a field in the large community tag to make
it aware of that might be considered as redundant information.

3) Using the first field to specify the ASN which needs to take the
action makes it quite easy for an operator to ignore any large community
tags which are intended to signal something to a 3rd party. This allows
for transitive instructions in cases where one doesn't have a direct
adjacency with the target ASN; quite useful for downstream customers of
a tier-2 network which are trying to trigger an action in that network's
upstream provider.

Informational communities are another matter - that's where an operator
SHOULD use their own ASN in the Global Administrator field. However
there is no (technical) difference between an informational and an
action community - just semantics - so we can't really specify such
restrictions in the draft.

Best regards,
Martijn

On 10/08/2016 06:35 PM, Nick Hilliard wrote:
> Brian Dickson wrote:
>> Is there anything you envision in use of large communities that
>> cannot be supported by use of ASNs and private ASNs? I can't see
>> anything that would not fit into those two use cases.
> There are plenty of situations where the semantics of what you're
> suggesting would be troublesome to define, for example, confederations,
> asn translation or asn migration, leading to cases where there would be
> multiple asns being legitimate on a single router.
>
> And even if these cases could be cleared up easily, what happens when
> someone injects a prefix tagged with a community which isn't the same as
> their ASN?  You're then stuck with the situation where you're defining
> one thing as a MUST in the semantic specification section of the rfc,
> while down in the Security Considerations section, it's going to need to
> be admitted that there's no guarantee whatsoever that the global
> administrator field in the large community was actually set by the ASN
> which announced the prefix.  Worse still, once it's been changed, there
> is no practical way for a neighbor to detect this change, as s-bgp isn't
> a thing.
>
> Realistically, vendors are going to implement ways of modifying the
> field in exactly the same way as rfc1997 communities can be set to
> anything at all at any policy specification point in a bgp-enabled network.
>
> Nick
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr