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

[Brian Dickson <[e-mail]>]

On Wed, Oct 19, 2016 at 11:54 AM, Jared Mauch <[e-mail]> wrote:

> On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote:
> > I remain unhappy with this I-D.
> >
> > I find it ironic that the messages for this Last Call should be
> > interspersed with those relating to what goes wrong when someone
> > somewhere else in the world uses a field in an unexpected way.  This
> > reinforces my belief that this I-D should be more forceful in calling
> > out the dangers (eg MUST instead of SHOULD).
> >
> > I think that this I-D is factually incorrect, or at least open to
> > misinterpretation,  when it says
> > '[RFC1997] BGP Communities attributes are four-octet values split into
> >    two two-octet words.  The most significant word is usually
> >    interpreted as an Autonomous System Number (ASN) '
>
>         rfc1998: section 4 gives you the slice + dice bits:
>
> -- snip -- rfc 1998 --
>    To make use of the BGP community attribute, several community values
>    (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used
>    by customers to tag routes so that the appropriate "LOCAL_PREF"
>    values are configured. Table 2 lists the appropriate community
>    attribute values (and the mappings of community to LOCAL_PREF):
> -- snip -- rfc 1998 --
>
>         This is the segmenting, and most customers have
> "ip bgp community new-format" configured.
>
>         If your issue is about printf %ull vs %d:%d:%d we operators
> can solve this by ensuring our vendors do the right thing, which
> we have already done 20 years ago via rfc1998.
>
>         This nit is imo not worth picking.
>
>
I think Tom was concerned about the usage of "usually", not the 16:16
format. I agree, and I am also concerned.

Per Susan Hare's WGLC instructions, here are my specific concerns, and
suggested text for correcting those concerns:

Concern #1:

>From my reading of RFC1997, and from a couple of decades of operational
experience,
I believe the wording in Section 1 should be as follows:

"The most significant word is always an ASN. Private ASN values MAY be used
when agreed upon by adjacent BGP peers."
(Insert reference to IANA private 32-bit ASN table.)

Rationale:

The second sentence was not explicitly part of RFC1997, but definitely has
been operational practice, and is implied by the meaning of ASN, and tables
of 16-bit ASN values (reserved, private, and available/assigned.)

Concern #2:

And, IMNSHO, the request/demand for parity with RFC1997, calls for similar
language when describing the 32-bit first field's interpretation:

In Section 2:

"Global Administrator:  A four-octet namespace identifier.  This MUST be an
Autonomous System Number. Private ASN values MAY be used when agreed upon
by adjacent BGP peers. Private ASN values SHOULD NOT be advertised to peers
where their use has not been agreed upon."

Rationale:

Trying to separate out the "best practice" into a separate,
non-Standards-Track document, significantly weakens the practical ability
BY OPERATORS to enforce the requirement of exclusive control of the
meanings assigned by them, of the number space within communities (regular
and wide).

The draft, as currently worded, gives third parties "wiggle room" to use
non-ASN values as the first 32-bit field. Their argument will be that this
document does not say "MUST", and for whatever choice of argument they
pick, they are justified in squatting on someone's ASN as the first 32-bit
value.

Since Section 1 of this document give exclusive semantic control of that
portion of the Large Community space -- " a four-octet ASN and two
four-octet operator-defined values, each of which can be used to denote
properties or actions significant to that ASN." -- squatting needs to be
explicitly prohibited via use of "MUST" instead of "SHOULD" in specifying
Global Administrator as meaning, exclusively, ASN.

Concern #3:

In addition, to address concerns the co-authors have expressed, the
non-intent of "MUST", to implementers, should be explicitly called out. The
proposed wording would be:
"The Global Administrator field is intended to allow different
   Autonomous Systems to define Large BGP Communities without collision.
   Implementations MUST allow the operator to specify any value for the
   Global Administrator field. Implementors MUST NOT restrict permitted
values
   of ASN, including non-reserved 16-bit ASN values and non-reserved 32-bit
ASN
   values, which includes all Private Use ASN ranges. Use of third-party
ASN values
   is an explicitly permitted use of Large Communities."

Rationale: Avoid any ambiguity for implementation of Large Communities.
Interoperation demands compatible interpretation of values of ASN permitted
by implementors.

Of course, if the above changes are adopted, I approve publication,
whole-heartedly.

Brian Dickson