Re: [Idr] WG adoption of draft-heitz-idr-large-community; one week to comment on early code point allocation

[Brian Dickson <[e-mail]>]

On Mon, Sep 26, 2016 at 2:18 PM, Job Snijders <[e-mail]> wrote:

> Hi,
>
> On Mon, Sep 26, 2016 at 12:49:41PM -0700, Brian Dickson wrote:
> > On Sat, Sep 24, 2016 at 2:26 AM, Job Snijders <[e-mail]> wrote:
> > >
> > > 3) Should values in the range "65535:0:0 -
> 65535:4294967295:4294967295" be
> > >    reserved to accomodate any future well known communities? 65535 is
> > >    used in RFC1997 so i see merit in continuing to use that number.
> >
> > IMHO, the first of the 3 32-bit values, should be treated as per the
> > IANA registry for Autonomous System Numbers.
>
> In most of the cases, probably.
>
> > There are several values in both 16-bit and 32-bit ranges with special
> > purposes. Those include documentation purposes, private use, and
> > "reserved".  Currently, I see the relevant values in the table as
> > follows:
> >
> > 0 (Reserved, RFC7607)
> > 23456 (AS_TRANS, RFC6794)
> > 64496-64511 (Documentation and sample code, RFC5398)
> > 64512-65534 (Private use, RFC6996)
> > 65535 (Reserved, RFC7300)
> > 65536-65551 (Doc'n & sample code, RFC5398)
> > 65552-131071 (Reserved)
> > 4200000000-4294967294 (Private use, RFC6996)
> > 4294967295 (Reserved, RFC7300)
> >
> > I'm not sure what the preferred method is these days, either refer to
> > the ARIN table, or to the RFCs directly.  However, the corresponding
> > communities should inherit the properties (Reserved, Documentation and
> > Sample Code, Private Use, and AS_TRANS).
>
> I agree with you that these are special values, but they are a different
> kind of special than the '65535' from RFC 1997.
>
>
RFC 1997 does not specifically say so, but definitely derives its "special"
from the ASN registry "special" for 0 and 65535.

The WKC use of 65535:xxxx is something tracked in an IANA registry.

I suggest a similar registry be set up for (2^32-1):xxxx:yyyy, and I would
hope the other document handles that.

I think parity with 1997 would be the best course of action, and to
include-by-reference 32-bit values that are 16 bits of 0, followed by 16
bits of 1997 values that are reserved, as well as the RFC 7300 32-bit
Reserved ASN.
I.e. 0:xxxx:yyyy, 65535:xxxx:yyyy, and 4294967295:xxxx:yyyy.

I think referencing RFC 5398 is sufficient, and hinting that their usage
(as the first 32-bit value of a Large community) is strongly discouraged
outside of documentation and sample code.

And I think it is sufficient to reference RFC 6996 plus 1997, to point out
the local nature of communities associated with Private Use ASNs.

RFC 6794 currently recommends use of Extended communities; I think the
current document should also Update 6794 to suggest Large as an alternative
or as the recommended alternative.


> I don't see how these values have meaning in a BGP implementation, thus
> are probably out of scope for IDR. I think this will be better covered
> in the "Usage" document we'll submit to GROW in the short term.
>

The ASN values in AS_PATH or AS4_PATH have mandatory restrictions, for both
Private Use and for Reserved, even if the controlling RFCs are not
Standards track.

I do think this RFC will be read by operators as well as implementors, so
documenting the expected usage would not be superfluous, IMHO, even if not
directly relevant to implementations.

Brian