Hello, Thanks a lot for those clarifications ! I am not quite sure they should be put somewhere in the draft, but I have learnt something.
Best regards, Antoine Fressancourt From: Acee Lindem <[email protected]> Sent: jeudi 1 juin 2023 17:19 To: Peter Psenak <[email protected]> Cc: Antoine FRESSANCOURT <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: Intdir telechat review of draft-ietf-lsr-ip-flexalgo-12 On Jun 1, 2023, at 06:54, Peter Psenak <[email protected]<mailto:[email protected]>> wrote: Hi Antoine, thanks for the review, please see my response inline: On 01/06/2023 11:22, Antoine Fressancourt via Datatracker wrote: Reviewer: Antoine Fressancourt Review result: Ready I have reviewed this document as part of the INT area directorate's ongoing effort to review all IETF documents being processed by the IESG. The document, in version 12, is well written. The objectives of the draft are clearly stated, and relate to the requirement stated in RFC 9350 to describe in specific document each extension of Flex-Algorithm beyond SR-MPLS and SRv6 data-planes. The draft's structure is borrowed from RFC 9350 and describes forwarding or operational considerations. In my view, the document is ready to be published. I only have one minor comment that the author might ignore as it may stem from my inexperience with IGP Flex Algorithms. As far as I can tell, the metrics that can be used in flexalgo can be rather dynamic. Given this dynamicity, what is the policy that should be adopted in case the metric for a given prefix is updated very frequently? IGP convergence can take time, and consumes resources on the routers, and I was wondering if there would be some sort of threshold or minimum time before an update is considered. there are three metric types defined in the draft: 1) IGP metric 2) TE metric 3) Min Unidirectional Link Delay First two are static values configured by administrator. Third one could be measured, but the min delay mostly reflects the property of the physical layer and should be semi-constant, unless the physical path changes (e.g. re-routing at the optical layer). RFC8570 that defines the "Min Unidirectional Link Delay" says: "Minimum and maximum delay MUST each be derived in one of the following ways: by taking the lowest and/or highest measured value over a measurement interval or by making use of a filter or other technique to obtain a reasonable representation of a minimum value and a maximum value representative of the interval, with compensation for outliers." RFC8570 also talks about announcement periodicity and announcement suppression to avoid frequent changes in these values. On top of what RFC8570 mentions, IGP implementations have SPF throttling mechanisms to avoid too many calculations, even if some originator advertises these values too frequently. For example, see https://datatracker.ietf.org/doc/rfc8405/ Thanks, Acee thanks, Peter Nits from the Gen-ART review have been addressed in version 12.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
