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

[Brian Dickson <[e-mail]>]

Sent from my iPhone

> On Oct 8, 2016, at 9:35 AM, Nick Hilliard <[e-mail]> 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.
> 

The operator setting the community would need to know the intended semantics. The other operator would need to establish what acceptable communities could be used and the corresponding semantics.

The operator doing anything complicated will already need to understand the ASN gymnastics; the corresponding communities follow those same gymnastics.

> 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?  

I said ASN. I didn't say THEIR ASN.

That is the apparent disconnect.

Nothing should enforce what ASN value is used.

> 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.

Correct. That is the intended behavior.

The ASN value will rarely be the ASN setting the community. The cases where the sender uses its own ASN can already be handled with extended communities.

>  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.

Yes, and this is the desired state of affairs. Complete parity with 1997.

Brian