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

Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk:
> Hi Martijn,
> 
> > Secondly, there's literally no way for the vendor to check whether an
> > ASN belongs to "the entity that defines the meaning of the rest of the
> > Large Community"
> 
> Why not ?

Because to determine if the contents is really something defined by the
GA in the community, the device would need a list of communities that the
GA uses, that list would need a signature and all the infrastructure to
verify that signature....and ultimately, what would the point be anyway?

> If you do not make those 4 octets configurable by spec and always fill it
> with AS number defined in your BGP instance you will have assurance it
> is ASN of the entity that defines the rest 8 octets of the LC as otherwise
> you will likely not establish any EBGP sessions to your peers.

BECAUSE IT IS NOT A ONE-WAY OR ONLY ONE-HOP THING.  THE AUTONOMOUS SYSTEM
ITSELF MIGHT SET THE COMMUNITY AS A TAG OR ANOTHER AUTONOMOUS SYSTEM MIGHT
SET IT TO SIGNAL ANOTHER AUTONOMOUS SYSTEM TO DO SOMETHING AND THAT
AUTONOMOUS SYSTEM MAY BE 1 OR MORE AUTONOMOUS SYSTEM HOPS AWAY.  Eg:

	2914:1001 	Ashburn, VA | set by ntt
	2914:450 	96 	customer fallback | received from a customer

a customer might use 2914:450, or a customer of a customer, or a customer
of a customer of a customer ....

Utimately, the so-called Global Administrator field has the same storage
size as an 4-octet ASN, operators will likely use it as such, but as far
as the protocol, it need not be.  It can be any 4-octet value as far as
the protocol is concerned.  Just as BGP RID is 4-octets and is just a
number as far as the protocol is concerned, but operators typically use
an IP address on the device as the RID.

> So there is very easy way to enforce it today in any BGP implementation.
> 
> However the question is should it be enforced at all ?
> 
> Best,
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Fri, Oct 21, 2016 at 5:19 PM, i3D.net - Martijn Schmidt <
> martijnschmidt@i3d.net> wrote:
> 
> > Hello Jakob,
> >
> > I think we need to ask ourselves whether the new wording is really
> > relevant to implementors. The answer here appears to be that it's not,
> > because the draft states "Implementations MUST allow the operator to
> > specify any value for the Global Administrator field." and no amount of
> > SHOULD will override the MUST.
> >
> > Secondly, there's literally no way for the vendor to check whether an
> > ASN belongs to "the entity that defines the meaning of the rest of the
> > Large Community" so it's completely unenforceable and therefore doesn't
> > belong in a protocol specification / IDR draft.
> >
> > If we want to instruct operators to do something, it SHOULD be done in a
> > RFC1998-like BCP/GROW document and I'd be happy to contribute some
> > wording which seeks to make that happen when the draft is submitted to
> > GROW for adoption as a WG subject.
> >
> > Best regards,
> > Martijn Schmidt
> >
> > On 10/21/2016 12:13 AM, Jakob Heitz (jheitz) wrote:
> > > 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
> > > _______________________________________________
> > > Idr mailing list
> > > Idr@ietf.org
> > > https://www.ietf.org/mailman/listinfo/idr
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >

> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr