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

Robert Raszuk <robert@raszuk.net> Fri, 21 October 2016 15:42 UTC

Return-Path: <rraszuk@gmail.com>
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 D10511295C9 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 08:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Wrlrbax5qtkK for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 08:42:41 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AD71293E9 for <idr@ietf.org>; Fri, 21 Oct 2016 08:42:40 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id m138so171798776itm.0 for <idr@ietf.org>; Fri, 21 Oct 2016 08:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wcAChagqJXpgxbdUXF50BkGDSaTOsxH/nAotkBehHsE=; b=mbZ04XLmMGsCyAgD+egiMVv2gDNW+5CO5VEtghdUi5ekYazzoy52NkYe4nOlF317y2 nx5SnML9676py6UQ93slIBB3QOEC2W57HbY1Q5nSsX1NmnKlAuWYn4Ff+ZoxZm22GLRM h08WJEQL6f7WTNHJB56SPLMz4yMkFFn92anyK8hcMtw/xUtfcQ9webRgrhpoq6Tjkau0 mNIchbpGcVsrZqWaY1mXfCAv3mioOcjov45YS/VpIGKGIMG13t+bRNFbJGRdlXl7qfZG 8ppFnr02HuJvm0GOO/I2FWz2UrN2lSqBzrPtG5Ne2Re83uqtwp/NDLfbyUeWsk0DdS4d LFzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wcAChagqJXpgxbdUXF50BkGDSaTOsxH/nAotkBehHsE=; b=LqJ8WyQQaDqryWTYNdp/FwXkfJc1WxdZ3chcUVRrHYvsA/pi0Ni5Bmb1QcDTS+0jmV zFcsyt8iMFqUqKnBG6GASUTMCtN+Fln+4gvrC87yN/hG4QWR6y1/e7tiv5LaYIzqrDAP tEq5W7goSYPUjat4Wk2e2Wq2BP9Xu089gEGMDrCKumcbt4jl5kYO2PkujnpBpEQLLBnC EEbsw1zvYtxiNL+xi6n0IVIOho1YPnp6g+wuQIRiiZOmP/LWLaIS7umqw5jkoLM1PTwa cCaRJw4nxWlM0nd4FVPS+L+glLJkDcDO8S620KBuWtv3ZTKOFQrLK36AaFk+KC/2hNwJ dV7A==
X-Gm-Message-State: ABUngvf/8KBCIaYwviuBIosv2T6s7ppdU6lsQ/yVVzdETMA7ZPZIeRV8sVkgj0xSaRN+pZAbbiQK51DxnPQWVQ==
X-Received: by 10.36.254.65 with SMTP id w62mr1688445ith.118.1477064558739; Fri, 21 Oct 2016 08:42:38 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.107.17.232 with HTTP; Fri, 21 Oct 2016 08:42:37 -0700 (PDT)
In-Reply-To: <ae5da282-201c-f745-9f26-67ce73826bd5@i3d.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>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 21 Oct 2016 17:42:37 +0200
X-Google-Sender-Auth: 96mpSZVNAaMUBjW4yy_uEBfSARk
Message-ID: <CA+b+ERkV2PBtzzx=uoygDzvTyJzunROCNX=0Y4phvGdn=oK5Xw@mail.gmail.com>
To: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Content-Type: multipart/alternative; boundary=94eb2c031b985588e7053f61e4cb
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/yq0wFzQ4KNyxr0qNak1nfodXny8>
Cc: IETF IDR WG <idr@ietf.org>, heasley <heas@shrubbery.net>, 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 15:42:44 -0000

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 ?

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.

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
>