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

[Huaimo Chen <[e-mail]>]

Hi Ketan,

    Thanks much for your further comments.
    My responses are inline below.

Best Regards,
Huaimo
________________________________
From: Ketan Talaulikar (ketant) <[e-mail]>
Sent: Tuesday, July 28, 2020 12:00 AM
To: Huaimo Chen <[e-mail]>; 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)


Hi Huaimo,



Please check inline below.



From: Huaimo Chen <[e-mail]>
Sent: 28 July 2020 02:27
To: Ketan Talaulikar (ketant) <[e-mail]>; 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)



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.

[KT] You/authors might have missed RFC7606 that talks about BGP error handling. I see that the draft does not even touch upon these aspects. So my concerns only gets compounded.

[HC2]: When Error occurs, there is a bug somewhere. The bug needs to be fixed. Even for the "strongest" action in Error-Handling approaches when Error occurs, "Session reset", it seems acceptable for the customers because the traffic adjusted/redirected may take its old path when the session is down and the route policies for adjusting the traffic are withdrawn.

     *   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.

[KT] What is meant by “processed”? And I am not talking about BGP update processing but how potentially multiple Route Policies for the same peer are going to get handled and applied.

[HC2]: It seems that there is no issue for multiple route policies for the same peer. The multiple route policies for adjusting the traffic are from the same controller, which will make sure they are not conflict.



     *   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.

[KT] Thanks for acknowledging that by picking up this work, the WG is going to open up floodgates for drafts related to Route Policies knobs down the line.

[HC2]: This work seems similar to Flow Spec, which defines match conditions for flows/routes and actions. In Flow Spec, the actions redirect the traffic to a location for monitoring or drop. In the draft, the actions redirect the traffic to less congested path.



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.

[KT] It seems at least some of us have a fundamental disconnect on this topic with the authors/proponents of this draft.



Thanks,

Ketan



Best Regards,

Huaimo

________________________________

From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of Ketan Talaulikar (ketant) <ketant=[e-mail]<mailto:ketant=[e-mail]>>
Sent: Thursday, July 23, 2020 6:02 AM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: idr@ietf. org <[e-mail]<mailto:[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%7C9c1635db34c444dd2d5b08d832aaceff%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315056486063048&sdata=0%2FRDHc2y4J%2BKw386bRPLqCfcgYAG%2B7rmA5Jpkpcq%2BiU%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]<mailto:[e-mail]>> On Behalf Of Robert Raszuk
Sent: 17 July 2020 18:38
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: idr@ietf. org <[e-mail]<mailto:[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]<mailto:[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%7C9c1635db34c444dd2d5b08d832aaceff%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315056486073042&sdata=6HatBziiSqWAMaFzuQaIyuC%2BboGKqbX0j5PeVkE1xMI%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]<mailto:[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%7C9c1635db34c444dd2d5b08d832aaceff%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315056486073042&sdata=7BXe4j%2BiGZ%2Fd6aKMhWBD5xgyU7jQzPZZ9X6xYqDrWCc%3D&reserved=0>