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

Maybe stating too much of the obvious, but it should suffice:

   It is not a protocol error to put an invalid ASN into the ASN field.
   For example 0 or 23456 are allowed.  It is up to the receiving BGP
   speaker to recognize (or not) any received large communities.  There
   are no routing semantics implied by the ASN field.  For example, this
   document does not require a receiver of a large community to know
   where the AS identified by the ASN of a large community is.
   The ASN field is simply a convenience that allows different ASes to
   define large communities without clashing with each other.  If an AS
   wants to use invalid ASNs in the ASN field privately within its own
   AS or even by agreement with a neighboring AS, then this document
   does not prohibit it.

To prevent junk communities from spreading throughout the internet,
a BGP speaker SHOULD NOT send a large community with an invalid or
unassigned ASN
unless it knows that the receiving speaker understands its meaning.
A receiving speaker is free to drop any large community, even if
it contains a valid ASN. A BGP speaker is under no obligation to
deliver a route containing a large community to the AS identified
by the ASN in the large community.

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Monday, September 26, 2016 4:32 PM
> To: Brian Dickson <brian.peter.dickson@gmail.com>
> Cc: In-Depth Review <idr@ietf.org>
> Subject: Re: [Idr] WG adoption of draft-heitz-idr-large-community; one week to comment on early code point
> allocation
> 
> 
> > On Sep 26, 2016, at 7:23 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
> >
> > RFC 1997 does not specifically say so, but definitely derives its "special" from the ASN registry "special" for 0
> and 65535.
> 
> Given the practice of encoding an AS number in the first portion of the community, reserving 0 made some amount of
> sense.
> 
> There also tends to be common practice to try to reserve 0 out of things resembling code points to have as the
> "uninitialized value".  I'd recommend that practice continue for pretty much everything, including large comms.
> 
> > 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.
> 
> FWIW, I think things with "well known" semantics should stick to the reserved code point space in 1997 communities
> unless there's some motivation to have a common parameter/argument in it.  In that case, it fits the case for large
> comms anyway.
> 
> -- Jeff
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr