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

Robert Raszuk <robert@raszuk.net> Wed, 16 June 2021 21:30 UTC

Return-Path: <robert@raszuk.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 B25933A2773 for <idr@ietfa.amsl.com>; Wed, 16 Jun 2021 14:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 hABg4U26ZPTh for <idr@ietfa.amsl.com>; Wed, 16 Jun 2021 14:30:21 -0700 (PDT)
Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (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 00FC83A2771 for <idr@ietf.org>; Wed, 16 Jun 2021 14:30:20 -0700 (PDT)
Received: by mail-lj1-f175.google.com with SMTP id s22so5820340ljg.5 for <idr@ietf.org>; Wed, 16 Jun 2021 14:30:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zCBi2ZbHIujcFeIWgS2YbepYRmqCOZySyw8S+nze1rw=; b=McHXMYL6cBva1Din+Wrm44trYodxaHOq/SQLc9oTnnXqUfGMi3POU/u6De32Uk/j3u tqFAwVavYLpCxGOcvQA21mAFeAZz3e4OFCQKI2OQCUbhU1U8qhapKmQu9K1G2C5ZiYn8 JNlfVHrYjJ7DHpuYzQceb2sFpCzM+JXDpF5oGHpKPSbfblfbGrO3/R4/Vlj8qfAFLhZ7 vjLRm6FDzRhU+CplmJmJpbsbu7I2Oy9viQHJvqEDzEYyY5nCDE6e09VhqYcAxLd/EoX1 zCF8PXufoiSn/4vzBv3lTm83KnpkbVWFFfSsJo7PDfxQqxSioo649Cx0xkoVp4be/Ijy gGKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zCBi2ZbHIujcFeIWgS2YbepYRmqCOZySyw8S+nze1rw=; b=JDfrxou3J3wolJmUDSvfxWe+8wu3i5nrF+D1FL4WjVZ+fjViw4F0eBPEbY8hWDBgF2 2seGkoiRXviM+VhqzpCdzwo97Ta+aTUzi09OOVjnGy/sKWAYJkMfGJL3BlRn+KaittcO CMfxkEKNqbTD+wn+G+eZdrh1XNr7EFcn242uefp5O9ZdmFP7MlegiDNtiDetpMXvIHpS a/gcQxE/v1KPNhp0oj1hQLwPmLbt8g6Hz5M03GQTIpVkIIf0eZiU89T/eEnCSvVgYp6d eiv8hXk5pOzJojHjjO/tLJgMZV+5B+DUhQx19ADxW+q6/ZGv6y9DN5tSbVZScKW/G1pJ Nxxg==
X-Gm-Message-State: AOAM531XkFzejTP0F/fRWgjygJ+6phD74ZCgpQgIHsEhtiXn18VATRRG mLPXq/p+3tRp3MJ4xOxQiw11bkQbeNl51P2Zgl1qkQ==
X-Google-Smtp-Source: ABdhPJwMf8fN+p+N0Z+wnVCI4GDX9fufk2viaANSbvXnrc+8yTtDNjy3D9YOEqzKRcRVJcwvBQB2EHMFMGjWuqA0KO8=
X-Received: by 2002:a2e:9bce:: with SMTP id w14mr1586385ljj.321.1623879013184; Wed, 16 Jun 2021 14:30:13 -0700 (PDT)
MIME-Version: 1.0
References: <162386038468.2054.10058025206181569780@ietfa.amsl.com> <CAOj+MMF+kZYv6Gp9s7xGUkcKR7SQCxZdfQtWnhvaZK1nzBCPGA@mail.gmail.com> <20210616203626.GR11634@kduck.mit.edu> <CAOj+MMEhQ4rXu5Bay9DHUdjkX7Bfr_+3DuYz5n2sLVeTpBOmkg@mail.gmail.com> <CAMMESsyW9rfcNaN7KCTPUb6WwBLjgrKoJjLq96a8A_Tn8VkbdA@mail.gmail.com>
In-Reply-To: <CAMMESsyW9rfcNaN7KCTPUb6WwBLjgrKoJjLq96a8A_Tn8VkbdA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 16 Jun 2021 23:30:02 +0200
Message-ID: <CAOj+MMHYfLNaN=VzxS4wW6nN3Lx4=Z_NGwy3LAkVoQSphguGSg@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, 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="000000000000bd4b3d05c4e8cbee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/SB6J_Q9-eVY8Htq0fJRAWE9RMw0>
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:30:26 -0000

Ok - Will update the draft accordingly.

Many thx !
Robert.

On Wed, Jun 16, 2021 at 11:28 PM Alvaro Retana <aretana.ietf@gmail.com>
wrote:

> 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
>
>
>
>
>
>
>