On 01/06/2023 23:58, Nyagudi Musandu Nyagudi wrote:
Question - To ask is not folly: At the time of writing these documents
"Administrator" is not a protocol, could it become a protocol in the
near future?
no matter how it is set it's not something that changes often. Please
understand that we are not introducing any new metric advertisement,
which would not have been advertised prior to flex-algo. We are just
using some of these advertised values for distributed path computations.
They have been used for TE path computations for 20 years.
thanks,
Peter
On Thursday, June 1, 2023 at 06:19:54 PM GMT+3, Acee Lindem
<acee.ietf@xxxxxxxxx> wrote:
On Jun 1, 2023, at 06:54, Peter Psenak <ppsenak@xxxxxxxxx> 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.
--
last-call mailing list
last-call@xxxxxxxx <mailto:last-call@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/last-call
<https://www.ietf.org/mailman/listinfo/last-call>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
