This is more informative as to the risks/impact. Works for me. Thanks. Joe PGP Key : https://www.marcuscom.com/pgp.asc > On Aug 28, 2019, at 22:15, Dhruv Dhody <dhruv.ietf@xxxxxxxxx> wrote: > > Hi Joe, > > On Wed, Aug 28, 2019 at 8:53 PM Joe Clarke (jclarke) <jclarke@xxxxxxxxx> wrote: > >>>> === >>>> >>>> In section 6.6, do you have any more concrete recommendations on a reasonable >>>> limit of LSPs with auto-bandwidth that you have discovered from testing or >>>> operational experience? Providing some data here may prove useful, even if it >>>> is somewhat anecdotal. >>>> >>>> >>> >>> We discussed this and felt reluctance in putting a number down in the >>> RFC, esp when we don't do it for our base published RFCs (ex. such as >>> how many LSPs can be delegated to a PCE). I also checked with at least >>> one vendor and was told that it is quite dependent on the deployment >>> scenario and would let the operator decide. >> >> Maybe not a hard number, but is there any kind of example you could provide for a given scenario that provides clearer guidance on what kind of impact each one of these LSPs would present? >> > > How is this - > > 6.6. Impact On Network Operations > > In order to avoid any unacceptable impact on network operations, an > implementation SHOULD allow a limit to be placed on the number of > LSPs that can be enabled with auto-bandwidth feature. For each LSP > enabled with auto-bandwidth feature there is an extra load on PCC, as > it needs to monitor the traffic and report the calculated bandwidth > to be adjusted to the PCE. The PCE further re-compute paths based on > the requested bandwidth and update the path to the PCC, which in > turns triggers the re-signalling of the path. All these steps adds > extra load and churn in the network and thus operator needs to take > due care while enabling this features on a number of LSPs. > > Thanks! > Dhruv > >> Joe >>
