Re: [Idr] draft-lapukhov-bgp-opaque-signaling

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Mon, 14 March 2016 04:37 UTC

Return-Path: <jheitz@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 5CC2C12DA0C for <idr@ietfa.amsl.com>; Sun, 13 Mar 2016 21:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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=-0.001, 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 ocqsblMi_zLP for <idr@ietfa.amsl.com>; Sun, 13 Mar 2016 21:37:48 -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 BFA5E12D9CA for <idr@ietf.org>; Sun, 13 Mar 2016 21:37:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16082; q=dns/txt; s=iport; t=1457930267; x=1459139867; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DVHgC7D/c+CzOI2QIpcolxo5VHXDx/tt5syMZm1c/9s=; b=IKtafolrC1B5g76uKklhaZtQOqgVtG3W2Qo4Q1sk1bdkk0cbpJ5IALz0 45IBjb0QDobqyfIooiBGyqPSS8B/EI7FxpA7EknF26QSXP7l4mtXksL3P 5/lt+KxXWUkpjg1Ek5WlkfEbk7NgMX8SnJdAx/XBgCCwEPnUqwqYIqe6U E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AmAgBOP+ZW/4cNJK1dgnpMUm0GuioBDYFtIIVtAoEmOBQBAQEBAQEBZCeEQQEBAQQtXAIBCBEEAQEoBzIUCQgBAQQBEggBEogJDro7AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYYhEKEZwmEBAWIO4R+hUqESAGFbYgLgWxLhySFMYYIiHQBHgEBQoFMNxmBSGoBAQGJYn4BAQE
X-IronPort-AV: E=Sophos;i="5.24,334,1454976000"; d="scan'208,217";a="249112032"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Mar 2016 04:37:46 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2E4bkQb018803 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Mar 2016 04:37:46 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 13 Mar 2016 23:37:45 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Sun, 13 Mar 2016 23:37:45 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Petr Lapukhov <petr@fb.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: draft-lapukhov-bgp-opaque-signaling
Thread-Index: AdF8nS8FQTTx9jiyQtWM4z1Bl2FmugABRu++AABFuBAAPFwa0A==
Date: Mon, 14 Mar 2016 04:37:45 +0000
Message-ID: <82489e182ab34b74a29cea2f5e3866bf@XCH-ALN-014.cisco.com>
References: <2d12cade49ac4ec19a7f2c80aee3b72d@XCH-ALN-014.cisco.com> <3F437107848A5140A6A19222EFFB3481200E2389@PRN-MBX01-2.TheFacebook.com> <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com>
In-Reply-To: <976fb2df5f974b298a04b547afb917b7@XCH-ALN-014.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.75.186]
Content-Type: multipart/alternative; boundary="_000_82489e182ab34b74a29cea2f5e3866bfXCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/FktNO20zKxieQjsLasCH3VAd6gc>
Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling
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, 14 Mar 2016 04:37:50 -0000

I was thinking more of how a service provider would use this with different
customers that don't know about each other, like preventing ships in the night from
crashing into each other. However, it could work in private.

Without a route target, any data sent will go everywhere and be stored in every router.
You probably don't want that.
This new AFI should require a route target. That means an update message without an RT must be dropped.

BGP treats all updates the same.
Once the floodgates are open to generic data, you might want to invent a precedence attribute.

Thanks,
Jakob.


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Saturday, March 12, 2016 1:12 PM
To: Petr Lapukhov <petr@fb.com>; idr@ietf.org
Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling

Without this problem solved, the proposal is not useful.
Everybody using it must stick to the eventual solution to ensure interoperability.
Therefore, it should be inside the scope.

Actually, BGP already has a way to distinguish applicationd: AFI and SAFI.

Jakob.

From: Petr Lapukhov [mailto:petr@fb.com]
Sent: Saturday, March 12, 2016 1:06 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; idr@ietf.org
Subject: RE: draft-lapukhov-bgp-opaque-signaling

Hi Jakob,

There is an ongoing discussion around avoiding NLRI (key) collisions. For now, the plan is to externally generate unique key prefix per application, e.g. application name, or UUID or some other globally unique string. Ensuring the uniqueness of those prefixes is outside the scope of the proposal, though - it's more of a deployment consideration.

Regards,

Petr

________________________________
From: Idr [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [jheitz@cisco.com]
Sent: Saturday, March 12, 2016 12:26 PM
To: idr@ietf.org
Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque-signaling

I read

http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_id_draft-2Dlapukhov-2Dbgp-2Dopaque-2Dsignaling-2D01.txt&d=CwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=LU_vJaM_EQu1Ssm35j2xlA&m=y8paWUSIMD4YG8hfWC8k0b55e7qWYVRgGAwsXJKLMD4&s=-jEO1Jw88BI6pWUJf9es7WC0Q8Sm0XfBIhYRrWQCBHg&e=>


Is this intended for any and multiple applications to use?
If so, how do independent applications guarantee no duplication in NLRI?
If not, what is the target application?

Thanks
Jakob.