IETF Logo Mail Archive

Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Tue, 07 June 2016 22:09 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 EE19A12D89A; Tue, 7 Jun 2016 15:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 XY9YVtfmODck; Tue, 7 Jun 2016 15:09:01 -0700 (PDT)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0099.outbound.protection.outlook.com [23.103.200.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5630F12D5FC; Tue, 7 Jun 2016 15:09:01 -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=h3n043cocQ6vgJHBfRDQOsffZFL04DBzg4wqtskdKXw=; b=AgrkxIDnAeSNXqcK2Uf/kP5GFzk8K3CSjfFbgohLWKcVw/VQjIz0AkhUbi21nlDgqwMPVBFNUrzoCZA8OWuko/HLlTQ5wjBoU27veSrLLFamuuhq7Qt683XawvXxS/W6PftROWwSQDraeeelRaYC7PAHbsbyp076GPj/sUaWiqk=
Received: from BL2PR09MB1123.namprd09.prod.outlook.com (10.167.102.151) by BL2PR09MB1121.namprd09.prod.outlook.com (10.167.102.149) with Microsoft SMTP Server (TLS) id 15.1.511.8; Tue, 7 Jun 2016 22:08:43 +0000
Received: from BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) by BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) with mapi id 15.01.0511.010; Tue, 7 Jun 2016 22:08:43 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
Thread-Index: AdHAEXYm+R0yr9NBRVeLkrezdS25EQA9XwKQ
Date: Tue, 07 Jun 2016 22:08:43 +0000
Message-ID: <BL2PR09MB11233AF9434057E641967E9E845D0@BL2PR09MB1123.namprd09.prod.outlook.com>
References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com>
In-Reply-To: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov;
x-originating-ip: [129.6.140.122]
x-ms-office365-filtering-correlation-id: c1fb5d25-b0ff-4561-e528-08d38f204a3f
x-microsoft-exchange-diagnostics: 1; BL2PR09MB1121; 5:t44lXflmmqOM8BDMNt+FW7aNnaz66TD48HqPaBfXWgCqsUAFUdl3chNiSWGEt/9Os+YvfLXwhB3m7rT96f/SAa8vfqtIb7WL+yyVw59jpq8iOz/JIBGVCeDsC3lYXy8iACDNreL2pN0QfA6IkLyLBg==; 24:9SUawoYqb25ESYRs5Mhb9V5jdyWMtelXn1jtu0FhhbL9Xc0ZJOj918+jYt57x9zejd9jsM5pEf3E+xNomwyaT54cRnQgTfEQPJguAy2tMaI=; 7:YIaiczMHwVxFrSfIeRhDH6juKOmbCiVolc3k6s1lpSfSNJ7yiT9q+jFCKtRWmfte+UdiaCsQqsc5d7/YyYX42tBGF4LJpG5D9wppIwrKQv2xBZlD10llu5W5LiPWuBmF9vmN81JPkuaoa2i/msmzBsrKMrMIDRqd2d84WdB1vyMlpU+0UTVrH1ZSRGIFSz9fZmBp3ZnxnRm/5PyYS+o0bgXYpUIv5Rum1Df4bndVxJ8=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB1121;
x-microsoft-antispam-prvs: <BL2PR09MB11218AB4AC9FE9925AA0FD31845D0@BL2PR09MB1121.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BL2PR09MB1121; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB1121;
x-forefront-prvs: 09669DB681
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(5423002)(9686002)(230783001)(101416001)(561944003)(5004730100002)(99286002)(86362001)(19580395003)(54356999)(50986999)(76176999)(68736007)(87936001)(5003600100002)(105586002)(790700001)(19625215002)(3846002)(5008740100001)(6116002)(16236675004)(102836003)(76576001)(586003)(66066001)(33656002)(2906002)(4326007)(11100500001)(3280700002)(106356001)(5002640100001)(10400500002)(3660700001)(189998001)(2900100001)(15975445007)(74316001)(2950100001)(81166006)(8936002)(8676002)(81156014)(19300405004)(122556002)(2501003)(92566002)(5001770100001)(97736004)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB1121; H:BL2PR09MB1123.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BL2PR09MB11233AF9434057E641967E9E845D0BL2PR09MB1123namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 22:08:43.5704 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB1121
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BWqiKd5ijzlQXQ2ILfGBVXT1hac>
Cc: "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" <draft-ietf-idr-route-leak-detection-mitigation@ietf.org>, "'John G. Scudder'" <jgs@bgp.nu>
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
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: Tue, 07 Jun 2016 22:09:04 -0000

I do not support WG adoption of the draft in its current form.



I have read the draft.

This draft has two parts: (1) modification of BGP Open to include BGP role,

and (2) a proposal for route leak detection/mitigation/prevention.



I would encourage the first part to be written as a separate draft in itself.

This effort may have broader utility besides assisting with

route leaks solution. Route leak detection-mitigation draft can (should)

refer to the BGP open policy draft, and should

say how the BGP role info can be utilized in the solution.



The above mentioned second part seems to be a compromised subset of

the proposal in the existing WG draft [ietf-idr-route-leak-detection-mitigation].

The bgp-open-policy draft proposes a single OTC flag per update

(as opposed to one flag per AS-hop).

This lacks efficacy as explained with examples in Section 5.5 of

[ietf-idr-route-leak-detection-mitigation] and also in ref [1] noted below.

In contrast, [ietf-idr-route-leak-detection-mitigation] proposes

an RLP flag per AS-hop, which is shown to work well

(i.e. more robust in the presence of errors and partial deployment)

for route leak detection (see Section 5.5 for details).



The IDR and SIDR WGs have discussed the solution mechanisms

over the past three or more years. The exiting WG draft factors in

those discussions and feedback, and also documents the discussions

in detail in Section 5 (design rationale). The bgp-open-policy draft

seems to overlook one key design principle as noted above.



Also, the bgp-open-policy draft mixes up detection and mitigation

into one combined algorithm.

(Mitigation belongs largely in the operator policy space.)

In contrast, [ietf-idr-route-leak-detection-mitigation] describes

the RLP encoding and detection separately.

It leaves the mitigation method entirely to the operator,

while providing only an example of a mitigation policy.

The operator uses the detection algorithm as a tool to

inform their own policy when it comes to mitigation.



Further, the existing WG draft offers a description of a common practice

(followed by major ISPs) for an intra-AS route tagging (see Section 3.2).

This mechanism conveys from ingress to egress routers the peering info

necessary to prevent route leaks that are under control of the AS locally.



Sriram



[1] see slides 5-9 of https://www.ietf.org/proceedings/95/slides/slides-95-idr-13.pdf

v2.23.0 | Report a Bug | By Email