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

Robert Raszuk <robert@raszuk.net> Tue, 28 July 2020 10:19 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 CB05D3A0AB6 for <idr@ietfa.amsl.com>; Tue, 28 Jul 2020 03:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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 47fAje4XbYhY for <idr@ietfa.amsl.com>; Tue, 28 Jul 2020 03:19:05 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 CE9923A0BAA for <idr@ietf.org>; Tue, 28 Jul 2020 03:18:57 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id y10so20112419eje.1 for <idr@ietf.org>; Tue, 28 Jul 2020 03:18:57 -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=3UixJ1kCZHROLKBrvoCbLWdF90Z8vJ5/RDBe6Z2IlUY=; b=TLs7iLOMYXlTfhSuUquwRCaAqwYtT8NYv4MrIolmgYkBVvNM2vB2TsE2K/kaL39wlR 4Zr/oRYy2iTk8FXLom0icpx3Uj41VAG6fCkkh3XNfUocZ+MOp66MOEcYPUCYZTZtDwf+ 8WTD3pEJC4zIWCcWF8ShZqPqgcIrEz2pxCttMWZGGfAvZ9edmtwMhLyyAchtg0wg5ueP s2MPy6deOy59rVnZAcSTZADzGRKxsKnE6FqaO69AZ1ZwfXah4pudm8b6JD3+9hHGc9uJ wtbNmn/5k15741SQYErw3OYCNuHHGE8bDmTOhY8jvfBZRwynXDgym/H0SFP92Sd9yw6/ w1Cw==
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=3UixJ1kCZHROLKBrvoCbLWdF90Z8vJ5/RDBe6Z2IlUY=; b=U/ZE9Myd1ofnzlvoAVmLOGHoof9rJQx8PeIX6m68IJS7x9Tm0EujJ1I2LZ/q+wgT6g zsjddn54n1Eb4Zl7/RtMt7j0RfNZH8lwkNTXwy2FtOtrO1b2IP5ymwJ8WtgzOLZ6YKdL kNKbLkvvZ2YfewqcYW4eL8RIeO7jtjoqoZGMn5gMyz2QI4VZimog4pzhSqBl29SYuZ91 0iEPyljMnO3SLs4as3RNs9eSNpv2Fb1Kcog1JbwCS58OsGj8ofI6sEkgEeUZcPZOzo5F xEG7LUa2g/IZm9JLW0+huj9wSveHi8pNNTNF6E+9JSnoKg2HKnGOiMz3/LJq0MjaFkPr L+YQ==
X-Gm-Message-State: AOAM531cSLVRH+qR9QF5VrlZbGLe3u3N/JLflB3CIL9NXRrwDI1MU8yf u949S+RRUsS43aZSdn8maEsmd2Yz6YpEhIpEiqt6vA==
X-Google-Smtp-Source: ABdhPJy7b8vDnoN+uId/3m49kg4MdxdIiz0wG0kA66qE0k1G77UsGHtPlEtPFkK8ljvktu9WEFcNnzT1+NkbePtdq9Q=
X-Received: by 2002:a17:906:3a04:: with SMTP id z4mr24123258eje.441.1595931536080; Tue, 28 Jul 2020 03:18:56 -0700 (PDT)
MIME-Version: 1.0
References: <003701d65aa9$689a64d0$39cf2e70$@ndzh.com> <CAOj+MMGG6usHpQrn020LwWd7obt8PRPk9oii1drk0UPhyG5_gw@mail.gmail.com> <MW3PR11MB457041054724225FB0DEB25DC1760@MW3PR11MB4570.namprd11.prod.outlook.com> <MN2PR13MB3117CEF5726D2711D21C97BBF2720@MN2PR13MB3117.namprd13.prod.outlook.com> <CAOj+MMGZPi16FUSwn4N4q23RLhDtCmYbSjm6_P0K5OJ3KnZinQ@mail.gmail.com> <PS1PR06MB28075D03037399E557A93163A4720@PS1PR06MB2807.apcprd06.prod.outlook.com> <c32cd36d681d48dbb008b69fcb544db2@huawei.com> <CAOj+MMEuPSp6EF2HsGoX_8myrNW1qmRZj-Ukh0i7sKxtX7RYuw@mail.gmail.com> <634358332cca46ac9bddacef4cdc39da@huawei.com>
In-Reply-To: <634358332cca46ac9bddacef4cdc39da@huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 28 Jul 2020 12:18:46 +0200
Message-ID: <CAOj+MMFsxOawm1jd+ZTtCBHuBuiaSGUhGs_eo8j7HM4QiUB8og@mail.gmail.com>
To: Zhuangshunwan <zhuangshunwan@huawei.com>
Cc: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, Huaimo Chen <huaimo.chen@futurewei.com>, Susan Hares <shares@ndzh.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004b599e05ab7dc45c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BE-kuIyQuU8MM6UytNyV_jIV2U8>
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, 28 Jul 2020 10:19:18 -0000

Hello,

> I have one question for your per-prefix use cases: How do you set
Widecommunity for prefixes?

In pretty much exactly the same way today standard or extended or large
communities are being used.

Say on PE1 you are sourcing /24. However for some reasons you would like to
advertise it to your upstream ISP1 with AS-PATH X and to ISP2 with AS-PATH
X X X X as the origin ASN.

So you attach to the update advertised from PE1 the below wide community
which when parsed by the egress to ISP2 will do the actual prepend.

3 <https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02#section-3>.
Example

   Customer of the source AS number 100 requests to execute AS_PATH
   prepend 4 times when advertising the prefixes to AS number 2424.  We
   will use the following community assigned on ingress or at the prefix
   origination.

   PREPEND N TIMES TO AS
       Type: 0x0001                S = 0x00000064 (dec 100)
       F = 0x80                    C = 0x00000000
       H = 0x00                    T = 0x00000978 (dec 2424)
       L = 0x001D (dec 29 octets)  E = none
       R = IANA assigned           P = 0x04 (dec 4)

Thx,
R.








On Tue, Jul 28, 2020 at 12:06 PM Zhuangshunwan <zhuangshunwan@huawei.com>
wrote:

>
>
> Hi Robert,
>
>
>
> Thank you for sharing the well-designed use cases of WideCommunity!  We
> have learned your excellent draft and have benefited greatly from it.
> https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02
>
>
>
> We believe that the use cases are not limited to the above. ISP' route
> policies can be classified into static policies and dynamic policies.
> Especially, those ISPs who are managing IGWs and POPs often have to modify
> route policies on devices with great care. A suitable tool should be found
> for dynamic policies management.
>
> Widecommunity is suitable for carrying route policies, so the RPD solution
> is proposed. In fact, the RPD solution is triggered by a large number of
> customer requirements.
>
>
>
> I have one question for your per-prefix use cases: How do you set
> Widecommunity for prefixes?
>
>
>
> Thanks,
>
> Shunwan
>
>
>
>
>
> *From:* Robert Raszuk [mailto:robert@raszuk.net]
> *Sent:* Tuesday, July 28, 2020 4:59 PM
> *To:* Zhuangshunwan <zhuangshunwan@huawei.com>
> *Cc:* Brendon H <brendonholm@outlook.com>om>; Huaimo Chen <
> huaimo.chen@futurewei.com>gt;; idr@ietf. org <idr@ietf.org>rg>; Ketan
> Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>rg>; Susan Hares <
> shares@ndzh.com>
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
>
> Dear Shunwan,
>
>
>
> On the point of wide communities they are indeed designed to automate
> limited policy propagation within the AS and beyond.
>
>
>
> But they travel along with the prefix from prefix originator or ingress to
> a domain.
>
>
>
> It was never the intention of wide community authors to use them as config
> snippets containers to be sent p2p from controller to a router.
>
>
>
> To summarize, if you implement wide communities you can use them along
> with the prefixes to instruct the other side of the domain how to advertise
> your routes. You do not need new SAFI for it.
>
>
>
> Many thx,
>
> R.
>
>
>
> On Tue, Jul 28, 2020 at 2:13 AM Zhuangshunwan <zhuangshunwan@huawei.com>
> wrote:
>
> Hi all,
>
>
>
> Thanks for your review and comments!
>
>
>
> If we believe that wide community is an acceptable solution, then we will
> realize that RPD is a good use case to push the wide community forward.
>
>
>
> RPD = New SAFI + wide community, and it is implemented in one
> administrator domain.
>
> RPD can implement dynamic routing policy management per peer, per node,
> and per administrator domain.
>
> And it can apply some optimization operations on the existing network.
> When the optimization operations are canceled, the network can return to
> the original running status.
>
>
>
> Best regards,
>
> Shunwan
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Brendon H
> *Sent:* Tuesday, July 28, 2020 7:42 AM
> *To:* Robert Raszuk <robert@raszuk.net>et>; Huaimo Chen <
> huaimo.chen@futurewei.com>
> *Cc:* idr@ietf. org <idr@ietf.org>rg>; Ketan Talaulikar (ketant) <ketant=
> 40cisco.com@dmarc.ietf.org>gt;; Susan Hares <shares@ndzh.com>
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
>
>
>
> sorry i've come in late on this "hot" topic, but after reviewing all the
> information.
>
> i too agree with Roberts answer.
>
>
>
> With regard to the questions posed by Susan.
>
>
>
> Ad 1) No.
>
> Ad 2) No.
>
> Ad 3) No.
>
> Ad 4) No.
>
> Ad 5) Yes.
>
>
>
>
>
> kind regards,
>
>
>
> Brendon
>
>
>
>
>
> Sent from Outlook <http://aka.ms/weboutlook>
> ------------------------------
>
> *From:* Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <
> robert@raszuk.net>
> *Sent:* 28 July 2020 08:02
> *To:* Huaimo Chen <huaimo.chen@futurewei.com>
> *Cc:* idr@ietf. org <idr@ietf.org>rg>; Ketan Talaulikar (ketant) <
> ketant=40cisco.com@dmarc.ietf.org>gt;; Susan Hares <shares@ndzh.com>
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
>
>
>
> > [HC]: Yang model seems mainly used in relatively static or stable
> configurations.
>
>
>
> Well that's a problem with the "user" or bad habits not with the YANG
> model itself.
>
>
>
> Nothing stops to use config push as dynamically as required to network
> elements.
>
>
>
> Best,
>
> Robert.
>
>
>
>
>
> On Mon, Jul 27, 2020 at 10:57 PM Huaimo Chen <huaimo.chen@futurewei.com>
> wrote:
>
> Hi Ketan,
>
>
>
>     Thanks much for your comments.
>
>     My answers/explanations are inline below with prefix [HC].
>
>
>
> >Some more/other comments on why I believe this draft is not a good idea:
>
>
>
>    - How does the controller or provisioning entity know the status of
>       the Route Policy provisioning on the target router. Even that it was
>       successfully propagated to it and installed on it?
>
> [HC]:  It seems that BGP protocols guarantees the BGP UPDATE with the
> route policy reaches the target router. When a BGP speaker as a controller
> sends a BGP UPDATE to a peer, there is no need for the ack from the peer
> about whether it is received, processed, and installed. The controller is
> monitoring the traffic of the network almost in real time, and adjusting
> the traffic dynamically almost in real time... The former gets the status
> of the network regarding to the traffic.
>
>
>    - Seems like one can have multiple policies advertised for a single
>       peer/neighbor? How would they be handled?
>
> [HC]: For multiple policies advertised to a single peer/neighbor, they are
> processed one by one by the peer/neighbor..
>
>
>    - The draft has support for IPv4 and IPv6 prefix list and AS regex.
>       What other route policy tools does the WG expect to extend in further
>       drafts? Perhaps we end up with yet another boatload of extension drafts for
>       BGP for RPD?
>
> [HC]: It seems that the current draft defines a small set of extensions (6
> sub TLVs), which is enough to support adjusting the traffic dynamically in
> the live networks. If there are some new requirements in the future, the
> extensions would be small too.
>
>
>
> We have Route Policy yang model defined at the IETF for provisioning of
> route policies that provide better and more comprehensive solution than the
> proposal in this document. That approach is also very robust from
> operational perspective. We don’t need to be putting this into BGP protocol.
>
> [HC]: Yang model seems mainly used in relatively static or stable
> configurations. For frequently changing route policies, the solution
> proposed in the draft is more suitable. It makes the operations and
> maintenance on the network simpler. For example, in one metro area network
> without using the solution in the draft, planning and implementing an
> adjustment/redirection of a service traffic takes days. After the solution
> in the draft is deployed in the network with a controller NCE, this takes
> just minutes instead of days.
>
>
>
> Best Regards,
>
> Huaimo
> ------------------------------
>
> *From:* Idr <idr-bounces@ietf.org> on behalf of Ketan Talaulikar (ketant)
> <ketant=40cisco.com@dmarc.ietf.org>
> *Sent:* Thursday, July 23, 2020 6:02 AM
> *To:* Robert Raszuk <robert@raszuk.net>et>; Susan Hares <shares@ndzh.com>
> *Cc:* idr@ietf. org <idr@ietf.org>
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
>
> +1 and I also agree on Jakob’s comments/discussion on a parallel thread.
>
>
>
> The individual version of this draft was called draft-li-idr-flowspec-rpd.
> When it came up for WG adoption, perhaps most people thought it was yet
> another Flowspec extension and did not have a close look at it.
>
>
>
> The draft got adopted in Nov 2019 and since then, there has hardly been
> any change for it (other than IANA allocations update) :
> https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-rpd-00&url2=draft-ietf-idr-rpd-05
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-idr-rpd-00%26url2%3Ddraft-ietf-idr-rpd-05&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C28cc9cc452284af4ab3508d82eef9d08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310953981956964&sdata=vUgOeTbdLbvoAWIi17vzORiS8UxREO4JoanDDuuGodM%3D&reserved=0>
>
>
>
> I am not sure if this document has received sufficient review and inputs
> from the WG over the recent 9 months of its life as a WG document. Those
> provided by Robert previously seem not to have been incorporated?
>
>
>
> Not sure if I missed implementation reports or some operator feedback on
> this.
>
>
>
> Some more/other comments on why I believe this draft is not a good idea:
>
>
>
>    - How does the controller or provisioning entity know the status of
>    the Route Policy provisioning on the target router. Even that it was
>    successfully propagated to it and installed on it?
>    - Seems like one can have multiple policies advertised for a single
>    peer/neighbor? How would they be handled?
>    - The draft has support for IPv4 and IPv6 prefix list and AS regex.
>    What other route policy tools does the WG expect to extend in further
>    drafts? Perhaps we end up with yet another boatload of extension drafts for
>    BGP for RPD?
>
>
>
> We have Route Policy yang model defined at the IETF for provisioning of
> route policies that provide better and more comprehensive solution than the
> proposal in this document. That approach is also very robust from
> operational perspective. We don’t need to be putting this into BGP protocol.
>
>
>
> In summary, my suggestion would also be not proceed further on this
> document.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Robert Raszuk
> *Sent:* 17 July 2020 18:38
> *To:* Susan Hares <shares@ndzh.com>
> *Cc:* idr@ietf. org <idr@ietf.org>
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
>
> Dear IDR WG,
>
>
>
> As discussed previously on the list I strongly object to proceed with this
> draft any further.
>
>
>
> While I am as others quite sceptical about distributing more configuration
> over BGP this can be said to be debatable especially for p2mp applications.
>
>
>
> However including peer's IP address in the NLRI to which given policy
> applies goes completely AGAINST BGP spray principle of p2mp
> information distribution. Adding such extension to BGP can only deteriorate
> the protocol further. It is not a fit in p2mp protocol to by definition use
> it as p2p transport channel.
>
>
>
> The prefix 0 which is in the draft is not the solution to the above
> problem...
>
>
>
> Moreover wide community ATOM also can already contain that peer's address
> so placing it in the NLRI of MP_REACH is not needed at all.
>
>
>
> To the specific questions asked:
>
>
>
> Ad 1) No.
>
> Ad 2) No.
>
> Ad 3) No..
>
> Ad 4) No.
>
> Ad 5) Yes.
>
>
>
> Kind regards,
>
> R.
>
>
>
>
>
> On Wed, Jul 15, 2020 at 3:11 PM Susan Hares <shares@ndzh.com> wrote:
>
> 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%7C28cc9cc452284af4ab3508d82eef9d08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310953981966953&sdata=te9utkoi5bJl%2BT167KdWJQ%2BHYXaOaogxnvPQZLvbbWI%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
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C28cc9cc452284af4ab3508d82eef9d08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310953981966953&sdata=uA9je9D95WX4sCUMQXWMpxWkKPo%2FbZY%2F1OiVNQKeggM%3D&reserved=0>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>