Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-route-reflection-14

"John G. Scudder" <jgs@juniper.net> Fri, 13 October 2017 17:52 UTC

Return-Path: <jgs@juniper.net>
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 1896A1332E3 for <idr@ietfa.amsl.com>; Fri, 13 Oct 2017 10:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level:
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 bt-MDiueEOLO for <idr@ietfa.amsl.com>; Fri, 13 Oct 2017 10:52:00 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0117.outbound.protection.outlook.com [104.47.34.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C281332CA for <idr@ietf.org>; Fri, 13 Oct 2017 10:52:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QJKuuCpsE/tsQGkmsRwVfSJ2htJR6i9MizAXOnoWQY8=; b=Y1F5ZVojuBLLdhgIyMmK4wVu2VDddcIouRe0tMyXyU+RQkCYa28ymPns39D3PRbxzehPCU431fw0s9aSf9RDEiRTE9p5HKgbXSBNrE0KzYKwa+DpAMtE7mqjDSFFGUBVnnjUQkEz0zvnx9gz8uVlf2xEA2z85QR0SxmI0MOmrBQ=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net;
Received: from czamprogna-sslvpn-nc.jnpr.net (66.129.241.14) by SN2PR05MB2512.namprd05.prod.outlook.com (2603:10b6:804:13::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 13 Oct 2017 17:51:59 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <20171009191236.GA72041@Vurt.local>
Date: Fri, 13 Oct 2017 13:51:56 -0400
Cc: Robert Raszuk <robert@raszuk.net>, ytti@ntt.net, Job Snijders <job@ntt.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <474938DA-3319-4AF0-8015-2A7DFA884779@juniper.net>
References: <1F4BD63B-3273-469E-A3C6-4365B56724EA@juniper.net> <20171009081140.qram6b2ubl4y3isj@hanna.meerval.net> <CA+b+ERmVAA8eG3cm8++osKS4OmxiBZ6svhNPj8wC7gnQXWWYdg@mail.gmail.com> <20171009152051.GH34236@Vurt.local> <CA+b+ERnTAxra-G8xbtFAoovyCwpOySAuJx52vG3p5g7AdODK2Q@mail.gmail.com> <20171009191236.GA72041@Vurt.local>
To: idr wg <idr@ietf.org>
X-Mailer: Apple Mail (2.3273)
X-Originating-IP: [66.129.241.14]
X-ClientProxiedBy: SN4PR0501CA0049.namprd05.prod.outlook.com (2603:10b6:803:41::26) To SN2PR05MB2512.namprd05.prod.outlook.com (2603:10b6:804:13::21)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 2a0602fa-2d81-440f-d423-08d512631a7d
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR05MB2512;
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 3:lmhYWTqXWwFH6JHalvbUg7jMZV6uvZz6u1gf8+ABQ36peadqUd8uvUpKTRYBtuVpMD98QtsarWVIiVXgVkifUH60zcAkbroMMpo5fh+a2fUIYPA9ofX9xNQ2g99EedygOBmQhyHEO0x+tWJASm9PSs0jQMzrPk5z8uI1zpZqFhI9TB+osnQL9rC9CIGeP5DjqBKAEMtlOFWlu870+BkjOz2S2qP6prJ29D0FpLf7h3tacMi2R31mgUgYxPthrt5L; 25:fMofOJ1D8lRuvxS3/WcMW1EC4Sh9jG6bRBR+U2+jXJZuMuLc7NImvX7UiVOAMAcmbzD7ThwBUfE2+CmkXsiTpS+5qHz3S81EGnJWABVxQ5mAprsUru5YPBGXs0p+abgpDLb4kX8nVnP1/DN5rQ3d1qBpKVsB89C9S89PfP7nfJXRAijI7GR6e1I/EciVoBCVq2nA90k2dWgORypUwKpQ7xUx5AFoL+RFystHmmTMm4ydMKuYnNwP6GexBbGzOq5ib0rlkSECihhswkV8pBox5JnkmEZV1lCrcIX2e/HHhX0MBlt2Wjx0jEF4wE9LYfMcDhUBi2k0HyJO75rCz+8pbw==; 31:NWJ8M/2WcevkuwUNIYSg26n8lMcCdK5m7EP9KMBxB21SFyTdV4NQdEb5w5Sz2c5a5fl+pa/9eXac3Qrl5/RjO9Rh+sGaYM01GSa827QKnXfH7/UtPehC3IiqmavHGyCFnxcIuaNG5wLcjTB9WCCIEEBko0UBTFqzsyGm1UopVPsm7Jo+EauXpe4vnvkYAEBGJmyffYI2yIl3l7+l0Ei3t4M0qnshsT0iUudrZvGHMX8=
X-MS-TrafficTypeDiagnostic: SN2PR05MB2512:
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 20:UVSL5PswE9yV3jwPmLrmsZAWEcYYSp1y+LEP8pp2k9uziKDeMTkS4U+TFPdWqxNfrcPu2t2PyJ0RSzr+Mj0nekIucqJjj4o3DDj9RJqar9ZoLkejwusqGPqAkzQpeYVUVGqPZeQV3Fz02GchxILvCT3jS4aB5AEoNgL8FyBnPQ6bHcqGJiw4OaYToi/+LJstGC8HZZeRE7GYocmgq7a/Zs6WEzDa5I5pqKIp8nqEJzmsa00iWn0YRK2eDhrR0uAmjROV/gwkJ2ib2KkNbZhX1wIqYzn1JssesAz5MUamp/iwwqW29iVKprLEGquAFZpsTvPdqR0vFhK+Ca2RhBh/2QKoIACxwopTeKgTfjmNZwKVxAq7C2Grim6v3Akeaehn4gaubg41WDMaKo21WA09NIxv3SyPDjwh4lahLdt3RNKyfebpNI/1HWTgt+SIKkIYQvJXJvt5UfQAgJdN4BvzrHVUzOtDFBwQa0G5I4UtmpY0Fi0ZKfd9gMozg513hUhfCQfjjx9Nb9wK+yzAs5vp+kUkdhrrhx5hsvaPUOqInrSNVFfQ2pioKnh/Jm2I0ipLeU3TzK96EUNMX321ZUNVjuqbmYVNFDwt6qgWTK9VrTE=; 4:eg904izFdSTc9Q4UjuDa7ywQsljwIhfswWq1Atk7UkN+opMd37zXAuduzikuqIxYDKIEbWGZ+NcDD+KYa2/ocgcY72kWZyBLH0ZOVCYOiU92UhQvvwbI6j48sraFVZC21opCm8F0AuTS6/U+RtDL4ZUjSPhYj5+DqaS8aOhxZ6/qm4H91K+/1gyyh8pe1OyZ8QwNZ3XF8s7XT+RU6TTQifakjIIViinQeLDF+CjhpjoAF7aPL+IfZhxYSxtaHuc/
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: <SN2PR05MB2512ACF376A9559C90A48A91AA480@SN2PR05MB2512.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR05MB2512; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR05MB2512;
X-Forefront-PRVS: 04599F3534
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(189002)(53754006)(24454002)(377454003)(199003)(53936002)(6666003)(6916009)(50226002)(2950100002)(16526018)(6506006)(5660300001)(54906003)(23726003)(316002)(69596002)(97736004)(6246003)(2906002)(105586002)(68736007)(106356001)(6512007)(3846002)(83716003)(66066001)(101416001)(189998001)(6486002)(6116002)(50466002)(305945005)(7736002)(8746002)(4326008)(8936002)(8676002)(81156014)(53416004)(81166006)(82746002)(478600001)(229853002)(25786009)(93886005)(230783001)(50986999)(76176999)(47776003)(57306001)(33656002)(86362001)(36756003)(53546010)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2512; H:czamprogna-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 23:v8tLDw+nx8bCE99xk6HA4P4EX5krOnGvQnTuzTaNfcxxRxoP1xr/MK4VLgk5D6IsYXi2Eg2pDeLI544Jdi8epBZ5jtW4MH5ajKxrtSlxzopvUkMnAV0VRH8+jTRuM0/WF2OKlO/DsxiWoJqsEZH5QNvIxTD+Z0De9w9opN27JyzhPXYHokplKKTq2kgLvBmgiZzcbR3ulCTh8bS5DpboyQFDLtyagNcU5dc4Z8N0lFnWI26/w2koiak9m5JWQ60u4OTD56M1MZFzdcbomM0xQzUpnJ1ZiKD5eETdV3SuIXc4Uj1HgyDkR65ZojWfLdxe0jMwSRvrtbyR7ZV9bx3d6s9lIz85JeZnnvPH8vxfH/BBQCr8e6Kw6e52NKHwk12yH5TyBSOOKhJwktywM41hLScDctVPLOx2bZ61ruDBiga9SMRUDdGOFFWN/F348IXFMxXIFr5gprUbMaWOXlVI3ioHR0K9Rgt5vhN+3ZZoZYfjUCIgd7rzkPhfItFG9c6ATgxsjOH19qj2wkvfqvKbRP+Je303oEvfrXke9BrkqjuILYrBOw7SBRqHwbmzLIDxdR+BxmEW11DOpHv0mUho8ITVlj6mHS0VPd2AKPVm3aouT6hKHfLP2ZVxNMG8EcyiiveyJaf9ERteX75FQjLGj4QPYYI/hn1O2Vg+RcNZNXTu+Xd65RaXTkVFgNxcpm8odv5GHkVegdoHus79J7k6EgyHze8LfXeFIdD4nVox1tEB6rBt20BhCheWBZq5YM0Z6eRWW8ST5y4T8WzHkLaVAocdHWxaJ1+jMxCGR7+y0uNRr0IKrEOdtCa6/q/GmytmnxTNtLy473ESqwelkg8mAdsLjL14o69dKeDDuO2hzIXwt6i1zRySJVdbcVwXYUsTruq1wBbwUEnZLFeywoXtqQMbVhk8H5ozi5eaa9zghOkMX1G8AAdtG8WM8JqtCYsZhz63Mj+evEdS3wIUl4K2qVn0sS++yBY2mCZd7/+ZuV9h1feQBNFISMTijBvMhvwI34y4py4USNqh6+dQKWnFhqBZqmqZar8Lwu3QfDVfFTebEo68t5utXleFW2ZUgJIuuQj7c+v52JPoJhtzDBshI0BUKL+gS+W+hvcxR+Lf6J3s9LKbtwxv8fGBWiqNuR+ZsGV08CZwKd/cUlF+KN4OhsENWtsk5rBJ6YvxTvtlCxB17xvpe2sdDCxI8ppkszngrNPNhetyZCrvSoC+K0W/KyHAt6qxGfFc8AeDe5O5s04M8uQFVmJEqQqQ0qh1Bhq7sppEOiUtsiu6ljoKdJICY44f1jvqgPNcIFgKlbJsKICvzunSanjj8VpVfVYAhycBr8gYmv+D1wTPmeVWhuWUpi3rhLkIkx6tIL9xdlfiHx4=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 6:ZN5TAfWM6lbMsNQz2S6zPDKklnIoKgHgKQHOU0f3qf7VibyUnmh03FIQ27jG9UK99RlcQiVWmoh1nw8nYP+ZjAIRbNqy/PJBeLORun+bGgLUOn7twQ6ePlLOkDLMdWcRyR+Hu+e7VSimkkd3etgkLTkGLiP548uQ/V+3+OSGNlszCdU02xtlgc4A4UcBMlTfIuPRLrPx0qQR0tAvmNg8TrTcVI2HLNYc9IHEpBQgfeFJnBnadiky8woqWopl6/DDa882CpcUFsYqmweq1/4gVP1awDbsLQF2aUqLo+O4p3v6J9QXnFzzNEgHaf9rtC0szCqujzULMlwN3jOGhD/IaA==; 5:IUYldgSAbEYG9MFRyDfb+8cRT14TeY7rRbboY0JAHeiaphg/FhbTHExNNuhP0is6V833GKaIf1eBYlkY9/LCppccuwsnrQuLU/kyWAtwcsf322qIN5lzclTpRiUCbIMkC4gue5etEKysxNG6fF/5rTyq/HXF2Vn2U+/QfvCF574=; 24:VfwI3u6y/rsVaAmXppnDnAZ5+mKAhSIeLWrLIpzHl27tMzXoucBBwAoQ/TpwVaRkpQNUCOvP1ZjALMDyv8yG4K++Z7vaVqyS8Nui+8tOtAs=; 7:DUOlem4/Kwr5IoA17WQGrqrETDazPjmqxOMsTv5yvoLWyZomRlL9CuW3eerQYBhQ6gjkWw/W6T6KcjEYt7X00FNXH5G53tZCXC+A7PsMaMnS3aovw1p4mYsZU3KNnC4JNsmNcGmnfeSc0kkrGsFVhrg90HM/cVt6VgeOQiyWT9NkWB+DP+lPZam1ahBUY2FLP17D0KneWYnvmynWz/YNkRvNpP76l5nacqIbKDBRtE8=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2017 17:51:59.2059 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2512
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/FP1vn_Fel4phcgcasWxxBw2lo9M>
Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-route-reflection-14
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: Fri, 13 Oct 2017 17:52:03 -0000

Hi All,

It seems to me as though Robert and Job agreed on the proposed text below, or something like it. If so, I suggest the authors update the draft and publish as -15, so the WG knows what we're talking about.

Speaking for myself, I don't object to the proposed clarification but it seems to me this draft isn't strictly speaking the right place for it since it amounts to a correction of an underspecification in RFC 4271. That underspecification affects all BGP implementations, not just ORR. Of course, most implementors "just knew" to do the obviously right thing, but apparently Job has encountered one implementor who didn't. It's tempting to criticize the implementor, but IMO the right target of criticism is the spec. 

Specifically I think the underspecification in RFC 4271 is in 9.1.2.2 (e), the definition of interior cost. 9.1.2.1 is actually quite careful to talk about recursive resolution, but unfortunately that care wasn't extended to talking about the interior cost. (The final "similarly..." sentence in the proposed text is strictly speaking redundant with 9.1.2.1.)

Even though this draft isn't the right place to correct the weakness in RFC 4271, since every BGP implementation should get this right, not just ORR implementations, I don't see harm in doing it here.

--John

> On Oct 9, 2017, at 3:12 PM, Job Snijders <job@ntt.net> wrote:
> 
> On Mon, Oct 09, 2017 at 05:56:44PM +0200, Robert Raszuk wrote:
>>> I think you are overestimating the impact of the proposed change.
>> 
>> It would be helpful to hear from vendors how propagating to BGP an IGP
>> metric in the scenario of N-level of recursion is easy or hard for
>> them.
> 
> I think the number of BGP implementations that can't do BGP to BGP to
> IGP recursion is extremely small, it'll be mostly the implementations
> that don't support the IGP or already operate without RIB.
> 
>>> The fact that they released software without this capacity, implies
>>> draft has ambiguity which causes operational inconsistency in best
>>> path algortihm (with possibility for blackholing).
>> 
>> Ok in such a case I don't see any problem of addressing the ambiguity
>> with the below sentence added to section 4.1:
>> 
>> Current text:
>> 
>>   "In this document we refer to optimal as the decision made during
>>   best path selection at the IGP metric to BGP next hop comparison
>>   step."
>> 
>> New text:
>> 
>>   "In this document we refer to optimal as the decision made during
>>   best path selection at the IGP metric to BGP next hop comparison
>>   step.
>> 
>>   In the scenario of BGP route's next hop resolving via N level
>>   recursion the metric used for given path's comparison (provided
>>   implementation supports it) should be equal to IGP metric of the
>>   final IGP route the N level recursion resolves via. Similarly next
>>   hop reachability validation should be based on the state of such
>>   IGP route."
>> 
>> Would WG and yourself be fine with this change ?
> 
> I think some wordsmithing may be needed to improve the readability. The
> word 'recursion' or 'recursive lookup' should probably be used.
> 
> NEW:
> 
>    """
>    In this document we refer to optimal as the decision made during
>    best path selection at the IGP metric to BGP next hop comparison
>    step.
> 
>    In the scenario where a path's BGP next-hop can only be resolved
>    through multi-level recursion, the metric used for a given path's
>    comparison SHOULD be equal to the IGP metric of the final IGP route
>    the recursive lookup resulted in. Similarly, next-hop reachability
>    validation should be based on the state of such IGP route.
>    """
> 
>> The only problem is what to do if implementation can not propagate
>> such metric .. should the N-level recursive path be less preferred and
>> assumed having max metric in such cases ?
> 
> Good question, 'assuming max metric' will at least prevent certain
> blackholes compared to 'not announcing'. Vendors may want to chip in
> here on what their implementation does. The document will be better off
> if we highlight this problem and make a recommendation (such as 'treat
> as less preferred').
> 
> Kind regards,
> 
> Job