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

[Brian Dickson <[e-mail]>]

Sent from my iPhone

> On Oct 7, 2016, at 4:48 AM, Nick Hilliard <[e-mail]> wrote:
> 
> Tom,
> 
> t.petch wrote:
>> Here, I would go for 'MUST be an ASN' (or else the community should not
>> be transitive:-)
> 
> Every 32 bit number is an ASN, so there's an argument to say that this
> is a tautology.

Let us leave the straw man alone, please. :-)

> 
> I don't think it's either viable or necessary to narrow down the text to
> specify that the global administrator field MUST be the ASN of the
> operator who assigns the community to the prefix.
> 
> The reason for this is that if large communities are used for inter-as
> signaling, operators should only act at the edge router when the global
> administrator field matches the peer-as, and if they need to interpret
> the community tag further inside the network, they should use a
> translation layer to map the semantics to a locally significant
> community (i.e. the same as what we do for rfc1997 communities).

No.

You are making the erroneous assertion that the way you think these communities should be used, is the only correct way or the only common way they should be (or will be) used.

For 1997 communities (both the year as well as the RFC), inter-as was not limited to adjacent ASNs.

This is why large needs to be transitive as well as globally unique for the global administrator - i.e. ASN.

>  For
> intra-as signaling, it doesn't matter because it's local semantics only.
> Either way, there is no compelling reason that this should be a MUST
> and good reasons (e.g. operator discretion) that it shouldn't.

Local semantics are fully supported by use of (agreed upon) private ASNs.

Those are also consistent with the strong assertion of MUST, as well as both the letter and intent of what is meant by ASN.

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.

Brian