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

In addition, to deal with the values for the GA field, we will replace

   The Global Administrator field is intended to allow different
   Autonomous Systems to define Large BGP Communities without collision.

with

  A Large Community that
  is intended to be sent to multiple ASes SHOULD contain an ASN
  in the Global Administrator field. The ASN SHOULD be one that
  is assigned to the entity
  that defines the meaning of the rest of the Large Community.
  This allows a route to carry multiple Large Communities, the meaning
  of each being defined by different independent entities.

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders
> Sent: Thursday, October 20, 2016 3:00 PM
> To: Jeffrey Haas <jhaas@pfrc.org>
> Cc: heasley <heas@shrubbery.net>; IETF IDR WG <idr@ietf.org>; Sue Hares <shares@ndzh.com>
> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
> 
> Hi working group,
> 
> On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote:
> >
> > > On Oct 18, 2016, at 3:15 PM, Job Snijders <job@ntt.net> wrote:
> > >
> > >>
> > >> Part of the idea behind reserving 65535:*:* was to reserve a space that
> > >> could later be used for well-knowns, if that was desired - but to not
> > >> spend time now arguing about details of what well-knowns are necessary.
> > >>
> > >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs.
> > >
> > > Jeff argues that a justification should be added. Maybe someone can
> > > pitch in one or two sentences that explain why these are reserved?
> >
> > That's certainly part of it.  While I think many people can see the
> > reason why you might want to do such a reservation, to do so you
> > should have a practical reason in the document.
> >
> > For the 65535:*:* case, for symmetry with RFC 1997, you'd probably
> > want to note that if it's used for that symmetry that either the
> > existing well known community registry is used at IANA or that a new
> > one would need to be created.  Alternatively, you just say the work is
> > expected and defer to a future document.
> >
> > Note by doing this, you're setting up some expectations about
> > translation of communities from one space to another.  FWIW, I don't
> > recommend this and simply suggest that you recommend *not* using these
> > for common use in case someone decides that they want to do so.  I
> > know your organization and others such as Deutsche Telecom have some
> > thoughts about what translation infrastructure might look like, and
> > such mechanisms would have impact.
> >
> > With regard to the 0: and max-uint32: cases, after dealing with the
> > headaches associated with helping with documents such as the as0 and
> > RFC 7300 and putting in some restrictions in the configuration...
> > followed by having to take them away, I'm very reluctant to put in
> > anything beyond "we think it's a bad idea to use these, so pretty
> > please don't"
> 
> After some off-list back and forth with John Heasley, Adam Chappell,
> Jeff Haas and the authors, we came up with the following text to address
> the above raised concern.
> 
> This will be part of -04.
> 
> """"
> 5.  Reserved Large BGP Community values
> 
>    The following Global Administrator values are reserved: 0 (the first
>    ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN)
>    [RFC7300].  Operators SHOULD NOT use these Global Administrator
>    values.
> 
>    Although this document does not define any Special-Use Large BGP
>    Communities, the Global Administrator values specified above could be
>    used if there is a future need for them.
> """
> 
> A preview of the -03 / -04 diff is available here:
> 
> https://htmlpreview.github.io/?https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-
> ietf-idr-large-community-04-from-3.diff.html
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr