Re: [Idr] WG Last call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

[Huaimo Chen <[e-mail]>]

Hi Ketan,

    Thank you very much for your three specific comments.
    My responses to them are inline below with [HC].

1. The introduction gives the raison d'etre for this work as
“complex and error prone configuration and maintenance of route policies”.
 Perhaps the authors have the view of network engineers going to individual
routers and operating CLI and while this is true in the real world, we do
now have automation systems that have been (and are being) built to not
only take care of consistent provisioning network-wide but also verify
their successful application. More importantly have the ability to detect
issues/errors and where necessary rollback to a consistent state.
IETF facilitates the same using YANG models
(e.g. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-policy-model/)
and there are other models also out there. These aspects are (still)
not covered or addressed adequately in this proposal.
[HC]: In some cases, it seems that there are lots of route policies
that have been configured on some border nodes of a network domain
and are relatively stable.
For dynamically adjusting traffic based on the network traffic,
we may dynamically add or change some route policies.
Some users seem not like this way (i.e., dynamically adding
or changing some route policies to the stable route policies)
even though they have configuration automation systems (including
YANG models) that can take care of consistency of configurations
network wide, verify their successful application and rollback to
a consistent state after detecting issues/errors in the updated
configurations. They seem like separating the stable route policies
from the ones that are changing dynamically.
In addition, adding or changing some route policies
through a configuration automation system may be slow.
For adjusting some traffic to avoid congestions or get around
congested points, it seems better to use a fast way to apply some
policies. I have updated the related text accordingly.

2. The changes to introduce ordering do address some comments provided
previously, but don’t address the key aspect that it is desirable for
a policy to be considered as “atomic”. If one rule in the middle fails,
the result can be dramatically different. This aspect/ability is not
addressed from my quick reading.
[HC]: It seems that the chance for one rule to fail while applying it
is very low.  A router or controller seems very reliable since there
should be a primary control plane and secondary control plane in the
controller and router.
Even when there is a failure (such as a controller failure) while
applying the rule, it should be recovered through using the existing
BGP mechanisms. When the controller fails, BGP Graceful Restart (GR)
and BGP Long-lived Graceful Restart (LLGR) can be used to let the
router keep the routes from the controller for some time. After the
controller recovers, the router will have all the routes (including
the rule being applied) from the controller. I have added/updated
some related text accordingly.

3. I find the text introduced in
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd-12#section-5.2
to be particularly disconcerting.
[HC]: I have added some connections.

Best Regards,
Huaimo

________________________________
From: Idr <[e-mail]> on behalf of Ketan Talaulikar (ketant) <ketant=[e-mail]>
Sent: Friday, July 30, 2021 10:29 AM
To: Susan Hares <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Idr] WG Last call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)


< fixed the subject line ... just to make sure ... in case WG members thought this was still the IPR call 😉 >



The updates to the draft do not change my position from the previous WGLC – that this is not a good idea to pursue for IDR.

https://mailarchive.ietf.org/arch/msg/idr/MmYyhpKdZIhmh8yywGNrvWYzUNo/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fidr%2FMmYyhpKdZIhmh8yywGNrvWYzUNo%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C242d44b942df4b9e4c8b08d953668b29%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637632522162008738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dY7hjuJngbEmLbX8UPzm9jwd6NEdDKeA6GiHV3m%2FDhY%3D&reserved=0>



I do appreciate that the authors have tried to update the draft to address the several comments provided. However, they do not change the fundamental issues in my opinion.



I will try to point out some specifics and here is the diff between the previous and this WGLC for the benefit of other WG members : https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-rpd-05&url2=draft-ietf-idr-rpd-12<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-idr-rpd-05%26url2%3Ddraft-ietf-idr-rpd-12&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C242d44b942df4b9e4c8b08d953668b29%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637632522162018696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ubTSB9IlxAgcaEO%2FygYJj%2B%2Bl0%2FdjQtH7%2BVzoE%2FNNZSg%3D&reserved=0>



  1.  The introduction gives the raison d'etre for this work as “complex and error prone configuration and maintenance of route policies”. Perhaps the authors have the view of network engineers going to individual routers and operating CLI and while this is true in the real world, we do now have automation systems that have been (and are being) built to not only take care of consistent provisioning network-wide but also verify their successful application. More importantly have the ability to detect issues/errors and where necessary rollback to a consistent state. IETF facilitates the same using YANG models (e.g. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-policy-model/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-policy-model%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C242d44b942df4b9e4c8b08d953668b29%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637632522162018696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aKc1SywChJyS563Em%2FeRKBq1kR3NyU7MjvR2RQKK%2B5U%3D&reserved=0>) and there are other models also out there. These aspects are (still) not covered or addressed adequately in this proposal.



  1.  The changes to introduce ordering do address some comments provided previously, but don’t address the key aspect that it is desirable for a policy to be considered as “atomic”. If one rule in the middle fails, the result can be dramatically different. This aspect/ability is not addressed from my quick reading.



  1.  I find the text introduced in https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd-12#section-5.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd-12%23section-5.2&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C242d44b942df4b9e4c8b08d953668b29%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637632522162018696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cqGzXRMFi4ZUkWyGN7bc%2FawtSAkCnEtrvR7JpDebRYQ%3D&reserved=0> to be particularly disconcerting.





Thanks,

Ketan



From: Idr <[e-mail]> On Behalf Of Susan Hares
Sent: 23 July 2021 22:53
To: [e-mail]
Subject: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)



This begins a 2 week WG last call on draft-ietf-idr-rpd-11.txt.



There is one missing IPR statement from Liang Ou.

Liang should send the IPR statements in response to this WG LC.



The implementation report is at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20impolementations%20<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-rpd%2520impolementations%2520&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C242d44b942df4b9e4c8b08d953668b29%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637632522162028652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LEfda1H9w2EideGilFu3FvPD5Nn8HUNFSDPtlfucrE0%3D&reserved=0>



The two implementations are different implementations from Huawei.



This document describes BGP Extensions for Routing

   Policy Distribution (BGP RPD) to support this.



Please consider in your review of this draft:

1) if this draft is ready for deployment,

2) if the BGP extensions for routing policy distribution

Help deployments of BGP in the Internet.



Cheerily, Susan Hares