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

[Robert Raszuk <[e-mail]>]

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
>