[Idr] BGP Role capability questions (draft-ymbk-idr-bgp-open-policy-03)

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Thu, 23 March 2017 16:01 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 A4648127078; Thu, 23 Mar 2017 09:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 ywvkC3z344Wl; Thu, 23 Mar 2017 09:00:59 -0700 (PDT)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0111.outbound.protection.outlook.com [23.103.201.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA29127369; Thu, 23 Mar 2017 09:00:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cqTMTCg3DfEn7hMZE2JSUzBShcgS3qu+8A15hujWDpI=; b=bG7CufsIZb0DsmHArCGZh+zlVLO6wnAYv6qCmQBryc7c5dp2GNNWxVUdjenMGEYg7I6RXSx2Q7th7PoJ4tbed8WIuZUrebGhsSuIW37kdTYPnObRMNTXBFQZttiA6HulGajj6OnnI63vwHviaxbT6PH3rvLJ+iOTmDYw6EFG+uc=
Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 16:00:53 +0000
Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0977.019; Thu, 23 Mar 2017 16:00:53 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: "aa@qrator.net" <aa@qrator.net>, Randy Bush <randy@psg.com>
CC: IDR <idr@ietf.org>, GROW WG <grow@ietf.org>
Thread-Topic: BGP Role capability questions (draft-ymbk-idr-bgp-open-policy-03)
Thread-Index: AQHSo+jvP6hZpcGmrUeYJg4L0E9giw==
Date: Thu, 23 Mar 2017 16:00:53 +0000
Message-ID: <DM2PR09MB0446B23F454A0F02EE7DBADB843F0@DM2PR09MB0446.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [129.6.218.117]
x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:OZEHsynHoaRawJ0WSxcKRMWoIz9cgVDnSdfAJHsWvTHeqCCO4JQrfzuGfmJq5bbOf9rYONaiTtqMqAHQKsW/X/kT+E5fVpMy4wEy2WAoJhXQbBhiYz5on9VqM4gniBBPR/10pMAYhuOGLjHGWjSJsiYm7Tes+FvatG2i32rpkjhwKB7MEczFDZdDdaT+gNez8wlwRWWEuBsvWcTCe6qzicN8yLVgDpJwpCbYVSndimMSwh5aRfFt8bo3qeWDJsNmMadGoEF5KkZY/4XUl36lUEQwdTmvEPasEogVTNzNwqQiApvXdL/AXpFkfjsqgCtVpLrTaECEYxqknLJE0BFTaw==
x-ms-office365-filtering-correlation-id: 87bc6241-ebde-47d2-074b-08d47205c8df
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0446;
x-microsoft-antispam-prvs: <DM2PR09MB04461DEC0FE4165331A214E0843F0@DM2PR09MB0446.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(20161123564025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446;
x-forefront-prvs: 0255DF69B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(53936002)(561944003)(189998001)(8676002)(3280700002)(86362001)(3660700001)(66066001)(7736002)(99286003)(25786009)(33656002)(55016002)(7696004)(5660300001)(81166006)(8936002)(6506006)(2900100001)(9686003)(2906002)(6436002)(74316002)(54906002)(54356999)(2501003)(50986999)(3846002)(305945005)(122556002)(230783001)(102836003)(77096006)(38730400002)(6116002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 16:00:53.0520 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WAZwyDon8iTSkfg0NNbyYP2nBWM>
Subject: [Idr] BGP Role capability questions (draft-ymbk-idr-bgp-open-policy-03)
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: Thu, 23 Mar 2017 16:01:02 -0000

This is meant to be friendly feedback/questions on the BGP Role capability proposal.
I think the claim is automation, which I am trying to understand/appreciate.
My difficulty is that BGP Role negotiation does not seem self-sufficient.
It still requires out-of-band (OOB) communication between operators to know 
the peering relationship, ASN, interface IP address, etc.  before BGP OPEN can be sent.
Then only can the operator fill in their BGP Role in the enhanced BGP OPEN message. Right?
So, BGP Role capability only seeks to re-confirm, does not replace the OOB part.

I suppose, if the BGP Role messages contradict with each other 
or with the prior OOB communication, the operators fall back on OOB 
once again to fix the miscommunication.
Further, for a "complex" relationship, the operators must inform 
each other via the OOB communication, the exact sets of prefixes 
for which they have different types of peering roles.
The BGP Role negotiation does not assist in that process. 
The per-prefix role info (for "complex") comes only from the OOB communication.

Considering the above, the following key statements 
in the Abstract (in the bgp-open-policy draft) do not seem entirely correct:

" This document enhances BGP Open to establish agreement
   of the (peer, customer, provider, internal) relationship of two
   neighboring BGP speakers to enforce appropriate configuration on both
   sides.  Propagated routes are then marked with an iOTC attribute
   according to agreed relationship allowing prevention of route leaks."

The enhanced BGP Open (or BGP Role capability) does not help in 
marking iOTC in the "complex" peering case. 
In that case, the OOB communication is all that is there to rely on. 
The proposed BGP Role capability cannot verify/confirm that unless all 
the per-prefix roles are also conveyed in the enhanced BGP Open message. 
But that is not feasible, right? 

The draft also does not cover all the mismatch conditions:
(1) If the BGP role messages contradict each other – do you drop the session?
(2) What is done if BGP role messages do not contradict each other but they 
contradict with the prior OOB communication, etc.?

Thanks!

Sriram