From nobody Wed Jun 16 14:28:25 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 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 In-Reply-To: References: <162386038468.2054.10058025206181569780@ietfa.amsl.com> <20210616203626.GR11634@kduck.mit.edu> MIME-Version: 1.0 Date: Wed, 16 Jun 2021 14:28:14 -0700 Message-ID: To: Robert Raszuk , Benjamin Kaduk Cc: Susan Hares , idr-chairs , draft-ietf-idr-bgp-optimal-route-reflection@ietf.org, John Scudder , The IESG , "idr@ietf. org" Content-Type: multipart/alternative; boundary="000000000000b155a005c4e8c4ee" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 21:28:23 -0000 --000000000000b155a005c4e8c4ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert: Hi! Given the text in =C2=A74: 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 sur= e > if > > it deserves the elevated level of referencing in the document. But if t= he > > 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-r= eferences/ > that points out that "even references that are relevant only for optional > protocol features must be classified as normative" (if they would otherwi= se > 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 --000000000000b155a005c4e8c4ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Robe= rt:

Hi!


= Given the text in =C2=A74:

=C2=A0 =C2=A0The achievement of optimal routing between = clients of different
=C2=A0 =C2=A0clusters r= elies upon all route reflectors learning all paths that are
=C2=A0 =C2=A0eligible for consideration.=C2=A0 In order to = satisfy this requirement,
=C2=A0 =C2=A0BGP a= dd-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 Be= n & Alvaro,

> Regarding moving referencing of RFC7911 to normative let's observe= that it
> may be required only in one specific deployment scenario of using mult= iple
> clusters in non encapsulating networks for IPv4/IPv6 AFs. It is clearl= y not
> required for other deployment models of BGP ORR. Therefore I am not su= re 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<= br> > personally have no problem moving it.

I'm happy to leave this to the responsible AD; my comment stems from th= e
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 optio= nal
protocol features must be classified as normative" (if they would othe= rwise
meet the criteria.=C2=A0 Only needed in some deployment scenarios is not qu= ite
the same as being an optional feature, though, so I think there's still=
some element of judgment needed.

In the=C2= =A0case 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=C2=A0= with=C2=A0or without this extension. ORR only observes that to get consiste= nt IBGP paths Add-Paths may be used between RR clusters. So could Diverse-P= ath technique and in some cases perhaps also consistent controller based pa= th installation. There can be even more ways to accomplish consistent path = selection pool across clusters.=C2=A0

But as you s= uggest I think moving RFC7911 to the normative reference should not be a pr= oblem if AD or anyone else finds this appropriate.=C2=A0

I will therefore=C2=A0hold publishing -26 till we get some clarity o= n this point from an AD.=C2=A0

Many thx,
Robert




=C2=A0
--000000000000b155a005c4e8c4ee--