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 > > > > > > >
- [Idr] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Robert Raszuk
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Robert Raszuk
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Robert Raszuk
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Alvaro Retana
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Nick Hilliard
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Robert Raszuk
- Re: [Idr] Benjamin Kaduk's No Objection on draft-… Alvaro Retana