IETF Logo Mail Archive

Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)

Keyur Patel <keyur@arrcus.com> Sat, 04 March 2017 05:18 UTC

Return-Path: <keyur@arrcus.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D97129437; Fri, 3 Mar 2017 21:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 h4vwikF5J66n; Fri, 3 Mar 2017 21:18:33 -0800 (PST)
Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 E6609127A90; Fri, 3 Mar 2017 21:18:32 -0800 (PST)
Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 645B660061; Sat, 4 Mar 2017 05:18:30 +0000 (UTC)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from mx7-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id BF1DD6004B; Sat, 4 Mar 2017 05:18:29 +0000 (UTC)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0113.outbound.protection.outlook.com [207.46.163.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx7-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 70004540075; Sat, 4 Mar 2017 05:18:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G+PrgPlZdPH5iLnjAUEjbbzowliFZNTT8EMqFQ7Gxuo=; b=loIYSMzrAeXLtI32ZncPbcO103nbXBOC2PNCWhJP+UzOtev56WSmMXJB9oAkXZfu/Qk/FSnmx9FMNYqJ84ZlHD6AQWPaDhoHtfqeFNBEzi2oO7x8aAyUcV103VWWMYRRGDRQoXP+hHQcZzUSdWwcNovjzbdZTlDABvCdrXRKA5o=
Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0261.namprd18.prod.outlook.com (10.163.72.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Sat, 4 Mar 2017 05:18:17 +0000
Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0933.020; Sat, 4 Mar 2017 05:18:16 +0000
From: Keyur Patel <keyur@arrcus.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)
Thread-Index: AQHSbB7tzlS1UVmWk0KSI6cn7Yzvt6F3XtWAgAAICACADGubgIAATY4AgAA/IwCAAAGigIAABpcAgAACC4CAAABngIAAALWAgAAKrlM=
Date: Sat, 04 Mar 2017 05:18:16 +0000
Message-ID: <316227B7-8EB3-43C4-A164-926DDCDBA8FD@arrcus.com>
References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> <AF3156BF-6CC9-4DDF-8C7A-4D6EDB9668AB@cisco.com> <D4DF2B46.74CF0%dougm@nist.gov> <m27f45x5jx.wl-randy@psg.com> <yj9oo9xhr8tj.wl%morrowc@ops-netman.net> <m2tw79vg94.wl-randy@psg.com> <4f0301f24b794a5c8ea0ab9e86f97eb0@XCH-ALN-014.cisco.com> <m2pohxvetm.wl-randy@psg.com> <yj9olgslr71w.wl%morrowc@ops-netman.net>, <b0af2bd3b7424c9fa0e41c7e5776beab@XCH-ALN-014.cisco.com>
In-Reply-To: <b0af2bd3b7424c9fa0e41c7e5776beab@XCH-ALN-014.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=arrcus.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2601:646:8980:4f18:8544:29f6:59d6:4e22]
x-ms-office365-filtering-correlation-id: 164b991b-f9a2-47cc-70d9-08d462bddd69
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0261;
x-microsoft-exchange-diagnostics: 1; BY2PR18MB0261; 7:3mCnApb5dKfzuggIp2y/0cfA4d4l8JWFXtKh0P3Ay0uVA9aBmO3JAuidw1HlrD0EDp2fQY6wcVIRAYk3KPsYqKStAIUnSDSMKTC3Zjc2UEuEjuaaKrJnFUV3nDXsczbMt3bpyaG64vJlM2P04BS8CuiAhBX/rXtCS8rO9JI3TYkiqjfbvlry9np+MVK1B8c1IIyDBU+rOm9dmtiuDnU132ZWnmN54kntNi3/QpHScEcAq3Es96LvSGN7o/gxYqCewXq32m/PcySpQ/9OfKua5kkPRFMUYvABmxoLafy6+fSrjvHR72+QrHMS0X/DM4HYx+dBBBgD2JqWODL98dQrgw==
x-microsoft-antispam-prvs: <BY2PR18MB0261A47B0BA7F5D5055EC131C12A0@BY2PR18MB0261.namprd18.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(2016111802025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6042181)(6043046); SRVR:BY2PR18MB0261; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0261;
x-forefront-prvs: 0236114672
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(24454002)(377454003)(93886004)(36756003)(2906002)(8656002)(5003630100001)(230783001)(50986999)(3280700002)(86362001)(76176999)(189998001)(3660700001)(54906002)(99286003)(54356999)(7736002)(6506006)(6436002)(4326008)(25786008)(305945005)(6512007)(6116002)(102836003)(106116001)(77096006)(229853002)(5660300001)(110136004)(33656002)(6916009)(38730400002)(53546006)(8936002)(2900100001)(92566002)(8676002)(122556002)(6246003)(2950100002)(81166006)(6486002)(53936002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0261; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2017 05:18:16.6910 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0261
X-MDID: 1488604710-rvNaIPXJje8G
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/6zNV1UTOaQvvlzgvqamHRTX-4rI>
Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" <draft-ietf-sidr-origin-validation-signaling@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sandy@tislabs.com" <sandy@tislabs.com>
Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Mar 2017 05:18:36 -0000

Jacob,

Ebgp Peers are out of scope. Imho, implementations are free to implement receipt and processing of a community from a ebgp peer as a knob. The standard doesn't have to accommodate knobs.

Regards,
Keyur

Sent from my iPhone

> On Mar 3, 2017, at 8:40 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
>   However it SHOULD be possible to
>   configure an implementation to send or accept the community when
>   warranted.  An example of a case where the community would reasonably
>   be received from, or sent to, an EBGP peer is when two adjacent ASes
>   are under control of the same administration.  A second example is
>   documented in [I-D.ietf-sidr-route-server-rpki-light].
> 
> Thanks,
> Jakob.
> 
>> -----Original Message-----
>> From: Chris Morrow [mailto:morrowc@ops-netman.net]
>> Sent: Friday, March 03, 2017 8:38 PM
>> To: Randy Bush <randy@psg.com>
>> Cc: Jakob Heitz (jheitz) <jheitz@cisco.com>; Chris Morrow <morrowc@ops-netman.net>; Montgomery, Douglas (Fed)
>> <dougm@nist.gov>; Alvaro Retana (aretana) <aretana@cisco.com>; draft-ietf-sidr-origin-validation-signaling@ietf.org;
>> sandy@tislabs.com; sidr-chairs@ietf.org; sidr@ietf.org
>> Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard
>> (draft-ietf-sidr-origin-validation-signaling-11.txt)
>> 
>> At Sat, 04 Mar 2017 13:36:05 +0900,
>> Randy Bush <randy@psg.com> wrote:
>>> 
>>>> The ext-comm may come from an ebgp neighbor.
>> 
>> ebgp neighbor? the text talks about ibgp, and about explicitly ignoring ebgp senders of this community (by default).
>> 
>> right?
>> 
>>> 
>>> ok.  saves a character.  my kind of change :)
>>> 
>>>  "Similarly, a receiving BGP speaker, in the absence of validation
>>>   state set based on local data, SHOULD derive a validations state from
>>>   the last octet of the extended community, if present."
>>> 
>>> randy

v2.23.0 | Report a Bug | By Email