Hi Jie,
please see the response for one of your questions inline:
On 14/05/2021 09:52, Dongjie (Jimmy) wrote:
Hi authors,
I’ve read the latest version of this document and have the following
comments:
1.Is the generic metric type applicable to applications other than
Flex-Algo? If so, it is better to make this clear in the document, or
perhaps it may be defined separately from the Flex-Algo specific extensions?
2.The “Exclude Minimum Bandwidth” constraint is compared with the
maximum link bandwidth to exclude the links from the computation, it
would be helpful if there is some analysis about how much this can help
in traffic engineering, such as to reduce the congestion or improve the
link utilization. One simple example is, if multiple Flex-Algos use this
constraint to exclude the same set of links, this may increase the
possibility of congestion on the rest of the links?
Perhaps a more general question is, what would be the benefit of
introducing bandwidth attribute into Flex-Algo based distributed path
computation? It is known that bandwidth can be used in centralized
computation for efficient path placement and resource management, can
distributed computation with bandwidth constraint achieve the same, or
is there some advantages compared with centralized computation?
3.With the automatic metric calculation, it could introduce per
Flex-Algo link metric value, while the existing Flex-Algo only refers to
the metric of the link via metric type. Is this the expected behavior?
Will it be further extended to make other link attributes flex-algo
specific?
we need to distinguish between:
a) flex-algo application specific metric (applies to all flex-algos)
b) flex-algo X specific metric
(a) already exists in the form of the ASLA advertisement for delay and
TE-metric. Bandwidth metric will be no different.
(b) there has been no such thing as flex-algo X specific
metric/attribute defined so far. And we are not defining it in this
draft either. The draft defines sub-TLVs for automatic bandwidth metric
calculation. It is the winning FAD for the Flex-Algorithm X that
specifies whether the automatic bandwidth metric calculation is done or
not and it would be rather complicated (certainly possible) to have the
parameters for such calculation being advertised outside of the FAD.
You are right these being part of the FAD may result in the calculated
bandwidth metric being different for each flex-algo on the same link.
The intention was NOT to have the different per algo bandwidth metric
value, rather it was the convenience of reusing the FAD that was the
motivation for the existing encoding.
So to answer your question, we do NOT intend to make any link attributes
per flex-algo number.
thanks,
Peter
4.In the reference bandwidth method, the draft says it simplifies the
management in case the reference bandwidth needs to be changed. Since
the reference bandwidth applies to the metric calculation of all the
links in the flex-algo with the same proportion, it seems the change of
the reference bandwidth will not impact the result of the path
computation in the flex-algo. In which case the reference bandwidth need
to be changed?
Best regards,
Jie
*From:*Lsr [mailto:[email protected]] *On Behalf Of *Acee Lindem (acee)
*Sent:* Thursday, May 13, 2021 5:09 AM
*To:* [email protected]
*Cc:* [email protected]
*Subject:* [Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
Bandwidth, Delay, Metrics and Constraints" -
draft-hegde-lsr-flex-algo-bw-con-02
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
Please indicate your support or objection by May 27^th , 2021.
Authors, please respond to the list indicating whether you are aware of
any IPR that applies to this draft.
Thanks,
Chris and Acee
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
