Re: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-08.txt

"John G. Scudder" <jgs@juniper.net> Mon, 14 December 2015 17:10 UTC

Return-Path: <jgs@juniper.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0203F1ACD86; Mon, 14 Dec 2015 09:10:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 If7eqhTkxtTN; Mon, 14 Dec 2015 09:10:14 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:735]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C121ACDA7; Mon, 14 Dec 2015 09:10:01 -0800 (PST)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net;
Received: from [172.29.35.202] (66.129.241.13) by DM2PR05MB462.namprd05.prod.outlook.com (10.141.105.11) with Microsoft SMTP Server (TLS) id 15.1.337.19; Mon, 14 Dec 2015 17:09:39 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <20151214170534.11198.66446.idtracker@ietfa.amsl.com>
Date: Mon, 14 Dec 2015 12:09:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <CC4BE1A0-479E-44C5-87E5-0BD2A5501BF8@juniper.net>
References: <20151214170534.11198.66446.idtracker@ietfa.amsl.com>
To: "sidr@ietf.org list" <sidr@ietf.org>, idr wg <idr@ietf.org>
X-Mailer: Apple Mail (2.2104)
X-Originating-IP: [66.129.241.13]
X-ClientProxiedBy: BY2PR08CA039.namprd08.prod.outlook.com (10.141.248.157) To DM2PR05MB462.namprd05.prod.outlook.com (10.141.105.11)
X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB462; 2:20KoHaua4bDk5hLsf301C1YnMqs4U4G/cdiwO3nb24CH5FDMQh/S7bADYNTQ4kQ/IIp+J6FBfAcg17YhAAepMjgHGKQAeJbfwXKY+wlUpV3BTgYNj5cuq5ENlzomeiJDcMkQZtHWJwWmlWVrXZEgFQ==; 3:y8YAGeLzXsccbTAGKI8qwecZsrapm1HqDmT71Jn7lW3b2d188DPOPTT/GDpnI9E4hFYkWSmL/kU9pYOyR1K1L/j1Da0nWv+aSGxKd/PYVSoFa3SIMwsDkSQdzZ86ZSKu; 25:vEAT/0HMaJZHjT8vvSb4cEjU5LkGYHH/96HUzqUyLBEYZaEzzh2/6RudBK/B4ZwujYcMdUdeeMJ1aNOQ/kG/JaRDzMpoyn4yBmaJPHkX4vsjbaBGo9ZlyzFtldZGINx64mBqKdEKDZhlLf+FIeRx2z5eiNW8iBL2T5mwDU4xEZlbKDEjYwLTkptub1slborTdruxaY04EOwGL4Y39rmdcgoeu677pMN2tMohjHeUth0wjDuQSBC92QYMSmprKQnlvT+KF7IEjkegeKJVcuWFwA==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB462;
X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB462; 20:hQt5waiRVl73oIPuEkzqs83CCOExMiYiH1ZLwghfyIr46fBvaVa0qZW11YgX8wPKKqVYIJXC2LY5oAjGdSECPq+1pSQJYVV75bk2LohRZ8t88Tw1546HfhDyIl7suxyEqVnr4Zq6cXEsabUiiMspvdp0Q8u5NRtA+nYC71T2sMxemo1FO8V/jJBwy5to/2un/sojjDuC99c9vHEEe7QUDTtLzXTEF3uujnfzA7KfKRI7ck4pZgoTMwh9xnCbQhF8UvX7Y115oolpBTsWmgMOLu5peWpkOfIA927ZOMGVNOjNlW1fs0kIBXldaSDOFHdXk7nCoInPwMnfWwbUN8mVSKmAD9dA2GQ3gxOV3uxj0GXlJeNr+fkTuoz/2kD3iRTVG6Kx6ybPE3FJbtXTzX2vNp1mo9ZoMHBCMwrIizizyuLikhzGtkO9HeFMmmzGlS7Rreqt8Qvt1XSKf0a7L2AwNvOsXSy6erpSg2LDIa5B4YhwXSz20qRP+JLRv+WmZuCh; 4:vkZkKczDh0/ZbMCVBEPCv7+iyUhRr1MeMghPc5gp0JaUY6J7UaHo7AfFwc3DSsDm6zV+BQy2TMrPVv9d36kgllT3ZTmJ9dT7iavF5jRQiuml1mQubZNIbvs8EIvtVvAr8/T4WKM+O0aM0gJ9o6xorsaeSA/3MkYfUNzaNmiAFi2yh8RaLa9Q6RsjnUgUGyksja/KoJVCIIVUIq/+9X5N/fJiFQjNaIyLUj5jUe7lMoohYNUrnJnSQZIvAD/N1Y8x27jJd4lOq2bjT0XiygTycMHfrOfIWsxCOwF3D2f8R98C9gBfK++iSsSw26b3WgECP7XRxOsTqLPXrsN406FYcADslAisRounI2NEH++EKLFNapnZf7LLgeBqD4a5ypYq
X-Microsoft-Antispam-PRVS: <DM2PR05MB462DE484760895915EFCB0BAAED0@DM2PR05MB462.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:DM2PR05MB462; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB462;
X-Forefront-PRVS: 0790FB1F33
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(377454003)(377424004)(53754006)(164054003)(24454002)(189002)(199003)(5008740100001)(450100001)(66066001)(33656002)(47776003)(87976001)(83716003)(586003)(23726003)(82746002)(1096002)(230783001)(50466002)(76176999)(3846002)(6116002)(101416001)(122386002)(40100003)(77096005)(81156007)(86362001)(50226001)(92566002)(42186005)(97756001)(46406003)(5001770100001)(36756003)(97736004)(50986999)(107886002)(2950100001)(5001960100002)(105586002)(189998001)(106356001)(19580405001)(4001150100001)(19580395003)(5004730100002)(57306001)(15975445007)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB462; H:[172.29.35.202]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB462; 23:JqvtOQBE6U7M+Wccr7A9jT2BTiFJbV9ZlxMl7CIN5VfUj7fKsVoO7euIoYq9GFd1cGeym03eDdAQGuSTDhXuasPz16TPdPd5XFAUT8DcKlp8zeCfaWN2srb0BhyWB/ACxJpeI+0XYyfxI+bCb/DPS3WsFquG5RCkw+fj5cUkKY7J4V6uMvqhLsRQB6mzX5DftnioQLyPblFWkD528PqG8pevHLp5jG0vGQMJwfXT0foZySHn8cFjgqaJ+2S2/D4QBsTfuT9dxABMK62RZ9SKKGnUCnIlMwYdrvVEhdanG7foU9MtfczNIJpFHrOUYmKqognWq3pKbB4ZOsoLmo6wBaAUJzooyhNlNf+2WzzPBR3MImQk5heo5v5qd17i6g6lIx1bYFZneMDzCZ+I+Il77KJQ6eRM5cfq/m/TqTDNw4NX8eMzcoSJMBy7P538tOjrEggZHvVAvUjDofPui8CY0+l8O99uHtm6qwcRCyWC92eqryJONXhmTd6HAIBJbuQ0kuXK8M02qlr8VRVW4a8dV+mvNL8iBLxKZaSUCmWBK08xrNrJ0oayip+Xc1+z9nDKUQ1MQV8EdAIBTtDLi6nHp1xNemL+AyulnoEbvWfocZO5jduk+HUdxA8jIiGtE10sd8efGJQo4xSTdcttv1aZEsUlhfjAh/iWe9E5HI14TaZ3K/YgU8myRIEPPpIAx3jh6cQuY1gpQQ51LjnE6YxSGBR7uLDvLbnbGyweu2hSggrlmEVLlz7ftA3CYVw6mvnvh/NJs5oq5H0YEA5UX7s8wkkx/mkkWD+lJxqCH7D8kxFCcydcX5Isah+2pr1b3qtbWBgQWmZfIAdIUNh0qPCrmEAIoc1hxolTSxV8VEgTB9Dc2Ysi+jYFsN6Np4NISJpwzDinQW22bF9lD0tSt17ywmVmJUjJ0S/9pxBsa6G/oFUJvPJQf+oI/BP3CrZuB1J1pNI08hhtBi/k9RHOJIacqqRT2erPiVNG6aDLXHdtpgTmRe0pKcEEdLMr7+DX82lt8ITBP5ZZfQLvgim8srr4qQzgs7EfBz6MdbzXMZSfcGt41Ku4bVIUEB1xBJk1PL1T7O7DOY+p6Kgj1bffiM6H9LAN21t3FDGa+wt76vtEmtYKworXkfnyxNfeSTwkTDVNnWy6OZWpqwcHUqrR1jEShCjn2E8AsOprSxeRclIp48URJ1i1Tk8dvlJ67MHBg7PqtzkoZ1Ma4Byv7+sDjFYfeM4ErMZSQny4IC4YWq1I8HbYNt7GJjoS83TATdQpi7YPYY1lNZQWyqskONp780nA18yJUqtXZdHLvUDh0jqZRLeUrw4om2ru/eizyE66ilGR9quTs0Fi3825Z3yN7EbXizat14NYpxMbm//ymyQqQSpLm+v6sp1+eYCuYm470YMB
X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB462; 5:1PuIrB1BAnalQZHaWF+Y6vDYWLQ9e/mx4qKQfT8+9Zuv/OeK37aVzGXM007VdAlWyZanmEGD+tuII5I5MlZR05qDms1ngaQnqLjSRz1CjTF0fNOxuTBffTRLqo7IOwRElGpiazQ8nXL7Om6wxEq20A==; 24:YXkJ7kdMN+g8DShYuUQTnjhcC32U/ZApTWfGRCmDhYPsN+OAU1bULRj2WAevNKGv4O/KQo93ljZk8WMVFt1BpdlOGteXAAxIu+kclXhuJGo=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2015 17:09:39.7173 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB462
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/mKD3D9_TsxgBCkk2ty7A7FEJtAc>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-08.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 14 Dec 2015 17:10:17 -0000

Hi Everybody,

Just when we thought we were completely done with this draft, we were approached by Thomas King who pointed out a use case that can be enabled by validation signaling, which benefits from a minor revision in the language of the draft. Here's the revision:

OLD:
   By default, implementations SHOULD drop the origin validation state
   extended community if received from an EBGP peer, without further
   processing it.  However an implementation MAY be configured to accept
   the community when warranted, for example when the EBGP session is to
   a neighbor AS under control of the same administration.  Similarly,
   an implementation SHOULD NOT send the community to EBGP peers but MAY
   be configured to do so if warranted.

NEW:
   By default, implementations SHOULD drop the origin validation state
   extended community if received from an EBGP peer, without further
   processing it.  Similarly, by default an implementation SHOULD NOT
   send the community to EBGP peers.  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.kklf-sidr-route-server-rpki-light].

The change does two things. One is to add an informative reference to Thomas's draft. The second is a change in emphasis. Whereas we formerly said that an implementation MAY be configured to send and/or receive the community over EBGP, now we say it SHOULD be possible to configure it to do that.

I'm hoping this change will be noncontroversial and we can continue to move forward towards RFC, however I anticipate the respective working group chairs of SIDR and IDR (for obvious reasons I'm recusing myself) may want to have a period to allow people to comment.

Thanks,

--John

> On Dec 14, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.
> 
>        Title           : BGP Prefix Origin Validation State Extended Community
>        Authors         : Pradosh Mohapatra
>                          Keyur Patel
>                          John Scudder
>                          Dave Ward
>                          Randy Bush
> 	Filename        : draft-ietf-sidr-origin-validation-signaling-08.txt
> 	Pages           : 5
> 	Date            : 2015-12-14
> 
> Abstract:
>   This document defines a new BGP opaque extended community to carry
>   the origination AS validation state inside an autonomous system.
>   IBGP speakers that receive this validation state can configure local
>   policies allowing it to influence their decision process.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-validation-signaling-08
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr