Re: [sidr] various

"George, Wes" <wesley.george@twcable.com> Sat, 12 November 2011 12:56 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 F1FB021F84A5 for <sidr@ietfa.amsl.com>; Sat, 12 Nov 2011 04:56:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.363
X-Spam-Level:
X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
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 2Vn2Njhw1048 for <sidr@ietfa.amsl.com>; Sat, 12 Nov 2011 04:56:57 -0800 (PST)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5777C21F847F for <sidr@ietf.org>; Sat, 12 Nov 2011 04:56:57 -0800 (PST)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,498,1315195200"; d="scan'208";a="281339909"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Nov 2011 07:52:08 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Sat, 12 Nov 2011 07:56:56 -0500
From: "George, Wes" <wesley.george@twcable.com>
To: Randy Bush <randy@psg.com>
Date: Sat, 12 Nov 2011 07:57:17 -0500
Thread-Topic: various
Thread-Index: AcyhKDI81Tfzw4xtTsmxm/84o1KYxQADkvwQ
Message-ID: <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CCE9@PRVPEXVS03.corp.twcable.com>
References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CC8D@PRVPEXVS03.corp.twcable.com> <m2ehxef1ob.wl%randy@psg.com> <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CCDA@PRVPEXVS03.corp.twcable.com> <m2aa81g7hp.wl%randy@psg.com> <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CCE5@PRVPEXVS03.corp.twcable.com> <m2d3cxei0p.wl%randy@psg.com>
In-Reply-To: <m2d3cxei0p.wl%randy@psg.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: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] various
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: Sat, 12 Nov 2011 12:56:58 -0000

> From: Randy Bush [mailto:randy@psg.com]
> Sent: Saturday, November 12, 2011 5:45 AM
> To: George, Wes
> Cc: sidr wg list
> Subject: Re: various
>
> > "However, signed updates received from BGPSec speakers outside of the
> > confederation (i.e. those transiting the confederation ASes) MUST be
> > passed to the other Member-ASes BGPSec speakers intact.
>
> nope.  you could decide to strip toward one or more confed peers which
> are not bgpsec capable.  your routers, your decision, your policy.
> don't go there.

[WEG] there's no deciding. If the peers are not BGPSec capable, you're already required to strip towards that peer, no exception was made for confed peers. The only available policy decision is whether or not you want the info carried across the confed to other BGPSec capable peers, so maybe make it a SHOULD so that it's configurable, but I think it's incomplete as is.
>
> imiho, saying anything more is either adding unnecessary words at best
> or opening up large complexity holes at worst.

[WEG] yes, there's a fine line, but as I've said before, an operational considerations document is where some of these details and their associated primrose paths have to be discussed, because you get into the shades of gray world of operationalizing this stuff. We're not always going to be able to consult you for a ruling on all of the things that you didn't say, and the IETF has no Supreme Court to interpret the "founders" intentions for those left behind.

> > I figured it'd be clear from the above discussion
>
> and yet you want to me to go into unnecessary complications not
> directly needed given my brutally specific statement?  :)
[WEG] Your brutally specific statement is so specific that it does not mention the second case at all, because it's not about confeds. :-)
Do you or do you not agree that on the transition between private ASN and public, if remove-private is configured, any signatures containing private ASN must be removed even if the eBGP peer is BGPSec capable?

Wes

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.