From nobody Mon May 24 09:07:16 2021 Return-Path: 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 66CD33A2D82; Mon, 24 May 2021 09:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vf-hW9xaybXF; Mon, 24 May 2021 09:07:13 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDAC3A2D7A; Mon, 24 May 2021 09:07:12 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id lz27so42630082ejb.11; Mon, 24 May 2021 09:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=DAdwy/T9jnmWwDWwkRWkVntXe5PrH4FWubsFmhES+ZE=; b=sEGmIa75lbv2Mb/UAAUnOOBbodXyh1BrTcYX/zRwZ+xbzsmJ0YtGOM6pHnLsUwxXwT CCqh/OJIcyEpkO5+VtRyqsQgXAoJibwMOco5EvoHVgWNQScoYX6Tv2+iuSOV8hvAjipc wx95WfycsPicZ0dyGbMVc4XAdDmEE3eaSVYtwcW8fnLOCXW+i6W48bBx8hx89FX/EzAz 9lia1YylMIzyhvVj3M8ulodoDmwyNtMDhRROJ5K70Jh969a1w+SX201Kw9VEp0UJtO4b jnh7J8PgLkuIKVGIjyNRn3y3Q3LF3H1APXnqiDWEVAnHpqQYR2YxyReDGVO79GPMFGEC yhBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=DAdwy/T9jnmWwDWwkRWkVntXe5PrH4FWubsFmhES+ZE=; b=PafNsQgV1wWzRK8jqo3/NIXUH1Pd7GmzhOpB2HbzmKPoAYSBmuQKJ1jkxiMTzaBIrx PcWfdR4F5onsLrUTlORK2E/bchunWETF7T1q6yMnmWsTX2qIPg47XAAYQ/2J0R2o/WIl rO7XnV153nYC8zMht4VmGG1TFlOSkpAXulMP1lwRtkV5YW6xLxvcPnM03vdAVtGeb42y QPA5lfbFRYosGdrDE0zZqEgN0zJ+FqQHpU63Nl0AyARP0Q17blXvay3zlTB2Vqd6NaRg 82LB+gFbMSiSu28QoTjy2QQqUL0I9z0OV47isFAgPB0xz9HCw7cDEL/rqRPAEIes7yAK P9RQ== X-Gm-Message-State: AOAM531LNGs4U03hG5+6G8JDmplR11AF6Pz51ei1MwHlBw+0NlxcKK14 scXLwLYHhhYeZFkiniYoi8P1yKi8ggx+K96IRNc= X-Google-Smtp-Source: ABdhPJztDD1g77E1mwHr6uKDgVTpwQleimu1rBYhe04A7f2lQtP5+Ly8iHqjcOAz5bNGTnCfTl1ZtH49X0wVVNDGA34= X-Received: by 2002:a17:906:4714:: with SMTP id y20mr11956847ejq.235.1621872428411; Mon, 24 May 2021 09:07:08 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 24 May 2021 09:07:07 -0700 From: Alvaro Retana In-Reply-To: References: <879_1620810145_609B99A1_879_373_1_53C29892C857584299CBF5D05346208A4CD9C11E@OPEXCAUBM43.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Date: Mon, 24 May 2021 09:07:07 -0700 Message-ID: To: Robert Raszuk Cc: Susan Hares , "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-optimal-route-reflection@ietf.org" , Bruno Decraene , "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 16:07:15 -0000 On May 22, 2021 at 7:43:42 AM, Robert Raszuk wrote: Robert: Hi! > Hi Alvaro, > > Few comments on your comments .... > > > What I meant is: when/why would an operator select to anchor the > > logical location based on a peer...or peer-group... I understand the > > load considerations, but I'm looking for advantages/disadvantages > > related to the point of view (assuming the platform can handle either > > choice). As you say in the abstract, the precision requirements are > > different -- but they are not explained. BTW, the new text in =C2=A76 > > doesn't address this question either. > > > > I'm looking for something along the lines of: > > > > Selecting to configure an IGP location per peer has the highest precisi= on > > as each peer can be associated with their ideal IGP location. However, > > doing so may have an impact on the performance (as explained above). Us= ing > > an IGP location per peer-group implies a loss of precision, but reduces= the > > impact on the performance of the route reflector. If peer-groups are > > configured taking into account the location of the route reflector clie= nts, > > and not just the policy, the impact of considering a non-optimal indivi= dual > > IGP location for each peer can be reduced. Similarly, if an IGP locatio= n > > is selected for the whole routing instance... > > > Well per peer-group or per peer was something added to the draft more for > convenience than anything else. If we were to be precise dynamic update > groups should also be listed. > > The point however is that selecting a set of peers which may share IGP > proximity from the perspective of path selection is essentially orthogona= l > to all of the above. > > I am not sure if this is too late in the process but I would suggest to j= ust > state in the draft "set of peers" and how they are grouped in the given > implementation is out of scope. > > For example I may group peers just based on the fact that I am doing some > policy on IBGP paths (say for vpnv4 routes as example). In such a case th= is > may be completely orthogonal to ORR objective. > > So some smart implementations may build automated grouping and all operat= or > needs to enter is delta IGP metric between peers which are allowed to get > auto grouped. All this is fine -- I don't disagree with anything. =C2=A0My point is not about selecting the peers, or how an implementation may group peers or not. My point is about the precision requirements mentioned in the abstract. =C2=A0In the general case, assigning an IGP location per-peer is more precise than doing it per group (again, regardless of how that group was determined). I think we're talking about related but different things. :-) > > How is a "node in the IGP topology" identified? > > > > I'm not asking how to configure it (you declare it out of scope later > > on -- which is ok). I'm asking what it is? How is it represented? I > > guess that a "node in the IGP topology" would be identified by it's > > router-id/system-id -- is that the expectation? > > > Is this really needed ? > > The reason why this is left out was to avoid limitations for the implemen= tation. Read the rest of my comments... ;-) Sure, that's ok. =C2=A0At least please mention an example. Thanks! Alvaro.