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

heasley <heas@shrubbery.net> Fri, 21 October 2016 16:02 UTC

Return-Path: <heas@shrubbery.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59060129636 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 09:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.632
X-Spam-Level:
X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWs-N4uqxBXO for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 09:02:12 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCC8129648 for <idr@ietf.org>; Fri, 21 Oct 2016 09:02:11 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 8502758FFB; Fri, 21 Oct 2016 16:02:11 +0000 (UTC)
Date: Fri, 21 Oct 2016 16:02:11 +0000
From: heasley <heas@shrubbery.net>
To: Robert Raszuk <robert@raszuk.net>
Message-ID: <20161021160211.GH7773@shrubbery.net>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <adb00bcd7b8e45db857eae7019c646fc@XCH-ALN-014.cisco.com> <ae5da282-201c-f745-9f26-67ce73826bd5@i3d.net> <CA+b+ERkV2PBtzzx=uoygDzvTyJzunROCNX=0Y4phvGdn=oK5Xw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+b+ERkV2PBtzzx=uoygDzvTyJzunROCNX=0Y4phvGdn=oK5Xw@mail.gmail.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/eUCLS1eOe7iT1yhIWbsFrYn050o>
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)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2016 16:02:17 -0000

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