Re: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-optimal-route-reflection-25: (with COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Wed, 16 June 2021 21:28 UTC

Return-Path: <aretana.ietf@gmail.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 DF0A13A2761; Wed, 16 Jun 2021 14:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 i-zfoc0cKYNr; Wed, 16 Jun 2021 14:28:18 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 E69C83A1CA4; Wed, 16 Jun 2021 14:28:17 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id r7so978275edv.12; Wed, 16 Jun 2021 14:28:17 -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; bh=As0eu1qKStasMCg7S1nWIR6EovWQgwWl2EUD0swNVIo=; b=j/fyUMZgKeknXfsEHI5ndQi7BjQTJs2HmeHTwJ7pY79AEhfQqJ/eeT37A5qaSi2tA2 Zg5ZdxnE8CBc39w+3keDLKBxNQo52pOQoZ/Ux/s7LwATY9N2WHaqMzEB3smllkmtyrKd /F92FsOvOZ6pL1aahwZM95JjE7S35q21ss0wg90Tz9UyyhXG003OjpaeF5DQn8NgHLEf kYedj1+9HY9NQNHCchovurQIrbZw8z7vzjm40Wd7kHcTi3QPFTWp2NbbDXEVre99AhLc 0TU36AaSVAtSbcVhntCoCoIFOQiuwMeepzcgUsVkLXzOu6l628Kv9xfxuWJ0aZk6Sn1k b1Yg==
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; bh=As0eu1qKStasMCg7S1nWIR6EovWQgwWl2EUD0swNVIo=; b=t7MAH6HP6YYZP8d7lubl0fbn8+rQCWuLEuCCjs9cx0HUHgxJamKHHnXm9oME66Agdx pow+m1FwehRvY/LCu9Vo7YB+j5+viCQoqY3QjyqOHFMDJ4l0PvlVplC1/UST4hBQ0T73 I9kIv3NMwzu/fu1A7sY5jGEMZjzcvA7Xzr3LwaTQemlV8Td7NNUacjIWLoJ2//KI+ots G5huf28S29Y3NYgFiojXukgyJxHlSXSPgVmzPsHnEGl2oPTPmmrx7gZKpI3PPSNsQazU si9WbrZn8y9uS7xVP1PxciFLYd0CHYzxjfVue44E1lMpzUCt+AhB6Pzl3FCjmXOk6LB4 nfsw==
X-Gm-Message-State: AOAM530xXITZPwcK2xvaDiYRRmuPrhina4nRC8PpsJZB+E2kOc/VTAhU Y0B4cV0MCXjVPwhjLSqe39Ss+anPN0tqvmWxEMA=
X-Google-Smtp-Source: ABdhPJwRan5txwA7v8fp144HkgUEUnB7rH6tUjHTpTQ5jyI6XPfpQoLS4gJf86+M3gKf3nYL//fOeUOsdUTy+P+AG5A=
X-Received: by 2002:a05:6402:1d0c:: with SMTP id dg12mr2092970edb.155.1623878894964; Wed, 16 Jun 2021 14:28:14 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 16 Jun 2021 14:28:14 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAOj+MMEhQ4rXu5Bay9DHUdjkX7Bfr_+3DuYz5n2sLVeTpBOmkg@mail.gmail.com>
References: <162386038468.2054.10058025206181569780@ietfa.amsl.com> <CAOj+MMF+kZYv6Gp9s7xGUkcKR7SQCxZdfQtWnhvaZK1nzBCPGA@mail.gmail.com> <20210616203626.GR11634@kduck.mit.edu> <CAOj+MMEhQ4rXu5Bay9DHUdjkX7Bfr_+3DuYz5n2sLVeTpBOmkg@mail.gmail.com>
MIME-Version: 1.0
Date: Wed, 16 Jun 2021 14:28:14 -0700
Message-ID: <CAMMESsyW9rfcNaN7KCTPUb6WwBLjgrKoJjLq96a8A_Tn8VkbdA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>, Benjamin Kaduk <kaduk@mit.edu>
Cc: Susan Hares <shares@ndzh.com>, idr-chairs <idr-chairs@ietf.org>, draft-ietf-idr-bgp-optimal-route-reflection@ietf.org, John Scudder <jgs@juniper.net>, The IESG <iesg@ietf.org>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b155a005c4e8c4ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WzM9YX5iEB5NyF83z2MgvkeM9J0>
Subject: Re: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-optimal-route-reflection-25: (with COMMENT)
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: Wed, 16 Jun 2021 21:28:23 -0000

Robert:

Hi!


Given the text in §4:

   The achievement of optimal routing between clients of different
   clusters relies upon all route reflectors learning all paths that are
   eligible for consideration.  In order to satisfy this requirement,
   BGP add-path [RFC7911] needs to be deployed between route reflectors.

...making rfc7911 a Normative reference makes sense to me.

Thanks!

Alvaro.

On June 16, 2021 at 5:08:03 PM, Robert Raszuk (robert@raszuk.net) wrote:

Hello Ben & Alvaro,
>
> > Regarding moving referencing of RFC7911 to normative let's observe that
> it
> > may be required only in one specific deployment scenario of using
> multiple
> > clusters in non encapsulating networks for IPv4/IPv6 AFs. It is clearly
> not
> > required for other deployment models of BGP ORR. Therefore I am not sure
> if
> > it deserves the elevated level of referencing in the document. But if the
> > above use is a sufficient reason to treat it as normative reference I
> > personally have no problem moving it.
>
> I'm happy to leave this to the responsible AD; my comment stems from the
> IESG statement at
>
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> that points out that "even references that are relevant only for optional
> protocol features must be classified as normative" (if they would otherwise
> meet the criteria.  Only needed in some deployment scenarios is not quite
> the same as being an optional feature, though, so I think there's still
> some element of judgment needed.


In the case of this work the situation is not really about Add-Paths RFC
being necessary for the proposed enhancement/protocol feature either
mandatory or optional. It is helpful to some Route Reflector deployment
scenarios with or without this extension. ORR only observes that to get
consistent IBGP paths Add-Paths may be used between RR clusters. So could
Diverse-Path technique and in some cases perhaps also consistent controller
based path installation. There can be even more ways to accomplish
consistent path selection pool across clusters.

But as you suggest I think moving RFC7911 to the normative reference should
not be a problem if AD or anyone else finds this appropriate.

I will therefore hold publishing -26 till we get some clarity on this point
from an AD.

Many thx,
Robert