Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

heasley <heas@shrubbery.net> Mon, 16 April 2018 23:29 UTC

Return-Path: <heas@shrubbery.net>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1597412D779; Mon, 16 Apr 2018 16:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 3FrMpyqyyeP4; Mon, 16 Apr 2018 16:29:31 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ECD1271DF; Mon, 16 Apr 2018 16:29:31 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id C546A3AC35; Mon, 16 Apr 2018 23:29:30 +0000 (UTC)
Date: Mon, 16 Apr 2018 23:29:30 +0000
From: heasley <heas@shrubbery.net>
To: "Joel M. Halpern" <joel@stevecrocker.com>
Cc: heasley <heas@shrubbery.net>, li zhenqiang <li_zhenqiang@hotmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" <draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, opsawg <opsawg@ietf.org>
Message-ID: <20180416232930.GB47095@shrubbery.net>
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com> <HKXPR0601MB1799868866AF89F9699EAF28FCB10@HKXPR0601MB1799.apcprd06.prod.outlook.com> <20180415160956.GC66082@shrubbery.net> <ace47a71-0e9d-6a0d-ae37-1f4bc48ada0b@stevecrocker.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ace47a71-0e9d-6a0d-ae37-1f4bc48ada0b@stevecrocker.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.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/nuyuKOpuLIEJp32YXVN2FbxmPeo>
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2018 23:29:33 -0000

Sun, Apr 15, 2018 at 12:32:49PM -0400, Joel M. Halpern:
> (the authors would not have written it if no one wanted it.)

eh, that might not be a valid argument :)

> Also, one of the arguments for doing this in the router is that you can 
> get more timely and precise correlation.  Except that for geolocation of 
> address blocks, upstream correlation seems to be quite sufficiently 
> stable and precise.  NLRI may come and go.  I fone has geo-information, 
> it is unlikely to change.

This may have been answered, but in case not or un-clear; what I and I
believe others refer to here as geo location, is different from what you
and randy are talking about in the sense of the IETF's prefixes.  I do not
always care about that location.

I am placing my own marks on routes - where I hear them; region, country,
metro, relationship with the neighbor, etc.  Though it is not the whole
story, this is typically of more interest to me.

If a neighbor AS does similarly and sends them to me, I could make use of
them.  However, as you observed, these are all choices local to the AS -
the values, whether to send them, etc.  There is definitely a maintenance
cost associate with using this data and a question of accuracy.

Other's comments about accuracy and burden of external enrichment are valid.
Whether this particular additional resolution is much of a burden on routers,
I suspect not, but I am not an implementer.

Authors: please use a spell checker.  Also seems a few of the reference
links are broken.