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

[Brian Dickson <[e-mail]>]

On Wed, Oct 12, 2016 at 5:10 PM, Julian Seifert <[e-mail]> wrote:

> Hi,
>
> On 2016 Oct 11 phessler wrote:
> > Putting my own ASN, or the ASN of my peer that I wish to control, will
> > be the main uses; I agree.  But there is a difference between SHOULD and
> > MUST.  Since I MUST allow users to change the value there, I am happy.
>
>
Close, but not quite.

The "MUST" for changing the values, IMHO, is something we all agree on,
myself included, and is directed at implementers.

The distinction is *to whom* the "MUST (be an ASN)" is directed at:
operators.


The "why" of the (global administrator) MUST is as follows:
- The Large community that the operator sets, may not involve the
operator's own ASN, nor any of the operator's peers' ASNs.
-- This is desired, allowable behavior, acknowledged by operators, and in
parity with RFC-1997
- Thus, the implementation CANNOT have enough local information to enforce
the "ASN-ness" of the 32-bit value
-- This is also as desired, acknowledged by operators, and in parity with
RFC-1997
- HOWEVER, it is not acceptable for the operator to use some other 32-bit
value in place of an ASN
-- By definition, any other 32-bit number will collide with the values of
32-bit ASNs (they are integers between 0 and 2^32-1)
-- There are plenty of private-use ASN values (between 4,000,000,000 and
2^32-2) for anyone who wants to do things "between consenting adults"

Private use ASNs are not guaranteed to be unique, so anyone using them need
to protect against collision.

Non-private-use ASNs are guaranteed to be unique, and adopting "MUST" gives
operators exactly what they need to influence those who behave badly, e.g.
out of ignorance.

Enforcement of this ASN-ness is something that needs to be exclusively
 handled in meat-space.

I don't think anyone (from an operator background) has any issues with
anything outside of "large" (in idr) doing smarter/better things.

Please let us have large, with this "MUST", without interfering in this
consensus, particularly from the operator community.

>
> The semantics of the value configured in the community is up to the
> operator and must not be
> enforced/assumed by the implementation. It makes sense to reserve certain
> values/prohibit their
> use to prevent compatibility issues, keep special values for
> tests/documentation/checking and for well known communities
> that might be defined later on, but don't force operators to only be
> allowed to configure iana assigned
> ASN values or force implementations to only allow configuration of  an ASN
> in the GA that is a configured ASN on
> the specific router etc.
>
> Communities are great because of the ambiguity(sorry of not the correct
> term for what I want to  express)
> The vast number of values I can configure with meaning only for me and
> parties I interact with)
> being too strict will greatly diminish the value they represent as a tool
> in operating networks.
> And would be contradictory to the operational need from which the draft
> arose.
>
>
Agreed (modulo "SHOULD vs MUST" language).

Maybe putting a prefacing statement to clarify the Global Administrator
definition, so that the restriction is guidance for operators, not
implementors, would get us to consensus?

Brian