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

Robert Raszuk <robert@raszuk.net> Wed, 19 October 2016 23:28 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 E39DB12984A for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 16:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 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] 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 dc7-UllbktWO for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 16:28:14 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 B72951295A5 for <idr@ietf.org>; Wed, 19 Oct 2016 16:28:13 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id x79so52606921lff.0 for <idr@ietf.org>; Wed, 19 Oct 2016 16:28:13 -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=J0wQU8JFqvBSyXkNK4bEbjjIH56LBJ/4y8ZoUqp3voc=; b=A5EIJVVP3/XV3kjki/tU2ENPBcjmQwaqSWwzOkA5Ri5AwjqVwfyfl+fTBFMnawzGn2 EDWav+Oaa4gs/I+iZela2y2/kdkDvk4xC6USOq9JawphMANCvUaSy3aDS3yxGWCbaZfa T7utmZwl7fu/q3VX59UNf4ukT5o7PdyBXnMetGAxf7mD/9Md/mo7zwx8XuF6otQ1r93Q w2MRRiSWsGzcqhcOudcfMGFzx9Hyyr2zmhdTVA2OWmU+YvwWYjlvwQR2XNyLtYPzmEAS B1bpZk0VEgQyIH+IEpCRomtB39nfSgdv97nssZdwhdzvQq/eiITBqR5PoKuogV6BQ4qC n/CQ==
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=J0wQU8JFqvBSyXkNK4bEbjjIH56LBJ/4y8ZoUqp3voc=; b=aWHwU42kRFiys3EyVNJ394ayyqugZQhbewq1ucCSjIjotllHhE8Y4RyvhH5/ViVCg9 bWCrLwXZoEqkQWdr6l9HcxcDasD3IuBppgC6/TFhTAemc9WVQAxTEdmCStE9RNFPP/aw A6ESX5oQiW6Bqw0xQDKBTu19uYeJJeVGt6Eazye9YmScxUBCgjc+OlLV+22BYbH4bay2 ePjefR9PQU4uk/5cdCy+HTrVEKeLYG7NjPOzEnFhhSBK6uGhidfTbvKccNvlBSSvFwmo uwq1J+NvuUCwOGrKjLyhUH4/BQ6Kkc9vOFT7o5dq7X7IxB+HFzjenD3RrfWME5ZJ1AJ3 LNbg==
X-Gm-Message-State: AA6/9RmVGk0IYuJazDH2Bbj8iZuXk+tMmltYqIkyFJikCwS+frh9KIHckzjoDVlq2WZrE87pUPrnURMG5A3jHA==
X-Received: by 10.28.46.15 with SMTP id u15mr4309883wmu.61.1476919691888; Wed, 19 Oct 2016 16:28:11 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.182.155 with HTTP; Wed, 19 Oct 2016 16:28:10 -0700 (PDT)
In-Reply-To: <CAH1iCirF2C-83z3hYC4bBqMYW7zHs1eeofySVipyODo=8FNQxg@mail.gmail.com>
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> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <CAH1iCirF_1ODLtLzeVhKmQPDeeGcczcQCSPXDcro=OQv2ipR3A@mail.gmail.com> <5807F3AF.9080200@foobar.org> <CA+b+ERn_7Bs8CeAgKrxSPiMPOCsE4pH9hoD+76tEDrWM-KYVRw@mail.gmail.com> <CAH1iCirF2C-83z3hYC4bBqMYW7zHs1eeofySVipyODo=8FNQxg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 20 Oct 2016 01:28:10 +0200
X-Google-Sender-Auth: 1DMrmXwLh9c3p12RurpGUUGjgv8
Message-ID: <CA+b+ER=oyCTF24f1pAQQjA0ogMCtqw0rKWzT7+jcNpL4WjPjHQ@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Content-Type: multipart/alternative; boundary=001a1142532c98d03d053f402915
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9KzvE5lBRTxrGogf9fB0EKr_Oq4>
Cc: IETF IDR WG <idr@ietf.org>
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: Wed, 19 Oct 2016 23:28:16 -0000

Brian,

Regarding BGP OV I meant to use it as a database of valid ASNs - where it
is present.. Nothing to do with actual prefixes in MP_REACH here.

> 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".

Well if my policy says drop junk it can not ALWAYS act as "allow any
value".

Thx,
R.



On Thu, Oct 20, 2016 at 1:21 AM, Brian Dickson <
brian.peter.dickson@gmail.com>; wrote:

>
>
> On Wed, Oct 19, 2016 at 3:36 PM, Robert Raszuk <robert@raszuk.net>; 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
> choices.
>
> 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.
>
> Brian
>