IETF Logo Mail Archive

Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath

Christopher Morrow <morrowc.lists@gmail.com> Wed, 28 March 2012 22:15 UTC

Return-Path: <christopher.morrow@gmail.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 1CD0121E8101; Wed, 28 Mar 2012 15:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.559
X-Spam-Level:
X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 7M8FIXWMr3PE; Wed, 28 Mar 2012 15:15:15 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5347B21E80FB; Wed, 28 Mar 2012 15:15:15 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so2212580obb.31 for <multiple recipients>; Wed, 28 Mar 2012 15:15:14 -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:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OvDZYE8GehlboS1naVrDM7QBFZ4XJdcoNj+7y/yswtE=; b=lqYe5HtQE2U/CxqJFD6XnPE2xCCz0UDUuWFjdV0L9dCPibL6gWQTvMQp6GtrdsY2i6 JvtD0r38EF9L6WBBFBvMWvUUhMrH2SnUelgfdlFv7jc3Trf0rnqQOD2UF5FaO3HeCnY1 lvJRRfb/cyrBEaSDtvEr2k8s6h4dbP/tnCaWIU7zvsteyqeDbXAPQpL3AglV96EtL4wn BY9+Dz2TuBthDZ5cuTSszTInhnWdtcLPBV543qdqE+px1KdugTE80sey9qPwMKt2GDEr /YbOGXCRLGFGBtR/vYlNKw0hiBixXoKdb4oPHBCOLWDmtx02dwHkV3HwM/JVbU+abtPS iSYQ==
MIME-Version: 1.0
Received: by 10.182.155.68 with SMTP id vu4mr39979033obb.61.1332972914880; Wed, 28 Mar 2012 15:15:14 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 15:15:14 -0700 (PDT)
In-Reply-To: <4F7374DD.7060301@raszuk.net>
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> <alpine.LFD.2.02.1203281618090.2692@jamaica.dcs.gla.ac.uk> <CAL9jLaYqMwXVNKsHuBf_r8h==CGoee+D9k89Q4AZqT49jOQK1A@mail.gmail.com> <4F733C79.8080600@raszuk.net> <CAL9jLabVcWMtpu8usUS5w_BVPCG8ihvDcVjWbhnj_u6H-cdZkw@mail.gmail.com> <4F733FBE.1020902@raszuk.net> <CAL9jLaZJEkiJi3DPLTY35Ag9ynhTejjv09yx6NH4Oohwe975hg@mail.gmail.com> <4F736F6E.70205@raszuk.net> <CAH1iCirmYVkHChaLW3XHD7z3HkkUbSjT6F4iM7wASinoWjJc6A@mail.gmail.com> <4F7374DD.7060301@raszuk.net>
Date: Wed, 28 Mar 2012 18:15:14 -0400
X-Google-Sender-Auth: Pl6mxZAWlmXnwmU-G4enVt-_ots
Message-ID: <CAL9jLaacqj9Dm5E5ELms=S+oBZ25bstZaBtaEn0mV7YBrcNwiQ@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: robert@raszuk.net
Content-Type: text/plain; charset="ISO-8859-1"
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 22:15:16 -0000

On Wed, Mar 28, 2012 at 4:30 PM, Robert Raszuk <robert@raszuk.net> wrote:
> I am saying that it exists in shipping implementations and simply asking
> what SIDR behaviour should be when such policy is present.

I guess what I wasn't saying was that not every oddball wierdness
permitted TODAY in BGP is able to be secured, or validate-able. It's
not required that this be the case actually.

-chris

v2.29.0 | Report a Bug | By Email | System Status