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 16:24 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 8AA6C12D841 for <idr@ietfa.amsl.com>; Wed, 25 May 2016 09:24:34 -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 bd86IlOUqKr3 for <idr@ietfa.amsl.com>; Wed, 25 May 2016 09:24:31 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5223212D84C for <idr@ietf.org>; Wed, 25 May 2016 09:24:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27109; q=dns/txt; s=iport; t=1464193471; x=1465403071; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZEKZnQnRzKkGmCaRu5nKnJxCC9G6ViKzVgeAeeFPWTo=; b=Q0uaaji002owFwTGJQKxRkJ2GSRFYB11J+NuyWvo6snWYqD6SmOmQfPq 9IXDtBIrQOGliDisxQrZbRwToAyr3z7gtOWSeqF/dntWXkAzu917dng2w nKhZRKlESvaz+vd22NyrZjPcLn1JG5P7FabT1tMRbfDlmaQaMots3OvS/ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgB70EVX/5ldJa1cgmxLVn0GuXEBD?= =?us-ascii?q?YF3FwEKhW8CHIElOBQBAQEBAQEBZSeEQwEBAQQBAQEgSwsQAgEIEQMBAigDAgI?= =?us-ascii?q?CJQsUCQgCBA4FG4gUDrI+kW0BAQEBAQEBAwEBAQEBAQEBAQEBFwWGJ4RMhDItg?= =?us-ascii?q?mGCWQWYNwGOH4FpjTOGM4kYAR4BAUKDbW6ISz1/AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208,217";a="106343189"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 16:24:29 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4PGOTtC031139 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 16:24:29 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 12:24:27 -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 12:24:28 -0400
From: "Keyur Patel (keyupate)" <keyupate@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)
Thread-Index: AQHRtqHoXuJ+eihBNEmCsBnJQ/gDcw==
Date: Wed, 25 May 2016 16:24:28 +0000
Message-ID: <D36B1BD7.40862%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> <D36B17B7.40835%keyupate@cisco.com> <CA+b+ERkzRFAS5EJ08ohbuN-KkzKDfar=tMMRqN6vkxEAa3JL-Q@mail.gmail.com> <D36B199A.40851%keyupate@cisco.com> <CA+b+ERnMFFUYQKbAKswrd4vCjZD7E-hUU3joQUE6hPM3_U7jNw@mail.gmail.com>
In-Reply-To: <CA+b+ERnMFFUYQKbAKswrd4vCjZD7E-hUU3joQUE6hPM3_U7jNw@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_D36B1BD740862keyupateciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/dQryJqArmA4OZUWAHLA2zpwhSN4>
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 16:24:34 -0000

Hi Robert,

There are Implementations that provide an ability of selectively dropping attributes as part of error handling solution.  We could add text that suggests the same.

However, dropping optional transitive attributes (in a somewhat random fashion or based on their size) without a knowledge of network operator MAY result in partial deployment of such attributes and its features and could have other issues in itself!

Regards,
Keyur

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


I listed 4 alternative solutions earlier in this thread already :). Dropping NLRI no matter how rear it would be is not one of them.

Your solution is not going to work in practice if extended msg is cap negotiated on by default (after upgrade) as there always be speakers which get upgraded later (if at all).

Rgs,
r.



On Wed, May 25, 2016 at 6:00 PM, Keyur Patel (keyupate) <keyupate@cisco.com<mailto:keyupate@cisco.com>> wrote:
Hi Robert,

Comments inlined #Keyur1

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


​You missed the scenario I am afraid :)

R1 --- RR --- R2


R1 and RR support extended message ... R2 does not.

So R1 sends to RR NLRI with attributes exceeding 4K as he has no clue who is behind RR and what they support.

How RR is supposed to pass this prefix with bunch of attributes larger then 4K to R2 ?

#Keyur1: IMHO, by enabling extended messages on R2. ;)

Whats the alternative to “enabling extended messages” so that the prefix with attribute size larger than 4K is delivered to R2? :)

Regards,
Keyur



Best,
R.
​

On Wed, May 25, 2016 at 5:51 PM, Keyur Patel (keyupate) <keyupate@cisco.com<mailto:keyupate@cisco.com>> wrote:
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.
​

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr