IETF Logo Mail Archive

Re: [Idr] BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)

"Alvaro Retana (aretana)" <aretana@cisco.com> Tue, 04 April 2017 17:18 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFAD120326; Tue, 4 Apr 2017 10:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 6zwdlFm16Mjt; Tue, 4 Apr 2017 10:18:47 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95CA127A97; Tue, 4 Apr 2017 10:18:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2046; q=dns/txt; s=iport; t=1491326326; x=1492535926; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Tb8HSrjOairsO9UtzqvoxXCmK4QO28GGDIdI6Stamqk=; b=iF3jo7j7rTszwGHl3VQb69xy1a4FI4DcFrsFIPHxGRRUtQ73SDFo29pz g3evYvOfrFRDdxBJuiNJXSeJqUpCJRP1s1yIYiAZ25lDt893XgXux2EXP B3lsZDLXTh3jQyhGWHZjoABqmD1//zbx5OQlD71mNdGoEoSeTQyb6pqdw k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAgCX1ONY/5xdJa1cDgwBAQEBAgEBAQEIAQEBAYNUgWwHg1yKEpFblVOCDoYiAhqDKD8YAQIBAQEBAQEBayiFFgEEASMRRQULAgEIDgwCJgICAjAVEAIEDgWKBgitaYImimgBAQEBAQEBAQEBAQEBAQEBAQEBAR6BC4VDggWCaoQxI4MGLoIxAQSWGoZTAZJPgX2PP4hcixgBHziBBVsVUgGGCj11hl+BL4ENAQEB
X-IronPort-AV: E=Sophos;i="5.36,275,1486425600"; d="scan'208";a="218360369"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2017 17:18:46 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v34HIkWm012391 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2017 17:18:46 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 4 Apr 2017 12:18:45 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 4 Apr 2017 12:18:45 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Matthew Lepinski <mlepinski@ncf.edu>
CC: "sidr@ietf.org" <sidr@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "draft-ietf-sidr-bgpsec-protocol@ietf.org" <draft-ietf-sidr-bgpsec-protocol@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)
Thread-Index: AQHSrV6hkKLo0jlbPUCXfQgnSjWfzKG1vpmA///GcwA=
Date: Tue, 04 Apr 2017 17:18:45 +0000
Message-ID: <36894BDC-01FC-41A5-B7B8-BC91204AE1D2@cisco.com>
References: <65677770-43DB-4CE0-8E81-B35B9A82DF6F@cisco.com> <CA++NScEB1=TswjnszJm8_kghE2n8MX9gyDPePRsqqNALKyA6=g@mail.gmail.com>
In-Reply-To: <CA++NScEB1=TswjnszJm8_kghE2n8MX9gyDPePRsqqNALKyA6=g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.6]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E4C917595EB1F0489CD928DFB26083E5@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oSoMhypfa0RP2K55ySd9Dq92TmE>
Subject: Re: [Idr] BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 17:18:49 -0000

On 4/4/17, 12:44 PM, "Matthew Lepinski" <mlepinski@ncf.edu> wrote:

Matt:

Hi!

> The proposed changes seem reasonable, but I want to make sure that I
> understand the path forward clearly.
>
> My understanding is that if we were to reach a future where
> draft-ietf-idr-bgp-extended-messages is widely deployed, then the BGP
> speaker's maximum message size will just be larger (than it is today)
> and as a result we avoid reaching the point where Section 9.2 (of
> 4271) guidance is needed.
> 
> Is my understanding correct? 

Not exactly.

The text in 9.2/rfc4271 is generic, it doesn’t apply to a specific message size; the maximum size is defined elsewhere.  The current text of draft-ietf-idr-bgp-extended-messages changes the size of the messages in Section 4 (of rfc4271), which is the same place where 9.2 points to.  IOW, the text in 9.2 would not change and still be applicable, the limit would just be reached later.

> (I want to make sure that future
> implementers will find our text clear and we won't need to revise this
> spec to add clarity if extended messages ends up in widespread use.)

To me, the main purpose of changing the BGPsec spec is to depend on whatever BGP does, and not on a future extension that may or may not be in the form it is today.  However, if we keep the reference to the known standard (rfc4271), then we should not have to update this document because we would just inherit whatever BGP does.

Thanks!

Alvaro.

v2.23.0 | Report a Bug | By Email