Hey Tony,
I think there are few things to observe here.
1.
It very much depends how one is to use Flex-Algo topologies. If you attempt
to use it as solid fixed topology for some applications I would be very
cautious not to create such topology with dynamic constraints. Not only
worrying about
the pesky operational issue of those computations to suddenly partition the
graph (if used with dynamic resource updates) or otherwise pile everything
on the same link that led to RFC5120 being built the way it is. It is one
thing to get from RSVP-TE a "no resources to get there" indication and
Hi Robert,
I have similar question as yours: whether the proposed mechanism is based on
static or dynamic bandwidth/latency metric?
If static, it is easy for Flex-Algo based distributed computation, while the
result may not be that helpful, as Tony said, all traffic may be steered to the
same
In ol’ good RSVP-TE days we already used “severity/relevance indicator” to
decide whether changes in link attributes (BW/etc) are significant enough and
should be propagated in into TED and trigger re-optimization/rerouting, this is
no different, define your threshold for a trigger.
Note -
Robert,
> Constructing arbitrary topologies with bw constrain is useful work. For
> example I want to create a topology without links of the capacity less then 1
> Gbps. All cool. Of course if I have a case where two nodes have 10 L3 1Gbps
> links nicely doing ECMP I will not include those
dyanmic queue lengths are still poor indicators of delay (in routing
network wide sense @ realistic routing flood/processing resolution),
nothing changed much since 1980 AFAIK
https://www.cs.yale.edu/homes/lans/readings/routing/mcquillan-darpa_routing-1980.pdf
delay/jitter can be talked about
Hi Tony,
Constructing arbitrary topologies with bw constrain is useful work. For
example I want to create a topology without links of the capacity less then
1 Gbps. All cool. Of course if I have a case where two nodes have 10 L3
1Gbps links nicely doing ECMP I will not include those which may be
Hi William, Gyan, Robert, Tony, et. al.,
Please permit me to wax a bit philosophic here.
William is exactly correct that the goal is not to make FlexAlgo deal with
reservations like RSVP does. Without some kind of setup protocol or global
computation, that’s simply not possible. Moreover
Hi Yali,
Thank you for the clarification. Yes, ok, that then suggests that MFI is
simply a way to partition flooding.
I’m still missing out on the motivation for doing this. What is the benefit of
having some data take one flooding path and other data take another flooding
path? Since all
On Sat, Feb 27, 2021 at 2:56 AM Tony Li wrote:
>
> Hi William & co-authors,
>
> Thank you for your contribution. It’s definitely interesting. As bandwidth
> management is one area where FlexAlgo lags legacy traffic engineering, this
> is definitely one small step in the right direction.
>
> But
Hi Wiliam,
I get yr point on bw. I was not saying to make any changes in the draft on
this. I was more hinting that perhaps deployment scenarios could better
articulate pros and cons of use of such static bw parameter.
Regarding the delay - Oh so the delay is a dynamic variable here ? I was
Hi Gyan,
This draft aims to provide the protocol constructs to define a flex-algorithm
which is suitable for sending high bandwidth traffic. Flex-Algo is a very
useful feature for network consolidation use-cases which requires different
metric-types for SPF. We are trying introduce the
Hi Robert,
Thanks for your comments.
Currently there are customers who deploy separate networks, of which one could
be assigned metrics relative to the interface bandwidths, while other could be
based on other parameters like latency, etc. Flex-Algo which facilitates
different metric-types
Hi Peter,
Many thanks for your feedback. First of all, I'm sorry for the confusion I had
caused you from my previous misunderstanding.
And I want to clarify that a single and common LSDB is shared by all MFIs.
Best,
Yali
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Hi Robert,
Thanks for your comments. But one process N threads or N processes, which is
indeed a implementation not a protocol. Hence, we do not discuss this problem
in this draft.
I fully agree with Gyan. MFIs share a common adjacencies, and a single LSDB.
And each MFI can have its own
Hi Acee,
Many thanks for your feedback and questions. Please see inline >Yali.
-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, February 26, 2021 9:04 PM
To: wangyali ; lsr@ietf.org
Cc: Huzhibo ; Aijun Wang ; Tianran
Zhou
Subject: Re: [Lsr] New
Hi Tony,
First of all, I'm sorry I misunderstood your question in previous mail. My
understanding of the 'subdivide the LSDB' in your question that ' Are there
separate flooding topologies but a common LSDB? Or are you trying to subdivide
the LSDB?' is subdividing a single LSDB for each MFI.
17 matches
Mail list logo
