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

[Robert Raszuk <[e-mail]>]

Hi,

> route policy may be applied on a group of BGP nodes for a set of peers

That is not how the NLRI format is defined. Today it is either single peer
or zero meaning all peers.

There is no provision for receiver groups.

But that's just the tip of the iceberg as indicated in this thread already.

Kind regards,
R.



On Tue, Jul 28, 2020 at 5:53 PM Dongjie (Jimmy) <[e-mail]> wrote:

> Hi Robert,
>
>
>
> Thanks for your example of using wide community within normal BGP prefix
> updates. This could be one use case of wide community.
>
>
>
> Since wide community provides the mechanism to carry matching criteria and
> the actions to be executed on the matched routes, this make it suitable for
> other scenarios, such as dynamic route policy provisioning at different
> granularity, such policy may be carried separately from the BGP prefix
> routes, so that it can be applied to a group of matched routes. Also the
> originator of the policy could be different from the originator of the
> routes.
>
>
>
> The RPD draft proposes to introduce the route policy as a new address
> family, this is to separate the dynamic route policy for optimization
> (which may be temporary) from the base policy carried with the original
> routes, so that the effect of dynamic route policy can be controlled, which
> can also help to reduce the complexity in managing the policy interactions.
>
>
>
> And I’d like to clarify about the possible misunderstanding of “P2P
> configuration”. Based on requirements, route policy may be applied on a
> group of BGP nodes for a set of peers, which also include the case of
> applying to one specific node or one specific peer. Maybe it could be
> clarified further in this document.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Idr [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, July 28, 2020 6:19 PM
> *To:* Zhuangshunwan <[e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>; Ketan Talaulikar (ketant) <ketant=
> [e-mail]>; Huaimo Chen <[e-mail]>;
> Susan Hares <[e-mail]>
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
>
> 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 <[e-mail]>
> 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:[e-mail]]
> *Sent:* Tuesday, July 28, 2020 4:59 PM
> *To:* Zhuangshunwan <[e-mail]>
> *Cc:* Brendon H <[e-mail]>; Huaimo Chen <
> [e-mail]>; idr@ietf. org <[e-mail]>; Ketan
> Talaulikar (ketant) <ketant=[e-mail]>; Susan Hares <
> [e-mail]>
> *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 <[e-mail]>
> 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:[e-mail]] *On Behalf Of *Brendon H
> *Sent:* Tuesday, July 28, 2020 7:42 AM
> *To:* Robert Raszuk <[e-mail]>; Huaimo Chen <
> [e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>; Ketan Talaulikar (ketant) <ketant=
> [e-mail]>; Susan Hares <[e-mail]>
> *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 <[e-mail]> on behalf of Robert Raszuk <
> [e-mail]>
> *Sent:* 28 July 2020 08:02
> *To:* Huaimo Chen <[e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>; Ketan Talaulikar (ketant) <
> ketant=[e-mail]>; Susan Hares <[e-mail]>
> *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 <[e-mail]>
> 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 <[e-mail]> on behalf of Ketan Talaulikar (ketant)
> <ketant=[e-mail]>
> *Sent:* Thursday, July 23, 2020 6:02 AM
> *To:* Robert Raszuk <[e-mail]>; Susan Hares <[e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>
> *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 <[e-mail]> *On Behalf Of *Robert Raszuk
> *Sent:* 17 July 2020 18:38
> *To:* Susan Hares <[e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>
> *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 <[e-mail]> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>