Re: [sidr] [Idr] No BGPSEC intradomain ?

"George, Wes" <wesley.george@twcable.com> Thu, 12 April 2012 12:08 UTC

Return-Path: <wesley.george@twcable.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 1669421F865A; Thu, 12 Apr 2012 05:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.777
X-Spam-Level:
X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1]
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 19jnQzTYnrq9; Thu, 12 Apr 2012 05:08:34 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3F53821F85C2; Thu, 12 Apr 2012 05:08:34 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="366668100"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Apr 2012 08:07:09 -0400
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 12 Apr 2012 08:07:43 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Christopher Morrow <morrowc.lists@gmail.com>, Paul Jakma <paul@jakma.org>
Date: Thu, 12 Apr 2012 08:07:43 -0400
Thread-Topic: [sidr] [Idr] No BGPSEC intradomain ?
Thread-Index: Ac0X9vKgDybfDBfvSGCdfgxGGidh+AAQtH5A
Message-ID: <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AAB@PRVPEXVS03.corp.twcable.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk> <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com>
In-Reply-To: <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] No BGPSEC intradomain ?
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: Thu, 12 Apr 2012 12:08:35 -0000

Thanks,

Wes

Wesley George
Time Warner Cable
ATG Technology Development
office: 703-561-2540 | mobile: 703-864-4902


> -----Original Message-----
> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Wednesday, April 11, 2012 11:23 AM
> To: Paul Jakma
> Cc: idr@ietf.org List; sidr@ietf.org
> Subject: Re: [sidr] [Idr] No BGPSEC intradomain ?
>
> On Wed, Apr 11, 2012 at 10:12 AM, Paul Jakma <paul@jakma.org> wrote:
> > On Tue, 10 Apr 2012, Jakob Heitz wrote:
> >
> >> I agree with Robert. Today, there are many tools that interact with BGP
> >> messages. If the AS_PATH disappears, they will all break.
> >
> >
> > Indeed. If mandatory, well-known attributes are removed, then the BGP
> > protocol version number needs to be bumped.
> >
> > There's near-0-cost in doing that for those interested in implementing the
> > new functionality, and it avoids a world of hurt for all the various tools
> > (sometimes in-house/home-grown) out there that believe they know what
> > they're getting when the version says 4.
>
> "if you don't ask for the 'bgpsec capability' then ... you get what
> you get today."
>
> also
>
> "if you ask for the 'bgpsec capabiltiy' then ... you get (and can
> presumably handle) the changes"
>
> so, everything you do today, ought to just keep right on working, or
> that's the plan.

[WEG] Why *are* we so resistant to incrementing the BGP version? I think that there's some merit to the idea that this suite of things represents a significant enough change to BGP that a change in version number might be a cleaner way to do the capability negotiation, perhaps even incorporating other secondary capabilities so that there isn't so much individual capability negotiation for all of the things that we've tacked onto BGP4 over the years. In other words, if you support BGPv5, you support the a list of capabilities (eg 4-byte ASN, GR, route refresh, etc), and they no longer have to be negotiated separately. Even if we move directly from version 4 to 6 as it seems we are wont to do, I think this bears some consideration (by IDR, of course) ;-)

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.