IETF Logo Mail Archive

Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

"Keyur Patel (keyupate)" <keyupate@cisco.com> Wed, 25 May 2016 15:51 UTC

Return-Path: <keyupate@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 2214D12D7F7 for <idr@ietfa.amsl.com>; Wed, 25 May 2016 08:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 H2cgxv4vbU_Y for <idr@ietfa.amsl.com>; Wed, 25 May 2016 08:51:10 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F0612B015 for <idr@ietf.org>; Wed, 25 May 2016 08:51:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11969; q=dns/txt; s=iport; t=1464191463; x=1465401063; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9+eleZYXT4ZNnUEcoawNnvdnSacMsq5jU2nYYyfmMZ4=; b=WEOicrmqWuF+gqDOkDvPq/rhN/86pofVHZYESyjcx122CBn+OsdIvdIW EMdZltiiweQPA5Xd7JfG1gBSEl2620bAHoXqz8YU1zB11NOBJ/2zb1OVC LNLMPYHQC7Rqny3vuqCZP5IhQ48ntZOYX1JW8IdPTJdcXBwlJroJNn9Oi Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BAAgCMyEVX/5pdJa1cgmxLgVMGtHiEeQENgXeGEQIcgSU4FAEBAQEBAQFlJ4RDAQEBBCNWEAIBCBEDAQIoAwICAjAUCQgCBAENBYgvskKRbAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4RMhF+CYYJZBZg3AY4fgWmNM4YziRgBHgEBQoNtbokIfwEBAQ
X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208,217";a="276960058"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 15:51:02 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4PFp291009183 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 15:51:02 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 11:51:01 -0400
Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Wed, 25 May 2016 11:51:01 -0400
From: "Keyur Patel (keyupate)" <keyupate@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)
Thread-Index: AQHRtp08K/E7XomEXUSbCzMdYMvGjQ==
Date: Wed, 25 May 2016 15:51:01 +0000
Message-ID: <D36B17B7.40835%keyupate@cisco.com>
References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> <CA+b+ERmdpCmCsP-5_NsLH6pbay4zaXMpjGJP2S3z8gfAAXZR8A@mail.gmail.com> <D36B06A7.6257D%acee@cisco.com> <CA+b+ERkioULCYg_HQK9qqN+wjiapTZxK7nHWLGaq_=8wfxajsA@mail.gmail.com> <D36B2E2D.625D3%acee@cisco.com> <D36B1406.4080E%keyupate@cisco.com> <CA+b+ERm0p7-tHJmo5CWDu2ZAOcMsngf84K6wRnn6Doa16QyRzQ@mail.gmail.com>
In-Reply-To: <CA+b+ERm0p7-tHJmo5CWDu2ZAOcMsngf84K6wRnn6Doa16QyRzQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.6.18]
Content-Type: multipart/alternative; boundary="_000_D36B17B740835keyupateciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/KJi6-oi0HIo-eoFiax9Lm9ho4KI>
Cc: Bruno Decraene <bruno.decraene@orange.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)
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: Wed, 25 May 2016 15:51:12 -0000

Hi Robert,

I thought the context of that line “not generating single NLRI if attributes exceed 4K” was for peers not supporting extended messages.

Otherwise its a moot point. :)
Regards,
Keyur

From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Date: Wednesday, May 25, 2016 at 8:48 AM
To: Keyur Patel <keyupate@cisco.com<mailto:keyupate@cisco.com>>, "Acee Lindem (acee)" <acee@cisco.com<mailto:acee@cisco.com>>
Cc: Bruno Decraene <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>, "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>>, Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)


Additionally, we could discourage the generation of a single NLRI exceeding 4K.

#Keyur: Yep. I agree. :)

​The entire idea for this draft was triggered by the fear that BGPSec may not fit to 4K update msg.

The draft explicitly states so as a motivation for this work.

Section 1

   "As BGP is extended to support newer AFI/SAFIs and newer capabilities (e.g.,
   [I-D.ietf-sidr-bgpsec-overview]), there is a need to extend the maximum message
   size beyond 4096 octets."

​Now in turn the referenced draft clearly defines that NLRI will only contain single prefix:

Section 3.2

   "When a BGP speaker originates a BGPsec update message, it creates a
   BGPsec_Path attribute containing a single signature. The signature
   protects the Network Layer Reachability Information (NLRI), the AS
   number of the originating AS, and the AS number of the peer AS to
   whom the update message is being sent. Note that the NLRI in a BGPsec
   update message is restricted to contain only a single prefix."

Question:

​So what exactly are we to discourage here because clearly not "generation of single NLRI exceeding 4K" ?

Maybe deployment of BGPSec till all BGP routers in the world support this new extended message size ?

Thx,
R.
​

v2.23.0 | Report a Bug | By Email