Re: [Idr] Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Mon, 07 December 2020 12:51 UTC

Return-Path: <daniele.ceccarelli@ericsson.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 3F9D53A138D; Mon, 7 Dec 2020 04:51:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 jqcKFiiN4Orl; Mon, 7 Dec 2020 04:51:12 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2081.outbound.protection.outlook.com [40.107.21.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293B53A0CDC; Mon, 7 Dec 2020 04:51:11 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dnB7tcHsOVxBT6eSgzE8ej737n1xa+jt1armTcIOAA32f5SyGEYUdM5n7tNnCg9oFKUsnaA5gIT+afbSMS+wSJagWXvdgzD2DVqnlrX6EPWpp1nVaaGsfz4P0Kemhj/diXVR8A47+bPKf9vnW3KSjCmwv2qjCTA/spZwiefQz4k9fE6Q7DwXAdO5RQYb3UwsI0q95jipIcgEDuTci8/3IRzAkwnQmRlb5bXuu5hHdqErVem+QGI7lxPSAFIpompjnjaK2aCQmi0ZDBr9xRA/lDSg8aqxC5ea6APJKj96trVcAOfINWVHxA9GtVXhOUZP8k9RNpQKp9nGSvlOBchnhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VAlO7WWGJQdBpdJ+o62Vyc6Dm6Tm5tTSL9hq9Fucy04=; b=JtLHAR0SiKeNCZ2z08kVGY+bZ/eh388gCy4XXbOm9QXc/0EPq7eXSuzEPr2aOQ7cCNjxibB6VK0EkjGzZgFW8Ew0par0YeAcaOizIl+4enLIfO3fi9/ybZAT2YFklng91JnYznS9ij6uakcx/HujHAqg+UVBjt7BJRKcIUGh4lscIYSmFnrZAqhtZ4alp19V1dUmSfUCR3L9HC9qNmkc8ORRc+o9NvKjHsZ7hPze1nizJ87xGhOcTRDcU5g5nVP48vy1O3E7GYmOkR/I5Zq6VbChnU0OgfzXFF3avcKetLzKg1qFCtaDW3vRp7QXUN1geeoZXmn4AmQihmX+TrFZGA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VAlO7WWGJQdBpdJ+o62Vyc6Dm6Tm5tTSL9hq9Fucy04=; b=dpKDmWHmGGaGdF/Io4FDwHztgQigJiewthaBwkWJLh6h8lXu8znqvlOSVTFWecnra15e8Mlx2xFJjCMtUMTTCjdpycdr9oKzXoo5M9a5o7zvkQCg5V+4zEcvER6hXZWRQykqACZuGuPlX7PgPjgpyn1CJMYCOMG2gFN2eBDWUUs=
Received: from HE1PR0701MB2282.eurprd07.prod.outlook.com (2603:10a6:3:2c::25) by HE1PR0702MB3785.eurprd07.prod.outlook.com (2603:10a6:7:80::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.8; Mon, 7 Dec 2020 12:51:08 +0000
Received: from HE1PR0701MB2282.eurprd07.prod.outlook.com ([fe80::18c1:2358:82ab:e3e5]) by HE1PR0701MB2282.eurprd07.prod.outlook.com ([fe80::18c1:2358:82ab:e3e5%11]) with mapi id 15.20.3654.011; Mon, 7 Dec 2020 12:51:08 +0000
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>
CC: "draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org" <draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Thread-Topic: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
Thread-Index: AQHWzJON9JTIoEXOIUeTwL8nrTKjP6nrkpVQ
Date: Mon, 7 Dec 2020 12:51:08 +0000
Message-ID: <HE1PR0701MB22823F29BCA88BE14B56F46FF0CE0@HE1PR0701MB2282.eurprd07.prod.outlook.com>
References: <160733163424.31714.2821566109849202386@ietfa.amsl.com> <27215_1607343702_5FCE1E55_27215_76_1_53C29892C857584299CBF5D05346208A490425B6@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <27215_1607343702_5FCE1E55_27215_76_1_53C29892C857584299CBF5D05346208A490425B6@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [151.81.54.199]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 61f2afbb-380f-4a7e-8546-08d89aaec4bb
x-ms-traffictypediagnostic: HE1PR0702MB3785:
x-microsoft-antispam-prvs: <HE1PR0702MB378557C44B31D0D71F6AB51EF0CE0@HE1PR0702MB3785.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: SQhGdohfxDJscqhGp7IKNuAs9AQB/RSPJl2aeNygVunmTLUCQELJaPyVBtLivNF9Llr36lFryfxq/dqOr2dLNQTtCsbW486/TKsN85q7hEfQb6XZctB17N/K3G+ptPqWWVpgHgl9Uial0fsexXdDv47o9bDCvNPLcMAqhLl+n4vYXue2A/MBCNgKdCR1MI6TiyX6aL9yujSWp0SSenG+gUEq3+Fg9Oee3IAbZ7WQF2m/iJJtnwsHe4X1T2Rf5eO0Hko19Zh/e8UEdQMMaX3+qWCmrwcV21HGxJjKykrE/4mIM8DK5OmqyZg9GTAx88YhT1PgrE/GNt9I3+n8vMIKK6nKi45DFqxPhcb4qlynEFhzBCso97DakmMTDLey4wiX6gJrCLLAVL7FRoM5Z1OhAw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2282.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(346002)(396003)(39860400002)(376002)(4326008)(186003)(86362001)(8936002)(966005)(8676002)(316002)(54906003)(33656002)(52536014)(71200400001)(66556008)(64756008)(26005)(5660300002)(66476007)(83380400001)(9686003)(55016002)(2906002)(76116006)(478600001)(53546011)(66946007)(6506007)(66446008)(6916009)(44832011)(7696005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?cHBUWUdFYWxnM3lZaTRieEFTdzBMa1B4TFNMUmVUQTRsNnlXbStIc2lXMDRt?= =?utf-8?B?aDU0ZGc2K2NaU2tYRUVHdkdwZHZaNSt4Vk9KTGNIWmpacXVpc3IyZTRKdEpx?= =?utf-8?B?b05SUDhFZS9zajE5WElsUkw5SkZCdDN2RjFiV2FUcDUxejZpTE5iTEtFU3lB?= =?utf-8?B?UGNaRmZDMVNqS0lrai9FTW9OUExya28vYXZNUzJoSTYvTDZqZWhZWTVFMlhI?= =?utf-8?B?SUpQNy83WUhtcFJQN0JXVW44TGl3Z24yRmw0RDVYRWVCbVl1Rmd5MytZQ21q?= =?utf-8?B?RDMvSUgzNllSY3hMbHlVcFFTYVZobkRKeHhEaHl6bFBiV1hTdGUwT0JsS0lP?= =?utf-8?B?Ni9TTDNRaDNjMkVmbFFZOWJiMXR6SWZMakw1cXYwVC82K1YrTnY1YlpKa1U2?= =?utf-8?B?NUsvVkVINUNlT25YR1pURFQxV3Q3WFNrbTU2S0R4OHNjcXJYdkFiYkN5bWZj?= =?utf-8?B?VEtwZUppMGQrSnhseU4yUlE1ekdIalc3RjdERG1iUkoxRUxiSnNoYnpGR0Vp?= =?utf-8?B?b0trWFUxYURGNjJwYVMvRmNxajFWLzZ5MlpQN3NITkxGTUU2QlZtakliVHAx?= =?utf-8?B?NmMzRWpHa0lob01reDZRWGoyNFg0emdCUlBNTVZaZUJwRzkyMmRmOWUzTDZX?= =?utf-8?B?eEMvNDBuenVpaUhNUldYN2tRVlVZZEJVRFlIWlBWb2lrR2RROEZKOElEOGxI?= =?utf-8?B?TC84L0k3R2hUM2pKTXIrUCtsaVcvVjY0dzNYampoNmx0VUx0UDhLVHlYMGYw?= =?utf-8?B?ei9oWTRGS3FxOTJ3QlcwZHpLRFNFN2JuRW0veG5iSDk1S0JMNjVsaVUrdHZP?= =?utf-8?B?cHc3TUpQc1dMVXkzTkd1N3AzTkxpUWRSY09UbXptSXl4NE5mY280RWZ6cGhY?= =?utf-8?B?RjdGaVV3dGZUcHhrbFl5cjdxbVVpS1ZyZWJYU2FCaG1JL2prcnRxR0tLTDBP?= =?utf-8?B?OXhpSjd0QlRkdHpvai9BbGk5ZFVsYjJKejdQdGRCY005anhNbDhhSlM2KzBt?= =?utf-8?B?RzMrRHE1U0RBNVBmcFRybjVtb2U2dXlwT0w5S1NNRnRFK0YzNkJaMHZZTDdV?= =?utf-8?B?YmQzZzF1eC9lMDF6VHR6MWdpR056SGwra3dITGpDS2t2a1UydmVqWkIyWCty?= =?utf-8?B?VU45UHU5aUVlbzkxUUlkMFVXTmpoZ2oyUW9VQUgyM0tqWmE0U3FVaGxjcWM2?= =?utf-8?B?OFoxMGNJSnRVOVp2c1JOS2dZVUliWGpqekpSZmd5RVNJcXBxcTFvL3M3M3B5?= =?utf-8?B?OEt1WC8zbnJNMUFlUU9JaVg0TjMvT1RrYS80VkdPUFgzQ1E5c2NtWmI5RTYv?= =?utf-8?Q?WVnorifLvxQfc=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2282.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 61f2afbb-380f-4a7e-8546-08d89aaec4bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2020 12:51:08.6966 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LMtro6K+cx8j8FnowJN6jT1Im1SSicvMyVhzMnuKbLhad5KvLc7baN3PUm3zqUWSlNm3MdZMpdGHKplNwQp/XXkDGGuoWLuaDXPD6x7vVYU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3785
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ozwR4m79acl52z5nVGwbVhYSU9s>
Subject: Re: [Idr] Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 07 Dec 2020 12:51:14 -0000

Hi Bruno,

Please see in line.

BR
Daniele  

-----Original Message-----
From: bruno.decraene@orange.com <bruno.decraene@orange.com> 
Sent: den 7 december 2020 13:22
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Cc: draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org; idr@ietf.org; rtg-dir@ietf.org
Subject: RE: Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21

Daniele,

Thanks for your review and comments.
Please see inline [Bruno]

> From: Daniele Ceccarelli via Datatracker [mailto:noreply@ietf.org]
> Sent: Monday, December 7, 2020 10:01 AM
> To: rtg-dir@ietf.org
> Cc: draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org; 
> idr@ietf.org
> Subject: Rtgdir early review of 
> draft-ietf-idr-bgp-optimal-route-reflection-21
> 
> Reviewer: Daniele Ceccarelli
> Review result: Ready
> 
> The draft has been significantly improved since my previous review (v11).
> Since the draft progressed till v21 i assume the working group found 
> an agreement on the usefulness of the idea. Please see my previous comment:
> 
> "My concern, which is something the working group probably already 
> discussed, is about the complexity and usefulness of the idea. The 
> goal of draft is: "The core of this solution is the ability for an 
> operator to specify on a per route reflector basis or per peer/update 
> group basis or per peer basis the virtual IGP location placement of 
> the route reflector. This enables having a given group of clients 
> receive routes with  optimal distance to the next hops from the 
> position of the configured virtual IGP location.  This also provides 
> for freedom of route reflector location and allows transient or 
> permanent migration of such network control plane function to optimal 
> location.”
> 
> But I understand that there is a number of workarounds and that 
> different paths are already used for redundancy reasons, hence my  
> questions is: is it worth defining a new solution? Is the usage of the 
> actual  mechanisms so disoptimized to require these changes? How many 
> possible paths  are there between the client and the AS border node?"
>
[Bruno] I don't read that you are calling for specific changes in the draft/specification.
[DC] no. I added that I'm fine with the text added in appendix A.

For what it worth, I can offer my personal feedback.
In the networks, there are multiple paths to a given destination/NLRI. BGP Route Reflector are a widely deployed tool but they may introduce non optimal routing in some cases. The typical solution to mitigate is to carefully position those BGP Route Reflectors in the IGP topology. This brings operational costs and inflexibilities during maintenance operations, addition/removal of RR for scaling purpose, moving this control plane function out of data plane/chassis routers in particular when 'virtualizing' them on generic x86 servers which are better suited in term of CPU/memory/power/cooling capability. So yes, I believe that the extension provided in §3.1 [1] is very useful to decouple the physical location of the BGP RR from the logical selection of the so called best routes. I find this a useful flexibility and don't find the cost of this extension high with regards to the benefit.
[1] https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-21#section-3.1

I could say more, but given that this document will eventually reach the IESG 10 years after its initial version, and multiple implementations, I think that the train left the station a while ago.
 
> I see that appendix A has been added with alternative solutions, very good.
> 
> I only found minor comment and nits.
> - Astract: "to choose the best path for their clients standpoint" i 
> guess this should be "From their clients standpoint" - Abstract: 
> "multiple type - multiple types"

[Bruno] Corrected *2. Thanks.

>- Section 3: there are some issues with bullet items

[Bruno] Sorry, could you be more specific? (There are 2*2 bullet items and the issue is not apparent to me).

[DC] i was just suggesting to have something as a bullet, eg. a dash.

> - Section 3: "The
> first change is related to the IGP cost to the BGP Next Hop, which is 
> done in the step e) in the BGP decision process" where is step e) 
> defined? maybe a missing reference? ...further reading the document i 
> find a description of step
> e) in section 3.1. Maybe just saying "as described in section 3.1 " 
> would be enugh. - Section 3.1.

[Bruno] As you found out, this is step 2) of the BGP decision process https://tools.ietf.org/html/rfc4271#section-9.1.2.2

Since the latest version of the draft has more text on this in section 3.1, I would propose:
OLD:
      The first change is related to the IGP cost to the BGP Next Hop,
      which is done in the step e) in the BGP decision process.

NEW:
      The first change, introduced in section 3.1, is related to the IGP cost to the BGP Next Hop,
      in the BGP decision process.


I've also added the reference of the second bullet.
[DC] great. That works.

> Since step e) is modified probably the draft should update RFC 4271?

[Bruno] I don't believe so.
- In the sense that people implementing 4271 but not implementing this document do not need to be aware of this document.
- This document is primarily an extension of BGP Route Reflector [2].  Note that BGP Route Reflector also changed the decision process and did not update 4271.

That been said, I leave this to the AD/IESG.
[DC] indeed. What about compatibility issues with implementations based on old step e)?

[2] https://tools.ietf.org/html/rfc4456
 
> Overall i like the way that the abstract and the introduction have 
> been updated, with the former introducing the solution and the latter 
> well explaining the problem to be solved.

[Bruno] Thanks. Improvements come from review from new eyes. So thank you again for your time, you review and comments.
[DC] you're more than welcome.
--Bruno


 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.