Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath
Jeffrey Haas <jhaas@pfrc.org> Wed, 28 March 2012 21:17 UTC
Return-Path: <jhaas@slice.pfrc.org>
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 44A7421F843E; Wed, 28 Mar 2012 14:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.163
X-Spam-Level:
X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoED3lGA5iGT; Wed, 28 Mar 2012 14:17:42 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8221E8132; Wed, 28 Mar 2012 14:17:29 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id E2C80170421; Wed, 28 Mar 2012 17:17:28 -0400 (EDT)
Date: Wed, 28 Mar 2012 17:17:28 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Message-ID: <20120328211728.GD16814@slice>
References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1203281401410.2692@jamaica.dcs.gla.ac.uk> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <FBFDBAE5-9BF8-4708-9240-B775CAF46D56@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "idr@ietf.org List" <idr@ietf.org>, Paul Jakma <paul@jakma.org>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 28 Mar 2012 21:17:43 -0000
On Wed, Mar 28, 2012 at 10:56:52AM -0400, Jakob Heitz wrote: > The issue is SIDR can not aggregate multiple paths. > > Solutions I can think of: > 1. Aggregate the signatures of the paths being aggregated. What are the semantics you're trying to preserve SIDR-wise? We're hitting the realm where Russ White would point out that BGP path validation can't prove how forwarding works. Presume we managed to pass along two distinct paths for the same multi-path route in BGP. What do you do if one doesn't validate? What do you do if they do, but you think this is a form of a "route leak" for one path? As a receiver of the route that is making use of multipath, you can't selectively choose which sub-paths to take. (It's not like we're gettng something like MPLS entropy labels.) > 2. Don't aggregate, but send both paths. That doesn't cover the actual forwarding semantics. > Should SIDR work on path aggregation? > Are there other possibilities? The biggest problem here is "SIDR secures BGP". The issue hasn't been clear in BGP for years, although I'm perhaps of the cynical opinion that it's been a well understood problem space for a while now. The protocol doesn't reflect what is done operationally. The safe thing operationally when aggregating unsafe paths is to generate sets, but some people have never liked sets. And as I mentioned elsewhere, it doesn't matter as long as you take care in where you redistribute such unsafe multipath. There was a reason I wasn't terribly supportive of the deprecating AS_SETs I-D. However, I also knew it was a losing battle. :-) -- Jeff
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Jakob Heitz
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Paul Jakma
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Jakob Heitz
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Robert Raszuk
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Jakob Heitz
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Paul Jakma
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Christopher Morrow
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Robert Raszuk
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Christopher Morrow
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Robert Raszuk
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Jeffrey Haas
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Christopher Morrow
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Murphy, Sandra
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… heasley
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Jakob Heitz
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Robert Raszuk
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Robert Raszuk
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Brian Dickson
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Robert Raszuk
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Jeffrey Haas
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Jeffrey Haas
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Jeffrey Haas
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Christopher Morrow
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Jakob Heitz
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Jeffrey Haas
- Re: [sidr] [Idr] AS_SET depreciation (RFC6472) an… Susan Hares