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

Robert Raszuk <robert@raszuk.net> Wed, 16 June 2021 21:59 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 9A0193A284C for <idr@ietfa.amsl.com>; Wed, 16 Jun 2021 14:59:21 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 5apBh01u6Nrh for <idr@ietfa.amsl.com>; Wed, 16 Jun 2021 14:59:16 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 3673D3A2848 for <idr@ietf.org>; Wed, 16 Jun 2021 14:59:16 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id x24so6737664lfr.10 for <idr@ietf.org>; Wed, 16 Jun 2021 14:59:15 -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=ayRnP0tDlD89GKuv2bymxHOPKaHwCitNaX6OzojLTXs=; b=VAEhipuXzs9vvTgydz4etoSeN7yavrqGAv9XYNtDVyqBSi7/hzjT2tvdO82cbGjAE0 rtRfdaRNjp9+5lot1gXhiMDfWiPzvg+ojO2r0+4rmG/uB9YQTgnHcEYl1qfthIBiAFhg MuJTGfkf9BmB2HAWf/2hpl/8Doq768e+ku6vtMG9Yqpqwr3p6nDleNyMgeg+Bbj3zSHO YEfsJDJXWH51OEqaclnuHNrm4IKUcdaryVaLMYQAFs1n+Cer9fJrLVudsfWpfu4QgB4n J8T8TbUWP/Dzxd+DD+j9VOa9ewml9VRwuXLkK2tVx+c46VxxAu41bLbiaIGjpmtTlDR6 54uQ==
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=ayRnP0tDlD89GKuv2bymxHOPKaHwCitNaX6OzojLTXs=; b=dmcg0v4LNmnZ9P1PHoJl8HeRWO3CLxhLsabxUZvl1vfIXq0e6NdyKYQnQkxHqs/Ncf A/+EGTrN+yfmkwt7qc9WP5IrxyrYGJiKmU61AEi/aQtFAbgPEh/clIgqsPBkpWVIaBoX Q0obXg6jUd3ZyVbx5FxTrr1g8PDvbBjgoOrGu08Ij2XZbUcu6cqYZLuZjLQqKrO+4GKH vftj9rgVYBFULamQ7YWP8k239Lnu4GvKM1f+3PGAKStW8Vada40pwL+eqyW3q4BydUyc nIQbf9hIa5DX+LIym21187y6zyR7GgKfHUctgN7cCO5fRR8hwEHus32KCZB8VjTwITGP Q8KA==
X-Gm-Message-State: AOAM5315XZDksoF9rfBRo1gUjUbTPHSIdBDbN6QQn7JBBJkXEMXuhSmt U9s4512eAF9Iq1YDJ7Z07Pg0JDTM+B+Lqr9YnDcGnA==
X-Google-Smtp-Source: ABdhPJyyCuMHYta/U3AnKaWTkZqBYBsAWwbh5NHxzoo8EAOSWYkFXUDY3ShFEX9Im6MJuuPmwCopr8eoE6ueREKJ+hI=
X-Received: by 2002:ac2:528f:: with SMTP id q15mr1401000lfm.36.1623880753795; Wed, 16 Jun 2021 14:59:13 -0700 (PDT)
MIME-Version: 1.0
References: <162384765726.7334.2926053112859463383@ietfa.amsl.com> <CAOj+MMFupFA_DQrCeduZrS-PT5QtRprKqFvbQEP=Y0FxMdv1WQ@mail.gmail.com> <2125D567-F330-4A30-BD89-37EFD5EFF857@ericsson.com>
In-Reply-To: <2125D567-F330-4A30-BD89-37EFD5EFF857@ericsson.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 16 Jun 2021 23:59:03 +0200
Message-ID: <CAOj+MMGb1vrZ0+QPZ-XLPB-Mm+NsNGaN=asrJ0Mpux71mwRnEQ@mail.gmail.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-idr-bgp-optimal-route-reflection@ietf.org" <draft-ietf-idr-bgp-optimal-route-reflection@ietf.org>, idr-chairs <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, John Scudder <jgs@juniper.net>, Susan Hares <shares@ndzh.com>, Alvaro Retana <aretana.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007ce4c305c4e933c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/syDXzVSq01KmEf9O8tHEKpGo-CM>
Subject: Re: [Idr] Francesca Palombini'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:59:22 -0000

Hello Francesca,

Many thx for the additional comments.

I expended ORR at the first occurrence in the body.

Based on your help it indeed makes sense to mark this spec as updating
RFC4456 as clearly it requires it to exist. If IESG or RFC editor decides
otherwise this marking can be removed, but understanding the motivation I
am putting it in for now.

Kind regards,
Robert





On Wed, Jun 16, 2021 at 11:42 PM Francesca Palombini <
francesca.palombini@ericsson.com> wrote:

> Hi Robert,
>
>
>
> Thanks for the quick answer.
>
>
>
> Re: ORR being expanded in the title: I was hoping to find it expanded
> somewhere in the body of the document as well, as I seem to remember that’s
> part of the RFC Editor style guide, but I might remember wrong, and you’ll
> be able to change that in AUTH48, in case it’s needed.
>
>
>
> Re: updating RFC4456 – I know that “Update” is an ambiguous header, so I
> do not want to bikeshed this: the “updates” header does have a flexible
> meaning, and I just wanted to make sure this had been discussed and decided
> within the community. Since it has, I am fine with it. But just for your
> information, “Update” does not necessarily mean “change and obsolete the
> previously defined spec”. The only meaning I could find is the one defined
> in https://datatracker.ietf.org/doc/html/rfc2223#section-12 which states:
>
>
>
>    Updates
>
>
>
>       To be used as a reference from a new item that cannot be used
>
>       alone (i.e., one that supplements a previous document), to refer
>
>       to the previous document.  The newer publication is a part that
>
>       will supplement or be added on to the existing document; e.g., an
>
>       addendum, or separate, extra information that is to be added to
>
>       the original document.
>
>
>
> I thought this matched well for this doc, which cannot be used alone
> without 4456, and which just adds to the existing document (without
> obsoleting it).
>
>
>
> Anyway, I am fine without it, just wanted to clarify where my comment came
> from.
>
>
>
> Thanks,
> Francesca
>
>
>
> *From: *Robert Raszuk <robert@raszuk.net>
> *Date: *Wednesday, 16 June 2021 at 16:11
> *To: *Francesca Palombini <francesca.palombini@ericsson.com>
> *Cc: *The IESG <iesg@ietf.org>rg>, "
> draft-ietf-idr-bgp-optimal-route-reflection@ietf.org" <
> draft-ietf-idr-bgp-optimal-route-reflection@ietf.org>gt;, idr-chairs <
> idr-chairs@ietf.org>gt;, "idr@ietf. org" <idr@ietf.org>rg>, John Scudder <
> jgs@juniper.net>gt;, Susan Hares <shares@ndzh.com>om>, Alvaro Retana <
> aretana.ietf@gmail.com>
> *Subject: *Re: Francesca Palombini's No Objection on
> draft-ietf-idr-bgp-optimal-route-reflection-25: (with COMMENT)
>
>
>
> Dear Francesca,
>
>
>
> Thank you so much for your review of this document.
>
>
>
> I added most of your suggestions to new version -26 which will be posted
> soon.
>
>
>
> On the other two points which perhaps require further clarification:
>
>
>
> "ORR" is already explained in the title so I removed the hyphen there to
> make it intuitive that this is the abbreviation for Optimal Route
> Reflection.
>
>
>
> As far as updating RFC4456 we have discussed this and the conclusion
> reached is that this spec is not really an update. Reason being is that in
> our understanding update is something that changes the previously defined
> behaviour also in the same time obsoleting it. Here this spec is not
> replacing traditional route reflection. It adds a new method on path
> selection for situations where this is applicable and helpful. It is also
> to be enabled explicitly by configuration.
>
>
>
> The vanilla RFC4456 will continue to operate just fine for those networks
> which deployed reflection in the data path or those AFs (AFI/SAFI) which by
> itself reflect all paths.
>
>
>
> Please kindly let us know if you are ok with the above explanations.
>
>
>
> Kind regards,
>
> Robert
>
>
>
> On Wed, Jun 16, 2021 at 2:47 PM Francesca Palombini via Datatracker <
> noreply@ietf.org> wrote:
>
> Francesca Palombini has entered the following ballot position for
> draft-ietf-idr-bgp-optimal-route-reflection-25: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work on this document. I have a couple of very minor
> comments
> below, and a non blocking question: it seems to me that this document could
> have contained the "updates" header wrt RFC 4456. Was this considered by
> the
> working group?
>
> Francesca
>
> 1. -----
>
> FP: Please expand AS, POP, SPF, IBGP on first use.
>
> 2. -----
>
>    The core of this solution is the ability for an operator to specify
>
> FP: I would suggest adding the name and abbreviation BGP ORR here,
> otherwise it
> comes as a surprise in section 4.
>
>
>