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

Brian Dickson <> Wed, 19 October 2016 23:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76AE3129520 for <>; Wed, 19 Oct 2016 16:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BEIrNrxfuQtl for <>; Wed, 19 Oct 2016 16:21:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D93CA129510 for <>; Wed, 19 Oct 2016 16:21:38 -0700 (PDT)
Received: by with SMTP id l131so46528722lfl.2 for <>; Wed, 19 Oct 2016 16:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PjlUwdg4idaz38BMHd7MuWC5eP8HiwuoGa9Nb6CKxPg=; b=mGd13Q653OxhuN0fs7o7SyPqdY/bkowtTSPtabgilj1vQt2wGd5icnBWFqoc/a8r2/ C+AiQMtB2zmzEqCoJGz2QEvKkvq94/TXLLDnYR6Q/jfhSKNQI6poQ4INtdCv1XuJJpqQ sggoQ3nveA7DqIDyCLL0hTe78mZgBKUX9qnSz7JDVflbDBpWL2zWaLZ2C7AlWb1DXjWG 37fQMtCiSWReY32FxSm70G+huL/YT0WGp5+16Rzg9vLeHsYilYiVQ3eMCWvS1hCRPjSu CxYFW5VBnoAoVs+LhCovoL4neCTg9mALUYL+g52xKuBkVXrgi0TpeiGTho5TjEHk6AtR aQAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PjlUwdg4idaz38BMHd7MuWC5eP8HiwuoGa9Nb6CKxPg=; b=CDqY2OuUmQemcetw5vACGOL0YYznfgc705MUixjVTvOq7essd4UUx9+VDxvl3VyMJy xGjSUs5vUhy6HhlZbs1leKJO1V2Th19a2Ag748M+cLEqf43IbishL5Q7/d4+ioVzO0nQ uBW4KH1cZEt8p8kTse5hv5TI4NF1yzb165ZHBLHNzvMbN8hLKP5q1j0XnTCs5y50kpCT lypctdCN1ATMAhwfMqZlJDlkhIGyd4K5QpA4wTD/918xsQskE5eclevWALTF7/vcJZMn ySFqgr5rd+gaDCVemMkAC+Z9wrM9+tLJZ2qfHEGEv5S/PyWJtYnMVK6PzRt1oP7HDEGA GWYw==
X-Gm-Message-State: AA6/9RmYVL3Zuj0FHc6aHfowy2eYEgRO7SDrYr9wqw+ULvpxd7UJHmzj52IWzjIIMjwTZ74arhnFCDZjMBLVTA==
X-Received: by with SMTP id 16mr7153360wme.39.1476919296641; Wed, 19 Oct 2016 16:21:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Oct 2016 16:21:35 -0700 (PDT)
In-Reply-To: <>
References: <01f301d228b4$e3319ef0$a994dcd0$> <> <> <20161018191521.GT95811@Vurt.local> <> <007201d229f6$b4ae9680$> <> <> <> <>
From: Brian Dickson <>
Date: Wed, 19 Oct 2016 16:21:35 -0700
Message-ID: <>
To: Robert Raszuk <>
Content-Type: multipart/alternative; boundary="001a1141f0bc09cfe6053f40122a"
Archived-At: <>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Oct 2016 23:21:42 -0000

On Wed, Oct 19, 2016 at 3:36 PM, Robert Raszuk <> wrote:

> so summarising:
>> - operators: you MUST use an ASN
>> - implementers: you MUST allow any value
> ​IMHO this is too coarse simplification.
> For operators if we are getting into this here vs in companion GROW doc
> draft/rfc must define what sending vs receiving operator is expected to do.
> ​For implementation allowing any value unless policy is in place. And as
> such policy must be able to validate against BGP Origin Validation database
> if present and enabled on the router.

You've lost me here. If I am sending prefix X, and I am ASN A, and the
community is B:C:V, the BGP OV will show A is allowed to originate X. There
are no other restrictions applicable from OV.
Also, the meaning of B:C:V is exclusively defined by ASN B, who may or may
not be a directly connected peer.

Nobody except B is expected to "do" anything.
What B does, is a combination of:
- What B tells the world
- What B tells some subset of the world (e.g. via a customer portal which
has restricted access)
- What B uses to decide for whom each set of actions is permitted
- Any internal policies and procedures known only to B

E.g. B may allow B:C:V from customers of B (including customers of
customers, etc.)
E.g. B may allow B:D:V from anyone for some set of values V and some
specific values of "D"
E.g. B may allow arbitrary automated functionality associated with
B:*:{V1,V2,V3,... VN}, where the second parameter is a BGP peer of B, and
VN is a trigger for some particular behavior (filter, prepend, change MED)

Every ASN "B" can choose whatever it wants as the methods, mechanisms,
values, etc., and those do not need to have any bearing on any other ASN's

Some ASNs will choose not to use their own ASN:X:Y, but rather use
PRIVATE_ASN:X:Y and only do those on a per-peer basis (with distinct
choices of PRIVATE_ASN, X, and Y, which can literally vary by peer, with no
global meaning.)

So, I think the "unless policy is in place" is a red herring; whether
policy is there or not, and regardless of what policy there is, it is
ALWAYS "allow any value".

> Again .. I assume we are all talking about first 4 octets only right ? Or
> also second 4 octets too ?
First 4 octets only.