IETF Logo Mail Archive

Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017)

"Susan Hares" <shares@ndzh.com> Mon, 06 February 2017 20:01 UTC

Return-Path: <shares@ndzh.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 E689D1295D5; Mon, 6 Feb 2017 12:01:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no
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 bv19Oe8gVd4m; Mon, 6 Feb 2017 12:01:50 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99BF31295F9; Mon, 6 Feb 2017 12:01:38 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.124.247.135;
From: Susan Hares <shares@ndzh.com>
To: "'Borchert, Oliver (Fed)'" <oliver.borchert@nist.gov>, 'John Scudder' <jgs@juniper.net>
References: <CY1PR09MB0444DBE54A903BB24A2A0F45844D0@CY1PR09MB0444.namprd09.prod.outlook.com> <24581E62-94D7-4D2E-8157-21ADF1CE7AF1@nist.gov>
In-Reply-To: <24581E62-94D7-4D2E-8157-21ADF1CE7AF1@nist.gov>
Date: Mon, 06 Feb 2017 14:57:08 -0500
Message-ID: <00ff01d280b3$33771830$9a654890$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFa04UJGQxVwyjfrfL4tU0zb1CHYAIFmXkSojuOasA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WVp1goSts2iWfcAC5XXu2cssBQQ>
Cc: idr-chairs@ietf.org, idr@ietf.org
Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 06 Feb 2017 20:01:52 -0000

Oliver would you fill review the form at:  
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

Please suggest changes to the way the implementation report is worded.  

Could you provide information on what happens if a peer: 
4a) SHOULD NOT Accept EXTENDED MESSAGE from peer if has not advertised BGP Extended Capability , and 
4b) It is not configured to the "MAY" that allows receiving the message Extended Messages 

Does it follows RFC4221 handling sending Bad Message Length Notification and resets session? 

Sue 

-----Original Message-----
From: Borchert, Oliver (Fed) [mailto:oliver.borchert@nist.gov] 
Sent: Friday, February 3, 2017 7:44 PM
To: Susan Hares; John Scudder (jgs@juniper.net)
Cc: idr-chairs@ietf.org; idr@ietf.org
Subject: Re: Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017)

At NIST we have two independent implementations of the BGPsec Protocol including the extended message capability as specified in “draft-ietf-idr-bgp-extended-messages-14”.

They are:
(1) QuaggaSRx, an extension to the Quagga router implementation
(2) BGPSEC-IO, a BGPsec traffic generator that allows generating multihop BGPsec updates.

QuaggaSRX:
==============
The implementation includes the following features in accordance with the draft:
1. Announce via BGP Capability advertisement (RFC5492) as BGP Extended Capability: Yes 2. If BGP Extended Capability negotiated, then MUST receive and process message larger than 4096 bytes: Yes 3. If BGP Extended Capability not negotiated, then MUST NOT send message larger than 4096 bytes: Yes 4. MAY accept EXTENDED MESSAGE from peer if not advertised BGP Extended Capability: Yes

BGPSEC-IO:
==========
The implementation includes the following features in accordance with the draft:
1. Announce via BGP Capability advertisement (RFC5492) as BGP Extended Capability: Yes 2. If BGP Extended Capability negotiated, then MUST receive and process message larger than 4096 bytes: Yes 3. If BGP Extended Capability not negotiated, then MUST NOT send message larger than 4096 bytes: Yes 4. MAY accept EXTENDED MESSAGE from peer if not advertised BGP Extended Capability: Yes


Thanks,
Oliver
-------------------------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238

v2.23.0 | Report a Bug | By Email