Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Robert Raszuk <robert@raszuk.net> Tue, 21 July 2020 09:12 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 E91363A1726 for <idr@ietfa.amsl.com>; Tue, 21 Jul 2020 02:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=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 LuQ-SzwYbdjo for <idr@ietfa.amsl.com>; Tue, 21 Jul 2020 02:12:38 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 EB8F53A1723 for <idr@ietf.org>; Tue, 21 Jul 2020 02:12:37 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id lx13so20943167ejb.4 for <idr@ietf.org>; Tue, 21 Jul 2020 02:12:37 -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=WPW/qDVRNb37V158EiP6iMGXR4X9kUQl9/s7Hwqec/4=; b=Xcln6g5F57yS9pGgudhUqSsIC2Af0EC87YsTIDxmKYZMtlGWalrbD8mWcHmDZA6vwi qeOe0QGYFf0c1e0Nfn5G/b1lI0L92caMdqD3DAoBh6BO3EUnEIox0Lo1TIRPVu/or2kO N3OfOi/RUJfA4xui5jJWjIgHJsGDtYJhjyqN4Vn1GNzIHpdiQKQ1ZKRCE8XEeAjvfnJ2 GWRNKd6IattLQQC0Q845keQ2zyXxdVb9zIENQp1OaKua/P5DQ9wCmLQTJiU2qchNKMTK lHGPay4O/TDgu6ISjQwauMySkGtrN13g2aAsx9TzkgpkW+0TDY3nvEQeDCT1mmRnNNeX aiQQ==
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=WPW/qDVRNb37V158EiP6iMGXR4X9kUQl9/s7Hwqec/4=; b=p8jn1JDfibtTnEfaLWXiBweNC7D2OyHhYOqvRcXr8oKTWHoGayNaiJLKJDKfeMZUZM h515qJt8/fqc7ohm2G6XIYOkfiTdQNxUUcn8UmqrDc+RAMBuxV0Vi5U/rZYTiyMuESWc 8CksCXSBrZmbNBjb2O1xKnhkirfcwJKtzMQPU47sIVIdtu5/Bq/mNVAT3Z/El1fDeqtq RUd8b7XVkd9cPkFWxqxJs2RZGgekbv6GksoO2uUu8vedAh7sfgH3L2AFSjvC/UIimrir tYEPl8kE9rl41Mwr8TO1l6jCtl0bcpP4RRq/NY2QZlqO9vCCMKaMkR9QUJRzLVf+LT6L WuIg==
X-Gm-Message-State: AOAM530WaPIIEM9Q+XUQW72Bal6yUQt9zzhAYxGoukQKTglpNk2t3qWO FEu73HJpb9+z3ynf57QhxobnUTjb08Qf7anfiG4slg==
X-Google-Smtp-Source: ABdhPJwU/gAQ2Kt+aFJlFMUwbEqZSm8fbecg+JoKQAxNqvDVxJabBtPOSDe007f1limQayFJABek2e0jC+hE+XB1pGU=
X-Received: by 2002:a17:906:4f09:: with SMTP id t9mr23761987eju.110.1595322756221; Tue, 21 Jul 2020 02:12:36 -0700 (PDT)
MIME-Version: 1.0
References: <003701d65aa9$689a64d0$39cf2e70$@ndzh.com> <BYAPR11MB32072C364496472F6BB8FBD4C07C0@BYAPR11MB3207.namprd11.prod.outlook.com> <MN2PR13MB3117DB85FAE31F34D6575B41F2780@MN2PR13MB3117.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB3117DB85FAE31F34D6575B41F2780@MN2PR13MB3117.namprd13.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 21 Jul 2020 11:12:26 +0200
Message-ID: <CAOj+MMH34b+KyrthWnhx3hgL8a_9e0ujSe3YN2qUX7sZc5Tnfw@mail.gmail.com>
To: Huaimo Chen <huaimo.chen@futurewei.com>
Cc: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003005ec05aaf00694"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/T51vFssdbM53dIffoKNoJRpcLkc>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
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: Tue, 21 Jul 2020 09:12:41 -0000

SR policies propagation is a config push and should never be done in BGP.
At least it is p2mp. Much better option here is
https://tools.ietf.org/html/rfc5440

Your draft is p2p configuration push which is completely an NMS task.
Please tell me why it can not be done with YANG models ?

Maybe instead of picking up one cherry at a time let's define a new
AFI/SAFI - "BGP NMS AF" and stuff all of the p2p configuration there. At
least when things melt it will be easy to recover by just disabling such AF
and still allow for some routing info to go through ....

Thx,
R.

On Tue, Jul 21, 2020 at 6:00 AM Huaimo Chen <huaimo.chen@futurewei.com>
wrote:

> Hi Jakob,
>
>     Thank you very much for your valuable comments.
>     Our answers/explanations are inline below with prefix [HC].
>
> Best Regards,
> Huaimo on behalf of co-authors
> ------------------------------
> *From:* Idr <idr-bounces@ietf.org> on behalf of Jakob Heitz (jheitz)
> <jheitz=40cisco.com@dmarc.ietf.org>
> *Sent:* Thursday, July 16, 2020 9:01 PM
> *To:* Susan Hares <shares@ndzh.com>om>; idr@ietf.org <idr@ietf.org>
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
> BGP seems the wrong way to distribute routing policy.
>
>
> [HC]: It seems that BGP flow spec has been used widely to distribute
> policies for redirecting the traffic. It seems work well without some
> mechanisms in Netconf. BGP RPD should be similar to BGP flow spec.  BGP SR
> Policy is on the same train.
>
>
> IETF has already defined a way to distribute configuration: Netconf.
>
> Netconf provides needed features that BGP does not have:
>
> - Atomic Transactions:
>
>   If one configuration item fails, they all fail.
>
>   They all either succeed or all fail. There is no partial success.
>
>   Multiple configurations in one transaction are applied at the same time.
>
>    . This avoids non-deterministic transient behavior between application
> of the first policy and the last.
>
> - Feedback:
>
>   BGP is "spray and pray".
>
>   Netconf provides an acknowledgement that the config either failed or was
> applied,
>
>   which then allows the controller to take the next steps with
>
>   reliable information about what configuration exists in the network.
>
> - Persistence:
>
>   If the BGP session were to go down, all the configuration it sent will
> be implicitly withdrawn.
>
>
>
> If another AS would not allow a foreign AS to configure it with netconf,
>
> it would not allow it with RPD either.
>
>
>
> There are already ways in BGP for an AS to signal preference across AS
> boundaries:
>
> Med, AS-path length, communities.
>
>
> [HC]: Netconf can be used to distribute configurations from a controller
> to the devices in a network. BGP RPD as an alternative option, may have
> some advantages in some cases. For example, in the case where BGP as a
> controller, BGP RPD seems more suitable. Using BGP RPD to control/redirect
> the traffic dynamically in real time may be more effective.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Susan Hares
> *Sent:* Wednesday, July 15, 2020 6:11 AM
> *To:* idr@ietf.org
> *Subject:* [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
>
>
>
> This begins a 2 week WG LC on draft-ietf-idr-rpd
>
> from 7/15 to 7/29/2020.  You can obtain this draft at:
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C12cf72daefe0446d5a7908d829ed0a36%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637305445341383523&sdata=3LvgG6xwElOv27jGetqpyk8ftRub%2B%2B4Ui31Yt8wN87A%3D&reserved=0>
>
>
>
> This draft defines a new AFI/SAFI and new atoms
>
> for the Wide Communities.  This WG LC has been delayed
>
> as I waited for a resubmission of the Wide Communities draft.
>
> I had hoped to do these 2 WG LC in parallel.
>
>
>
> I’ve not received the Wide Communities draft, but we will
>
> start this WGLC to provide feedback to the authors.
>
> We may have to run a short follow-up to this WG LC
>
> If there are changes to the Wide Communities draft during
>
> Its WG LC.
>
>
>
> There is an IPR statement on this draft.
>
>
>
> In your responses please answer the following questions:
>
>
>
> 1) Do you feel this draft has an solution that is acceptable
>
>    With the IPR as a WG RFC?
>
>
>
> 2) Do you feel this draft is ready to publish?
>
>
>
> 3) Do you know of implementations of this draft?
>
>
>
> 4) Do you know of deployments of this draft?
>
> If so, is this feature useful in the deploy ments.
>
>
>
> 5) Do you feel that Wide Communities is ready for
>
> Publication?
>
>
>
> Cheerily, Susan Hares
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>