IETF Logo Mail Archive

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

"Alvaro Retana (aretana)" <aretana@cisco.com> Tue, 04 April 2017 16:15 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 A7DB5127775; Tue, 4 Apr 2017 09:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.12
X-Spam-Level:
X-Spam-Status: No, score=-13.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, 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, T_HTML_ATTACH=0.01, 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 SC64vfQFF6B8; Tue, 4 Apr 2017 09:15:13 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6691287A7; Tue, 4 Apr 2017 09:15:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=117185; q=dns/txt; s=iport; t=1491322513; x=1492532113; h=from:to:cc:subject:date:message-id:mime-version; bh=VPq5kPXYpe4WtJcwKu78zmusRDKF5XVEQppGETLNWAY=; b=fcnGYV5b5/SsVDkBUpi7hx8JcyWfaoP6nCIkvIY5XO9kL9RypfSsot63 6aNVd8IM9gSGrjWeP9IBHD56ADlqvUGXotHFDE+U5rL+xeQ/I5ieyWzG2 eixqpp0ElLLL6c2mJx5AIeVn/ZgOQZtCKI25/wh08REV2OUYny49yoW2u g=;
X-Files: Diff_ draft-ietf-sidr-bgpsec-protocol-22-download.txt - draft-ietf-sidr-bgpsec-protocol-23.txt[1].html : 75707
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CqAgC3xeNY/4cNJK1cGgEBAQECAQEBAQgBAQEBgm47K2GBCweDXIIGiAyRO5Vygg4shByBWhyDKD8YAQIBAQEBAQEBax0LhTYJCjoHCxIBQAEGAwIEMBQTBA4FCQWKAA6sTA+BIIImK4oxAQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+GToIFCIV5gQQWgykugjEFiSOMd4IrhCgBg3uDAX6FU4UCgX0ZPIRZiFeBOohchnKEJgEfOIEFWxVBEQGEDjYggWN1AYZeASQHgQOBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.36,275,1486425600"; d="html'217?scan'217,208,217";a="404513103"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2017 16:15:10 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v34GFAqP019695 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2017 16:15:10 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 4 Apr 2017 11:15:09 -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 11:15:09 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "sidr@ietf.org" <sidr@ietf.org>
CC: "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: AQHSrV6hkKLo0jlbPUCXfQgnSjWfzA==
Date: Tue, 04 Apr 2017 16:15:09 +0000
Message-ID: <65677770-43DB-4CE0-8E81-B35B9A82DF6F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
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: multipart/mixed; boundary="_004_6567777043DB4CE08E81B35B9A82DF6Fciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mWUSStttdgVPbaojZeOon_RNs58>
Subject: [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 16:15:18 -0000

Dear sidr WG:

As has been discussed in the mailing list and at the sidrops meeting last week in Chicago, there is interest to not have the BGPsec document (draft-ietf-sidr-bgpsec-protocol) depend normatively on the Extended Messages work (draft-ietf-idr-bgp-extended-messages).  Based on that discussion, Sriram and I have come up with proposed diffs – please see the attachment (-23 has not been posted yet).

To summarize, the changes are: (1) remove mention/references of/to draft-ietf-idr-bgp-extended-messages, and (2) add the following text in Section 4.1. (General Guidance):

    All BGPsec update messages MUST conform to BGP's maximum message
    size.  If the resulting message exceeds the maximum message size,
    then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be
    followed.

[For easier reference, I put the relevant text from 9.2 below.]

The result is then that draft-ietf-sidr-bgpsec-protocol doesn’t depend on draft-ietf-idr-bgp-extended-messages.  Instead, when referring to the size of the messages, it depends on rfc4271.

Please let me know if you have any concerns.  I will wait a week before proceeding.

Given that this document has already been approved by the IESG, the process going forward is:

- consult the WG (this thread)
- inform the IESG of the intent
- inform the IETF (ietf@ietf.org)<mailto:ietf@ietf.org)> of the changes
- publish an updated draft
- continue the publication process

Each step may, obviously, require additional discussion and could result in changes to the current plan.

Thanks!!

Alvaro.




https://tools.ietf.org/html/rfc4271#section-9.2

9.2.  Update-Send Process

…
   If, due to the limits on the maximum size of an UPDATE message (see
   Section 4), a single route doesn't fit into the message, the BGP
   speaker MUST not advertise the route to its peers and MAY choose to
   log an error locally.

v2.23.0 | Report a Bug | By Email