Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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 sudden disconnected or partitioned areas, but also that
micro loops during topology changes may not be so micro anymore. It would
be rather rear that all network elements compute topology and activate it
in the same time.

And that is quite different from local protocol convergence when typical
microloop can and do happen all the time, but rest of the topology is
unchanged.

2.
If you however are using such tools as optimizations and you can always
fall back to base topology the risks are much lower. I think there is room
for at least testing it in real scale.

3.
Of course to get #2 going we would need not only control plane topology
creation but also build in data plane ingress to egress live topology
validation - before you shift some traffic on it or remove from it
to fallback to base.


So back to the subject - we still do not know if the current proposal
assumes static bw & static delay or dynamic delay to take into
consideration.

Many thx,
R.



On Tue, Mar 2, 2021 at 7:47 AM Tony Przygienda  wrote:

> 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 another for IGP to magically not be getting there anymore
> while in terms of best-effort functionality the destination looks perky and
> happy. One could argue that you just need a routing table to see whether
> it's there but the nature of those algorithms is that people show up with
> "I want 100MB" and the answer there is very different from another request
> for "I want 1GB". In Fore systems we basically had bunch of
> pre-defined/configurable profiles we were pre-computing the answers
> (obviously also for performance purposes) and comibned with the Q.2931
> doing roughly what RSVP-TE is doing  + crankback to do low catches stuff
> was working pretty well. There is a patent for that still somewhere AFAIR.
>
> -- tony
>
> On Mon, Mar 1, 2021 at 10:48 PM Jeff Tantsura 
> wrote:
>
>> 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 - flex-also requires contiguous topology to work, self isolation as
>> the result of (dynamic) topology re-computation would not be a great thing.
>>
>> Cheers,
>> Jeff
>> On Mar 1, 2021, 12:48 PM -0800, Tony Li , wrote:
>>
>>
>> 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 which may be a
>> problem.
>>
>>
>>
>> I agree that it may be a problem. Maybe it’s not the right tool for the
>> job at hand. That doesn’t make it a bad tool, just the wrong one. I try not
>> to turn screws with a hammer. And I try not to drive nails with a
>> screwdriver.
>>
>> I will happily stipulate that we need more tools and that these are not
>> enough. We should not reject a tool simply because it doesn’t solve all
>> problems. Let’s work towards the right set of tools. Linear algebra tells
>> us that we want an orthogonal set of basis vectors. What are they? Adding
>> them one at a time is not horrible progress.
>>
>>
>> However my observation is precisely related to your last sentence.
>>
>> Is this extension to be used with static or dynamic data ? If static all
>> fine. But as William replied to me earlier link delay may be dynamically
>> computed and may include queue wait time. That to me means something much
>> different if Flex-Algo topologies will become dynamically adjustable. And I
>> am not saying this is not great idea .. My interest here is just to
>> understand the current scope.
>>
>>
>>
>> Link delay was dynamic before this draft. As William mentioned, TWAMP can
>> already be used to provide a dynamic measurement of link delay. That,
>> coupled with the link delay metric already gave us dynamic path computation
>> requirements and the possibilities of oscillation and instability. We have
>> chosen to charge ahead, without addressing those concerns already.
>>
>> Regards,
>> Tony
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> ___
>> Lsr mailing list
>>

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Przygienda]

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
another for IGP to magically not be getting there anymore while in terms of
best-effort functionality the destination looks perky and happy. One could
argue that you just need a routing table to see whether it's there but the
nature of those algorithms is that people show up with "I want 100MB" and
the answer there is very different from another request for "I want 1GB".
In Fore systems we basically had bunch of pre-defined/configurable profiles
we were pre-computing the answers (obviously also for performance purposes)
and comibned with the Q.2931 doing roughly what RSVP-TE is doing  +
crankback to do low catches stuff was working pretty well. There is a
patent for that still somewhere AFAIR.

-- tony

On Mon, Mar 1, 2021 at 10:48 PM Jeff Tantsura 
wrote:

> 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 - flex-also requires contiguous topology to work, self isolation as
> the result of (dynamic) topology re-computation would not be a great thing.
>
> Cheers,
> Jeff
> On Mar 1, 2021, 12:48 PM -0800, Tony Li , wrote:
>
>
> 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 which may be a
> problem.
>
>
>
> I agree that it may be a problem. Maybe it’s not the right tool for the
> job at hand. That doesn’t make it a bad tool, just the wrong one. I try not
> to turn screws with a hammer. And I try not to drive nails with a
> screwdriver.
>
> I will happily stipulate that we need more tools and that these are not
> enough. We should not reject a tool simply because it doesn’t solve all
> problems. Let’s work towards the right set of tools. Linear algebra tells
> us that we want an orthogonal set of basis vectors. What are they? Adding
> them one at a time is not horrible progress.
>
>
> However my observation is precisely related to your last sentence.
>
> Is this extension to be used with static or dynamic data ? If static all
> fine. But as William replied to me earlier link delay may be dynamically
> computed and may include queue wait time. That to me means something much
> different if Flex-Algo topologies will become dynamically adjustable. And I
> am not saying this is not great idea .. My interest here is just to
> understand the current scope.
>
>
>
> Link delay was dynamic before this draft. As William mentioned, TWAMP can
> already be used to provide a dynamic measurement of link delay. That,
> coupled with the link delay metric already gave us dynamic path computation
> requirements and the possibilities of oscillation and instability. We have
> chosen to charge ahead, without addressing those concerns already.
>
> Regards,
> Tony
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Dongjie (Jimmy)]

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 link.

If dynamic, the changes in the metric will result in dynamic computation with 
Flex-Algo constraints, thus more need to be considered: measurement and 
advertisement of dynamic metrics, overhead in dynamic computation, loop 
prevention during dynamic computation and convergence, the possibility of an 
unacceptable result… And with all this overhead in mind, it is better to 
understand what would be the gains, can it help to reduce the congestion or 
packet drop? Or what possible problem it is targeted to solve?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, March 2, 2021 4:22 AM
To: Tony Li 
Cc: Gyan Mishra ; DECRAENE Bruno IMT/OLN 
; Shraddha Hegde ; Rajesh M 
; lsr@ietf.org; William Britto A J 

Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

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 a problem.

However my observation is precisely related to your last sentence.

Is this extension to be used with static or dynamic data ? If static all fine. 
But as William replied to me earlier link delay may be dynamically computed and 
may include queue wait time. That to me means something much different if 
Flex-Algo topologies will become dynamically adjustable. And I am not saying 
this is not great idea .. My interest here is just to understand the current 
scope.

Thx,
R.





On Mon, Mar 1, 2021 at 7:42 PM Tony Li 
mailto:tony...@tony.li>> wrote:

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 that’s not the real problem 
that we’re out to solve.

Reservations are just a first order approximation to a traffic flow in any 
case. We characterize them as having a fixed constant bandwidth, but we all 
know that that is far from the truth. Each flow is diurnal and fractally 
bursty. Every user who ever clicks on a link creates bandwidth demand and while 
the Law of Large Numbers helps us out with some averages we all know that we 
have no good way of characterizing the traffic that we’re trying to carry. 
Claiming that it is a single 12Gbps LSP is truly a huge over simplification and 
a good step towards solving the real problem.

So what is the real problem that we’re trying to solve?

We are trying to not drop packets.

Dropping packets is bad because it forces retransmissions and impacts someone’s 
Internet experience. Dropping packets is our response to congestion events. If 
we could manage to have a network that never congested and always delivered 
packets without giant latency, all would be good.

To date, we have created traffic engineering mechanisms to help us steer 
traffic so that we could delivery traffic without congesting. It has been a 
means to an end. The mechanisms that we’ve created have a non-trivial overhead 
and approximate our goals, but they do NOT preclude, anticipate, or avoid 
congestion. They do not react when we have unexpected inputs. We do extensive 
pre-computation to deal with even single failures and have no serious 
mechanisms that handle multiple failures.

Right now, FlexAlgo does nothing to help with bandwidth management. Wiilliam 
et. al., are proposing some first steps, which are to be encouraged. Much more 
will be needed, not to recreate legacy mechanisms but because we should be 
striving for a more sophisticated, real-time approach to bandwidth management 
and congestion avoidance.

Regards,
Tony



On Mar 1, 2021, at 2:24 AM, William Britto A J 
mailto:bwilliam=40juniper@dmarc.ietf.org>>
 wrote:

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 protocol constructs to 
simplify the use of metric based on bandwidth via Flex-Algo.

This draft does not attempt to do bandwidth management nor reservation like 
what RSVP does. For LDP based networks that use igp metric relative to 
bandwidth, Flex-Algo provides an easy alternate.

Thanks,
William

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Date: Saturday, 27 February 2021 at 9:40 PM
To: Robert Raszuk mailto:ro

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Jeff Tantsura]

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 - flex-also requires contiguous topology to work, self isolation as the 
result of (dynamic) topology re-computation would not be a great thing.

Cheers,
Jeff
On Mar 1, 2021, 12:48 PM -0800, Tony Li , wrote:
>
> 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 which may be a 
> > problem.
>
>
> I agree that it may be a problem. Maybe it’s not the right tool for the job 
> at hand. That doesn’t make it a bad tool, just the wrong one. I try not to 
> turn screws with a hammer. And I try not to drive nails with a screwdriver.
>
> I will happily stipulate that we need more tools and that these are not 
> enough. We should not reject a tool simply because it doesn’t solve all 
> problems. Let’s work towards the right set of tools. Linear algebra tells us 
> that we want an orthogonal set of basis vectors. What are they? Adding them 
> one at a time is not horrible progress.
>
>
> > However my observation is precisely related to your last sentence.
> >
> > Is this extension to be used with static or dynamic data ? If static all 
> > fine. But as William replied to me earlier link delay may be dynamically 
> > computed and may include queue wait time. That to me means something much 
> > different if Flex-Algo topologies will become dynamically adjustable. And I 
> > am not saying this is not great idea .. My interest here is just to 
> > understand the current scope.
>
>
> Link delay was dynamic before this draft. As William mentioned, TWAMP can 
> already be used to provide a dynamic measurement of link delay. That, coupled 
> with the link delay metric already gave us dynamic path computation 
> requirements and the possibilities of oscillation and instability. We have 
> chosen to charge ahead, without addressing those concerns already.
>
> Regards,
> Tony
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Li]

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 which may be a problem. 


I agree that it may be a problem. Maybe it’s not the right tool for the job at 
hand. That doesn’t make it a bad tool, just the wrong one. I try not to turn 
screws with a hammer. And I try not to drive nails with a screwdriver.

I will happily stipulate that we need more tools and that these are not enough. 
 We should not reject a tool simply because it doesn’t solve all problems. 
Let’s work towards the right set of tools. Linear algebra tells us that we want 
an orthogonal set of basis vectors. What are they? Adding them one at a time is 
not horrible progress.


> However my observation is precisely related to your last sentence. 
> 
> Is this extension to be used with static or dynamic data ? If static all 
> fine. But as William replied to me earlier link delay may be dynamically 
> computed and may include queue wait time. That to me means something much 
> different if Flex-Algo topologies will become dynamically adjustable. And I 
> am not saying this is not great idea .. My interest here is just to 
> understand the current scope. 


Link delay was dynamic before this draft.  As William mentioned, TWAMP can 
already be used to provide a dynamic measurement of link delay.  That, coupled 
with the link delay metric already gave us dynamic path computation 
requirements and the possibilities of oscillation and instability. We have 
chosen to charge ahead, without addressing those concerns already.

Regards,
Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Przygienda]

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 meaningfully if the context of the
topologies involved is controlled, pretty much stuff Lou's DETNET is
chewing

my 2c

-- tony



On Mon, Mar 1, 2021 at 9:22 PM Robert Raszuk  wrote:

> 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 a
> problem.
>
> However my observation is precisely related to your last sentence.
>
> Is this extension to be used with static or dynamic data ? If static all
> fine. But as William replied to me earlier link delay may be dynamically
> computed and may include queue wait time. That to me means something much
> different if Flex-Algo topologies will become dynamically adjustable. And I
> am not saying this is not great idea .. My interest here is just to
> understand the current scope.
>
> Thx,
> R.
>
>
>
>
>
> On Mon, Mar 1, 2021 at 7:42 PM Tony Li  wrote:
>
>>
>> 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 that’s not the
>> real problem that we’re out to solve.
>>
>> Reservations are just a first order approximation to a traffic flow in
>> any case. We characterize them as having a fixed constant bandwidth, but we
>> all know that that is far from the truth. Each flow is diurnal and
>> fractally bursty. Every user who ever clicks on a link creates bandwidth
>> demand and while the Law of Large Numbers helps us out with some averages
>> we all know that we have no good way of characterizing the traffic that
>> we’re trying to carry. Claiming that it is a single 12Gbps LSP is truly a
>> huge over simplification and a good step towards solving the real problem.
>>
>> So what is the real problem that we’re trying to solve?
>>
>> We are trying to not drop packets.
>>
>> Dropping packets is bad because it forces retransmissions and impacts
>> someone’s Internet experience. Dropping packets is our response to
>> congestion events. If we could manage to have a network that never
>> congested and always delivered packets without giant latency, all would be
>> good.
>>
>> To date, we have created traffic engineering mechanisms to help us steer
>> traffic so that we could delivery traffic without congesting. It has been a
>> means to an end. The mechanisms that we’ve created have a non-trivial
>> overhead and approximate our goals, but they do NOT preclude, anticipate,
>> or avoid congestion. They do not react when we have unexpected inputs. We
>> do extensive pre-computation to deal with even single failures and have no
>> serious mechanisms that handle multiple failures.
>>
>> Right now, FlexAlgo does nothing to help with bandwidth management.
>> Wiilliam et. al., are proposing some first steps, which are to be
>> encouraged. Much more will be needed, not to recreate legacy mechanisms but
>> because we should be striving for a more sophisticated, real-time approach
>> to bandwidth management and congestion avoidance.
>>
>> Regards,
>> Tony
>>
>>
>> On Mar 1, 2021, at 2:24 AM, William Britto A J <
>> bwilliam=40juniper@dmarc.ietf.org> wrote:
>>
>> 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 protocol
>> constructs to simplify the use of metric based on bandwidth via
>> Flex-Algo.
>>
>> This draft does not attempt to do bandwidth management nor reservation
>> like what RSVP does. For LDP based networks that use igp metric relative to
>> bandwidth, Flex-Algo provides an easy alternate.
>>
>> Thanks,
>> William
>>
>>
>> *From: *Gyan Mishra 
>> *Date: *Saturday, 27 February 2021 at 9:40 PM
>> *To: *Robert Raszuk 
>> *Cc: *DECRAENE Bruno IMT/OLN , Rajesh M <
>> mraj...@juniper.net>, Shraddha Hegde , William
>> Britto A J , lsr@ietf.org 
>> *Subject: *Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
>> *[External Email. Be cautious of content]*
>>
>>
>> Hi William & Co-authors
>>
>> From first read of the draft it does appear your are trying to apply RSVP
>> TE PCALC path and reserve message link attributes constraints such as
>> concept of affinity bits to exclude low bandwidth or delay of individual
>> links with

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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 a
problem.

However my observation is precisely related to your last sentence.

Is this extension to be used with static or dynamic data ? If static all
fine. But as William replied to me earlier link delay may be dynamically
computed and may include queue wait time. That to me means something much
different if Flex-Algo topologies will become dynamically adjustable. And I
am not saying this is not great idea .. My interest here is just to
understand the current scope.

Thx,
R.





On Mon, Mar 1, 2021 at 7:42 PM Tony Li  wrote:

>
> 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 that’s not the real
> problem that we’re out to solve.
>
> Reservations are just a first order approximation to a traffic flow in any
> case. We characterize them as having a fixed constant bandwidth, but we all
> know that that is far from the truth. Each flow is diurnal and fractally
> bursty. Every user who ever clicks on a link creates bandwidth demand and
> while the Law of Large Numbers helps us out with some averages we all know
> that we have no good way of characterizing the traffic that we’re trying to
> carry. Claiming that it is a single 12Gbps LSP is truly a huge over
> simplification and a good step towards solving the real problem.
>
> So what is the real problem that we’re trying to solve?
>
> We are trying to not drop packets.
>
> Dropping packets is bad because it forces retransmissions and impacts
> someone’s Internet experience. Dropping packets is our response to
> congestion events. If we could manage to have a network that never
> congested and always delivered packets without giant latency, all would be
> good.
>
> To date, we have created traffic engineering mechanisms to help us steer
> traffic so that we could delivery traffic without congesting. It has been a
> means to an end. The mechanisms that we’ve created have a non-trivial
> overhead and approximate our goals, but they do NOT preclude, anticipate,
> or avoid congestion. They do not react when we have unexpected inputs. We
> do extensive pre-computation to deal with even single failures and have no
> serious mechanisms that handle multiple failures.
>
> Right now, FlexAlgo does nothing to help with bandwidth management.
> Wiilliam et. al., are proposing some first steps, which are to be
> encouraged. Much more will be needed, not to recreate legacy mechanisms but
> because we should be striving for a more sophisticated, real-time approach
> to bandwidth management and congestion avoidance.
>
> Regards,
> Tony
>
>
> On Mar 1, 2021, at 2:24 AM, William Britto A J <
> bwilliam=40juniper@dmarc.ietf.org> wrote:
>
> 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 protocol
> constructs to simplify the use of metric based on bandwidth via Flex-Algo.
>
> This draft does not attempt to do bandwidth management nor reservation
> like what RSVP does. For LDP based networks that use igp metric relative to
> bandwidth, Flex-Algo provides an easy alternate.
>
> Thanks,
> William
>
>
> *From: *Gyan Mishra 
> *Date: *Saturday, 27 February 2021 at 9:40 PM
> *To: *Robert Raszuk 
> *Cc: *DECRAENE Bruno IMT/OLN , Rajesh M <
> mraj...@juniper.net>, Shraddha Hegde , William
> Britto A J , lsr@ietf.org 
> *Subject: *Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
> *[External Email. Be cautious of content]*
>
>
> Hi William & Co-authors
>
> From first read of the draft it does appear your are trying to apply RSVP
> TE PCALC path and reserve message link attributes constraints such as
> concept of affinity bits to exclude low bandwidth or delay of individual
> links without taking into account all of what RSVP TE is reserving of
> bandwidth in the end to end path with the Path and Reserve message.  As
> mentioned Looking at individual links will not provide the end to end path
> view or bandwidth requirements for the entire path to be reserved as
> accomplished by RSVP TE.
>
> As Tony and Robert have mentioned I agree this is a good first step but
> does need more refinement to make useful.
>
> Kind Regards
>
> Gyan
>
> On Sat, Feb 27, 2021 at 7:24 AM Robert Raszuk  wrote:
>
> Hi William & co-authors,
>
> I read the draft and have two basic questions.
>
> 1.
> Both bw & 

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Li]

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 that’s not the real problem 
that we’re out to solve.

Reservations are just a first order approximation to a traffic flow in any 
case. We characterize them as having a fixed constant bandwidth, but we all 
know that that is far from the truth. Each flow is diurnal and fractally 
bursty. Every user who ever clicks on a link creates bandwidth demand and while 
the Law of Large Numbers helps us out with some averages we all know that we 
have no good way of characterizing the traffic that we’re trying to carry. 
Claiming that it is a single 12Gbps LSP is truly a huge over simplification and 
a good step towards solving the real problem.

So what is the real problem that we’re trying to solve?

We are trying to not drop packets.

Dropping packets is bad because it forces retransmissions and impacts someone’s 
Internet experience. Dropping packets is our response to congestion events. If 
we could manage to have a network that never congested and always delivered 
packets without giant latency, all would be good.

To date, we have created traffic engineering mechanisms to help us steer 
traffic so that we could delivery traffic without congesting. It has been a 
means to an end. The mechanisms that we’ve created have a non-trivial overhead 
and approximate our goals, but they do NOT preclude, anticipate, or avoid 
congestion. They do not react when we have unexpected inputs. We do extensive 
pre-computation to deal with even single failures and have no serious 
mechanisms that handle multiple failures.

Right now, FlexAlgo does nothing to help with bandwidth management. Wiilliam 
et. al., are proposing some first steps, which are to be encouraged. Much more 
will be needed, not to recreate legacy mechanisms but because we should be 
striving for a more sophisticated, real-time approach to bandwidth management 
and congestion avoidance.

Regards,
Tony


> On Mar 1, 2021, at 2:24 AM, William Britto A J 
>  wrote:
> 
> 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 protocol constructs to 
> simplify the use of metric based on bandwidth via Flex-Algo.
>  
> This draft does not attempt to do bandwidth management nor reservation like 
> what RSVP does. For LDP based networks that use igp metric relative to 
> bandwidth, Flex-Algo provides an easy alternate.
>  
> Thanks,
> William
>  
> From: Gyan Mishra mailto:hayabusa...@gmail.com>>
> Date: Saturday, 27 February 2021 at 9:40 PM
> To: Robert Raszuk mailto:rob...@raszuk.net>>
> Cc: DECRAENE Bruno IMT/OLN  >, Rajesh M  >, Shraddha Hegde  >, William Britto A J  >, lsr@ietf.org  
> mailto:lsr@ietf.org>>
> Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
> 
> [External Email. Be cautious of content]
>  
>  
> Hi William & Co-authors 
>  
> From first read of the draft it does appear your are trying to apply RSVP TE 
> PCALC path and reserve message link attributes constraints such as concept of 
> affinity bits to exclude low bandwidth or delay of individual links without 
> taking into account all of what RSVP TE is reserving of bandwidth in the end 
> to end path with the Path and Reserve message.  As mentioned Looking at 
> individual links will not provide the end to end path view or bandwidth 
> requirements for the entire path to be reserved as accomplished by RSVP TE.  
>  
> As Tony and Robert have mentioned I agree this is a good first step but does 
> need more refinement to make useful.
>  
> Kind Regards 
>  
> Gyan
>  
> On Sat, Feb 27, 2021 at 7:24 AM Robert Raszuk  > wrote:
> Hi William & co-authors, 
>  
> I read the draft and have two basic questions. 
>  
> 1. 
> Both bw & delay can be used as defined in the draft to construct new 
> forwarding topologies. But how practical such topologies would be in the real 
> life when 40GB links may be heavily occupied with bursty traffic and 10G 
> links can sit idle ? I suppose you are trying to address the case where say 
> 12 gbps holographic stream needs to be sent across a network.. But then I 
> don't think if sending it in a single flow instead of spreading into many 
> sub-flows and use as much as possible ecmp would not be a better option. 
>  
> 2. 
> Likewise how good is my accumulated link delay value if in between there are 
> deep buffer network elements and say egress queui

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Tony Li]

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 nodes are going to end up synchronized sooner or later, how is 
this better?

Tony




> On Mar 1, 2021, at 1:05 AM, wangyali  wrote:
> 
> 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. 
> 
> Hence in the previous mail I said that 'Because different information 
> advertisements are categorized into different MFI, so an LSP in MFI A and 
> another LSP in MFI B have different flooding topology, flooding parameters, 
> and prioritization for processing LSP. Each flooding instance is associated 
> with a MFI-specific LSDB, which is trying to subdivide the LSDB.' Hence, I'm 
> trying to say each Update process associated with a MFI operates on a 
> logically subdivided LSDB.
> 
> Therefore I clarify that MFIs share a common adjacencies, and a single LSDB. 
> And each MFI can have its own flooding sub topology and its customized 
> flooding parameters.
> 
> Best regards,
> Yali
> 
> -Original Message-
> From: wangyali 
> Sent: Thursday, February 25, 2021 1:24 PM
> To: Tony Li 
> Cc: lsr@ietf.org; Huzhibo ; Aijun Wang 
> ; Tianran Zhou 
> Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
> 
> Hi Tony,
> 
> Thanks for your questions and comments. Please see inline >>Yali.
> 
> Best regards,
> Yali
> 
> -Original Message-
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of Tony Li
> Sent: Wednesday, February 24, 2021 6:08 AM
> To: wangyali 
> Cc: lsr@ietf.org; Huzhibo ; Aijun Wang 
> ; Tianran Zhou 
> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
> 
> 
> Hi,
> 
> Thank you for contributing your draft. I’m writing because I’m having trouble 
> understanding the motivation for this work.
> 
> First off, I do NOT want to argue about carrying unnecessary information in 
> IS-IS. IMHO, it is unmitigated evil and an attempt to destroy the viability 
> of the protocol by creating arbitrary complexity and scale. But never mind 
> that, I’ll stipulate for this discussion that we want to do so.
> 
> Given this, what is it that you’re trying to accomplish?  You’ve called this 
> a ‘multi-flooding instance’, but it’s very unclear about what that means.  
> You say that multiple MFIs exist within a single IS-IS instance.
>>> Yali: The ‘multi-flooding instance' means that multiple Update process are 
>>> allowed operating within the zero IS-IS instance. Each Update process is 
>>> associated with a topology and a LSDB. Flooding parameters of each Update 
>>> process can be different and customized based on different information 
>>> needed to be advertised in the associated Flooding Instance. 
> Although each Flooding Instance has its own separate Update process, flooding 
> topology and LSDB, these multiple flooding instances share a common 
> adjacencies.
> 
> You obviously want data flooded. So what is the difference between an LSP in 
> MFI A and another LSP in MFI B? Are there separate flooding topologies but a 
> common LSDB? Or are you trying to subdivide the LSDB?
>>> Yali: Because different information advertisements are categorized into 
>>> different MFI, so an LSP in MFI A and another LSP in MFI B have different 
>>> flooding topology, flooding parameters, and prioritization for processing 
>>> LSP. 
> Each flooding instance is associated with a MFI-specific LSDB, which is 
> trying to subdivide the LSDB.
> 
> You mention that there is only a single update process in an instance. 
> AFAICT, that’s only a model, not a requirement. There’s no prohibition that I 
> know of against an implementation using a process per interface if iit wanted 
> to.
>>> Yali: As mentioned in draft, the each flooding instance support one update 
>>> process operation on a LSDB.
> 
> What problem are you solving?
>>> Yali: The problem we are trying to solve is how to isolate application 
>>> information flooding from the routing information flooding through multiple 
>>> flooding instance.
> 
> Regards,
> Tony
> 
> 
> 
>> On Feb 22, 2021, at 11:10 PM, wangyali  wrote:
>> 
>> Hi all,
>> 
>> In order to separate multiple flooding instances for dissemination of 
>> routing information and other types of application-specific information to 
>> minimizes the impact of non-routing information flooding on the routing 
>> convergence and stability, We submitted a new IS-IS flooding mechanism 
>> implemented in the zero IS-IS instance, named as IS-IS Multi-flooding 
>> Instances (MFIs).
>> 
>> An encoding format for

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Przygienda]

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 I have many comments…
>
> 1) I’ll start with the title: there is MUCH more here than bandwidth
> constraints. Perhaps this should be generalized somehow? Sorry, I don’t
> have a constructive suggestion.
>

there is good general, theoretical body of work here that shows what is
possible to compute (NP completeness, algorighms, heuristics). short search
yields e.g.

http://www.csun.edu/~ctoth/Handbook/chap31.pdf
https://engineering.purdue.edu/~ece624/Week-9.pdf

JSAC '96 Crowcroft is a starting point on additive/multiplicative, other
papers even eqarlier called that stuff max/additive, convex/concave (that
has to do with linear programming space properties) etc. I'm aware of work
going as far back as '92-'93 here.

Generally, one max/min & one additive is doable (you need additive to make
sure you don't start hamiltonian walks based on a constraint ;-)  Mixing up
addvitive & mix/min is a fairly poor idea unless one is happy with
heurestics that kind of "almost always work" and customer is not looking
for hard guarantees but "wishes that maybe granted".

>
>
> 2) Section 2: I concur that bandwidth is an important consideration in
> path computation. At a first reading, it is not at all clear to me that it
> is optimal to somehow transmogrify things into a metric. Why not simply
> deal with the bandwidth directly?  I did (eventually) realize that you did
> this because you want SPF to somehow select the path with the minimum
> product of (# links) * bandwidth.  I think you need to be explicit about
> this motivation and also mention that traditional SPF is not set up to deal
> with a floating point metric. Note that a bandwidth metric is STILL
> somewhat counter-intuitive to me, as I would expect that you’d mostly want
> to route things along the highest bandwidth paths, not the lowest ones.
> More motivation behind the bandwidth metric would be most welcome.
>

yeah, BW can be made a metric and work, IEEE encoding is simply a funky
number and different max/min/additive/multiplicative/any increasing
function (whether it has to be stricly monotonic is a more complex
discussion).  old but very solid stuff for that space

https://tools.ietf.org/html/rfc2676

based on even earlier


   [BP95]   J.-Y. Le Boudec and T. Przygienda.  A Route Pre-Computation
Algorithm for Integrated Services Networks.  Journal of
Network and Systems Management, 3(4), 1995.
   [GOW97]  R. Guerin, A. Orda, and D. Williams.  QoS Routing Mechanisms
and OSPF Extensions.  In Proceedings of the 2nd IEEE Global
Internet Mini-Conference, pages 1903-1908, Phoenix, AZ,
November 1997.

expired draft-ietf-qosr-framework-04.txt

 but given graph theory doesn't change things roughly still the same ;-)

There is also good body of work on something that quickly interacts with
that work, namely k-disjointness. e'thing looking for "fattest pipe" or
"shortest-widest" pretty quickly crams all traffic on the same links ;-)
unless somehting like RSVP-TE reserves & changes metric.

All those things have been implemented and worked in products so we know
they work, maybe flex stuff is just a framework now to unify it all a bit.

my only small nit on the draft is that the stepping is in practical terms
almost always exponewntial so you don't have to encode full value
necessarily. the rounding has to adjust to link size as well or is better
served as % value.

-- tony
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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
under the impression that this would be a static cfg based value.

Can you clarify ?

Thx,
R.


On Mon, Mar 1, 2021 at 11:16 AM William Britto A J 
wrote:

> 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 for SPF, is a very useful feature for
> such network consolidation use-cases. We are trying introduce the protocol
> constructs to simplify the use of metric based on bandwidth via Flex-Algo.
>
>
>
> Any existing tools and techniques used by operators who configure metric
> relative to link bandwidth to optimize the network can be used with these
> Flex-Algo constructs too. The Flex-Algo bandwidth constraints defined here
> can be used to automatically derive a metric based on reference bw vs link
> bw; and if required, this can be overridden using the individual link
> bandwidth-metric sub-TLV. We will make this clear in the next version.
>
>
>
> RFC 8570 support advertising link delay parameters in ISIS. Protocols like
> TWAMP support dynamically measuring the delay. Whether egress queueing
> delay is included in the link delay depends on the measuring mechanism. The
> Exclude Max Delay sub-TLV introduced in this draft is only meant for
> pruning out high latency links from a Flex-Algo, and it is upto the
> operator to define the maximum bounds based on the measuring mechanisms
> deployed in his network.
>
>
>
> Thanks,
>
> William
>
>
>
> *From: *Robert Raszuk 
> *Date: *Saturday, 27 February 2021 at 5:54 PM
> *To: *William Britto A J 
> *Cc: *lsr@ietf.org , Rajesh M ,
> Shraddha Hegde , DECRAENE Bruno IMT/OLN <
> bruno.decra...@orange.com>
> *Subject: *Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi William & co-authors,
>
>
>
> I read the draft and have two basic questions.
>
>
>
> 1.
>
> Both bw & delay can be used as defined in the draft to construct new
> forwarding topologies. But how practical such topologies would be in the
> real life when 40GB links may be heavily occupied with bursty traffic and
> 10G links can sit idle ? I suppose you are trying to address the case where
> say 12 gbps holographic stream needs to be sent across a network.. But then
> I don't think if sending it in a single flow instead of spreading into many
> sub-flows and use as much as possible ecmp would not be a better option.
>
>
>
> 2.
>
> Likewise how good is my accumulated link delay value if in between there
> are deep buffer network elements and say egress queuing to each link (which
> max is unaccounted for in your draft) can significantly alter the end to
> end delay ? Have you consider to add MAX_EGRESS_QUEUE_DELAY on a per link
> basis (still as static value).  So if some traffic is delay sensitive we
> will have a much better accuracy not to get into a trap of queuing related
> delays.
>
>
>
> Thx a lot,
>
> Robert.
>
>
>
>
>
> On Fri, Feb 26, 2021 at 8:37 AM William Britto A J  40juniper@dmarc.ietf.org> wrote:
>
> All,
>
>
>
> We would like to draw your attention to a new ID:
> https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00
> 
>
>
>
> The draft talks about introducing link bandwidth related constraints in
> Flex-Algorithm which can be used to define a Flex-Algorithm based on
> bandwidth based metric.
>
>
>
> Please review. Any questions and comments are welcome.
>
>
>
> Thanks,
>
> William
>
>
>
>
>
> *From: *internet-dra...@ietf.org 
> *Date: *Monday, 22 February 2021 at 10:56 PM
> *To: *Bruno Decraene , Rajesh M <
> mraj...@juniper.net>, Rajesh M , Shraddha Hegde <
> shrad...@juniper.net>, William Britto A J , William
> Britto A J 
> *Subject: *New Version Notification for
> draft-hegde-lsr-flex-algo-bw-con-00.txt
>
> [External Email. Be cautious of content]
>
>
> A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt
> has been successfully submitted by Shraddha Hegde and posted to the
> IETF repository.
>
> Name:   draft-hegde-lsr-flex-algo-bw-con
> Revision:   00
> Title:  Flexible Algorithms Bandwidth Constraints
> Document date:  2021-02-22
> Group:  Individual Submission
> Pages:  21
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[William Britto A J]

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 protocol constructs to 
simplify the use of metric based on bandwidth via Flex-Algo.

This draft does not attempt to do bandwidth management nor reservation like 
what RSVP does. For LDP based networks that use igp metric relative to 
bandwidth, Flex-Algo provides an easy alternate.

Thanks,
William

From: Gyan Mishra 
Date: Saturday, 27 February 2021 at 9:40 PM
To: Robert Raszuk 
Cc: DECRAENE Bruno IMT/OLN , Rajesh M 
, Shraddha Hegde , William Britto A 
J , lsr@ietf.org 
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
[External Email. Be cautious of content]


Hi William & Co-authors

>From first read of the draft it does appear your are trying to apply RSVP TE 
>PCALC path and reserve message link attributes constraints such as concept of 
>affinity bits to exclude low bandwidth or delay of individual links without 
>taking into account all of what RSVP TE is reserving of bandwidth in the end 
>to end path with the Path and Reserve message.  As mentioned Looking at 
>individual links will not provide the end to end path view or bandwidth 
>requirements for the entire path to be reserved as accomplished by RSVP TE.

As Tony and Robert have mentioned I agree this is a good first step but does 
need more refinement to make useful.

Kind Regards

Gyan

On Sat, Feb 27, 2021 at 7:24 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi William & co-authors,

I read the draft and have two basic questions.

1.
Both bw & delay can be used as defined in the draft to construct new forwarding 
topologies. But how practical such topologies would be in the real life when 
40GB links may be heavily occupied with bursty traffic and 10G links can sit 
idle ? I suppose you are trying to address the case where say 12 gbps 
holographic stream needs to be sent across a network.. But then I don't think 
if sending it in a single flow instead of spreading into many sub-flows and use 
as much as possible ecmp would not be a better option.

2.
Likewise how good is my accumulated link delay value if in between there are 
deep buffer network elements and say egress queuing to each link (which max is 
unaccounted for in your draft) can significantly alter the end to end delay ? 
Have you consider to add MAX_EGRESS_QUEUE_DELAY on a per link basis (still as 
static value).  So if some traffic is delay sensitive we will have a much 
better accuracy not to get into a trap of queuing related delays.

Thx a lot,
Robert.


On Fri, Feb 26, 2021 at 8:37 AM William Britto A J 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
All,

We would like to draw your attention to a new ID: 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00

The draft talks about introducing link bandwidth related constraints in 
Flex-Algorithm which can be used to define a Flex-Algorithm based on bandwidth 
based metric.

Please review. Any questions and comments are welcome.

Thanks,
William


From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Date: Monday, 22 February 2021 at 10:56 PM
To: Bruno Decraene 
mailto:bruno.decra...@orange.com>>, Rajesh M 
mailto:mraj...@juniper.net>>, Rajesh M 
mailto:mraj...@juniper.net>>, Shraddha Hegde 
mailto:shrad...@juniper.net>>, William Britto A J 
mailto:bwill...@juniper.net>>, William Britto A J 
mailto:bwill...@juniper.net>>
Subject: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-00.txt
[External Email. Be cautious of content]


A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt
has been successfully submitted by Shraddha Hegde and posted to the
IETF repository.

Name:   draft-hegde-lsr-flex-algo-bw-con
Revision:   00
Title:  Flexible Algorithms Bandwidth Constraints
Document date:  2021-02-22
Group:  Individual Submission
Pages:  21
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$
Status: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[William Britto A J]

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 for SPF, is a very useful feature for such network 
consolidation use-cases. We are trying introduce the protocol constructs to 
simplify the use of metric based on bandwidth via Flex-Algo.

Any existing tools and techniques used by operators who configure metric 
relative to link bandwidth to optimize the network can be used with these 
Flex-Algo constructs too. The Flex-Algo bandwidth constraints defined here can 
be used to automatically derive a metric based on reference bw vs link bw; and 
if required, this can be overridden using the individual link bandwidth-metric 
sub-TLV. We will make this clear in the next version.

RFC 8570 support advertising link delay parameters in ISIS. Protocols like 
TWAMP support dynamically measuring the delay. Whether egress queueing delay is 
included in the link delay depends on the measuring mechanism. The Exclude Max 
Delay sub-TLV introduced in this draft is only meant for pruning out high 
latency links from a Flex-Algo, and it is upto the operator to define the 
maximum bounds based on the measuring mechanisms deployed in his network.

Thanks,
William

From: Robert Raszuk 
Date: Saturday, 27 February 2021 at 5:54 PM
To: William Britto A J 
Cc: lsr@ietf.org , Rajesh M , Shraddha Hegde 
, DECRAENE Bruno IMT/OLN 
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
[External Email. Be cautious of content]

Hi William & co-authors,

I read the draft and have two basic questions.

1.
Both bw & delay can be used as defined in the draft to construct new forwarding 
topologies. But how practical such topologies would be in the real life when 
40GB links may be heavily occupied with bursty traffic and 10G links can sit 
idle ? I suppose you are trying to address the case where say 12 gbps 
holographic stream needs to be sent across a network.. But then I don't think 
if sending it in a single flow instead of spreading into many sub-flows and use 
as much as possible ecmp would not be a better option.

2.
Likewise how good is my accumulated link delay value if in between there are 
deep buffer network elements and say egress queuing to each link (which max is 
unaccounted for in your draft) can significantly alter the end to end delay ? 
Have you consider to add MAX_EGRESS_QUEUE_DELAY on a per link basis (still as 
static value).  So if some traffic is delay sensitive we will have a much 
better accuracy not to get into a trap of queuing related delays.

Thx a lot,
Robert.


On Fri, Feb 26, 2021 at 8:37 AM William Britto A J 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
All,

We would like to draw your attention to a new ID: 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00

The draft talks about introducing link bandwidth related constraints in 
Flex-Algorithm which can be used to define a Flex-Algorithm based on bandwidth 
based metric.

Please review. Any questions and comments are welcome.

Thanks,
William


From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Date: Monday, 22 February 2021 at 10:56 PM
To: Bruno Decraene 
mailto:bruno.decra...@orange.com>>, Rajesh M 
mailto:mraj...@juniper.net>>, Rajesh M 
mailto:mraj...@juniper.net>>, Shraddha Hegde 
mailto:shrad...@juniper.net>>, William Britto A J 
mailto:bwill...@juniper.net>>, William Britto A J 
mailto:bwill...@juniper.net>>
Subject: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-00.txt
[External Email. Be cautious of content]


A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt
has been successfully submitted by Shraddha Hegde and posted to the
IETF repository.

Name:   draft-hegde-lsr-flex-algo-bw-con
Revision:   00
Title:  Flexible Algorithms Bandwidth Constraints
Document date:  2021-02-22
Group:  Individual Submission
Pages:  21
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$
Status: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[wangyali]

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] 
Sent: Sunday, February 28, 2021 8:23 PM
To: Gyan Mishra ; Robert Raszuk 
Cc: Huzhibo ; Aijun Wang ; Tony Li 
; lsr ; Tianran Zhou ; 
wangyali 
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Gyan,

On 26/02/2021 17:19, Gyan Mishra wrote:
> 
> MFI seems more like flex algo with multiple sub topologies sharing a 
> common links in a  topology where RFC 8202 MI is separated at the 
> process level separate LSDB.  So completely different and of course 
> different goals and use cases for MI versus MFI.

I would not use the fle-algo analogy - all flex-algos operate on top of a 
single LSDB, contrary to what is being proposed in MFI draft.

> 
>   MFI also seems to be a flood reduction mechanism by creating 
> multiple sub topology instances within a common LSDB.  There are a 
> number of flood reduction drafts and this seems to be another method 
> of achieving the same.

MFI draft proposes to keep the separate LSDB per MFI, so the above analogy is 
not correct either.

thanks,
Peter


> 
> Gyan
> 
> On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk  > wrote:
> 
> Aijun,
> 
> How multi instance is implemented is at the discretion of a vendor.
> It can be one process N threads or N processes. It can be both and
> operator may choose.
> 
> MFI is just one process - by the spec - so it is inferior.
> 
> Cheers,
> R.
> 
> 
> On Fri, Feb 26, 2021 at 12:44 PM Aijun Wang  > wrote:
> 
> Hi, Robert:
> 
> Separate into different protocol instances can accomplish the
> similar task, but it has some deployment overhead.
> MFIs within one instance can avoid such cumbersome work, and
> doesn’t affect the basic routing calculation process.
> 
> Aijun Wang
> China Telecom
> 
>> On Feb 26, 2021, at 19:00, Robert Raszuk > > wrote:
>>
>> Hi Yali,
>>
>> If this was precise, then the existing multi-instance
>> mechanism would be sufficient.
>> [Yali]: MFI is a different solution we recommend to solve
>> this same and valuable issue.
>>
>>
>> Well the way I understand this proposal MFI is much weaker
>> solution in terms of required separation.
>>
>> In contrast RFC8202 allows to separate ISIS instances at the
>> process level, but here MFIs as defined must be handled by the
>> same ISIS process
>>
>> This document defines an extension to
>> IS-IS to allow*one standard instance*  of
>> the protocol to support multiple update
>> process operations.
>>
>> Thx,
>> R.
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org 
>> https://www.ietf.org/mailman/listinfo/lsr
> 
> ___
> Lsr mailing list
> Lsr@ietf.org 
> https://www.ietf.org/mailman/listinfo/lsr
> 
> --
> 
> 
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[wangyali]

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 flooding sub topology and its customized flooding 
parameters.

Best regards,
Yali


From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Saturday, February 27, 2021 12:19 AM
To: Robert Raszuk 
Cc: Aijun Wang ; Huzhibo ; Tianran 
Zhou ; Tony Li ; lsr ; 
wangyali 
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt


MFI seems more like flex algo with multiple sub topologies sharing a common 
links in a  topology where RFC 8202 MI is separated at the process level 
separate LSDB.  So completely different and of course different goals and use 
cases for MI versus MFI.

 MFI also seems to be a flood reduction mechanism by creating multiple sub 
topology instances within a common LSDB.  There are a number of flood reduction 
drafts and this seems to be another method of achieving the same.

Gyan

On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Aijun,

How multi instance is implemented is at the discretion of a vendor. It can be 
one process N threads or N processes. It can be both and operator may choose.

MFI is just one process - by the spec - so it is inferior.

Cheers,
R.


On Fri, Feb 26, 2021 at 12:44 PM Aijun Wang 
mailto:wang...@chinatelecom.cn>> wrote:
Hi, Robert:

Separate into different protocol instances can accomplish the similar task, but 
it has some deployment overhead.
MFIs within one instance can avoid such cumbersome work, and doesn’t affect the 
basic routing calculation process.
Aijun Wang
China Telecom


On Feb 26, 2021, at 19:00, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Yali,

If this was precise, then the existing multi-instance mechanism would be 
sufficient.
[Yali]: MFI is a different solution we recommend to solve this same and 
valuable issue.

Well the way I understand this proposal MFI is much weaker solution in terms of 
required separation.

In contrast RFC8202 allows to separate ISIS instances at the process level, but 
here MFIs as defined must be handled by the same ISIS process


   This document defines an extension to

   IS-IS to allow one standard instance of

   the protocol to support multiple update

   process operations.

Thx,
R.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--

[Image removed by sender.]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[wangyali]

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 Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Yali, 

Speaking as WG member:

So this rather simplistic draft can be summarized as separate out the 
non-routing info into different LSPs, tag the corresponding LSPs, and then 
implementations can "do the right thing". As we already have RFC 8202 which 
offers clean separation, I don't know why we'd consider this under specified 
proposal. 
>Yali: This draft intend to propose a different solution, aka MFI, to isolate 
>the non-routing information flooding from routing information flooding in a 
>standard IS-IS standard. So there are no non-zero instances of IS-IS protocol 
>needed to be used. 
Different from RFC8202, MFIs share a common adjacencies and a single LSDB. Each 
Update process associated with a MFI-specific sub topology operates on a 
logically subdivided LSDB. For each MFI, it is given a MFI-specific 
prioritization for processing PDUs and MFI-specific flooding parameters so as 
to allow different MFIs to consume network-wide resources at different rates. 

Using a separate instance offers other advantages such only requiring those 
IS-IS routers that need the non-routing information to be in the topology and 
providing a separate LSPs space for the new instances.
>Yali: Each non-zero MFI can also support a sparse sub topology in which there 
>are those IS-IS routers that are interested in the non-routing information. 
>Besides, this draft also specifies that each MFI can has its own sets of LSPs.

Speaking as WG Co-chair:

Given the feedback you've received thus far, do you still want to present this 
draft at IETF 110?
>Yali: Many thanks for all guys’ comments and questions. Given these feedbacks, 
>I think there are still a lot of points needed to be discussed at IETF 110. If 
>possible, I wish there's time to present.

Thanks,
Acee



On 2/23/21, 2:11 AM, "Lsr on behalf of wangyali"  wrote:

Hi all,

In order to separate multiple flooding instances for dissemination of 
routing information and other types of application-specific information to 
minimizes the impact of non-routing information flooding on the routing 
convergence and stability, We submitted a new IS-IS flooding mechanism 
implemented in the zero IS-IS instance, named as IS-IS Multi-flooding Instances 
(MFIs).

 An encoding format for IS-IS MFI-ID TLV and MFIs Update Process defined in 
this draft could be found in 
https://datatracker.ietf.org/doc/draft-wang-lsr-isis-mfi/ .

Any questions and comments are welcome.

Thanks,
Yali

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, February 22, 2021 9:59 AM
To: Aijun Wang ; Tianran Zhou 
; wangyali ; Huzhibo 

Subject: New Version Notification for draft-wang-lsr-isis-mfi-00.txt


A new version of I-D, draft-wang-lsr-isis-mfi-00.txt has been successfully 
submitted by Yali Wang and posted to the IETF repository.

Name:   draft-wang-lsr-isis-mfi
Revision:   00
Title:  IS-IS Multi-Flooding Instances
Document date:  2021-02-20
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/archive/id/draft-wang-lsr-isis-mfi-00.txt
Status: https://datatracker.ietf.org/doc/draft-wang-lsr-isis-mfi/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-isis-mfi
Htmlized:   https://tools.ietf.org/html/draft-wang-lsr-isis-mfi-00


Abstract:
   This document proposes a new IS-IS flooding mechanism which separates
   multiple flooding instances for dissemination of routing information
   and other types of application-specific information to minimizes the
   impact of non-routing information flooding on the routing convergence
   and stability.  Due to different flooding information has different
   requirements on the flooding rate, these multi-flooding instances
   should be given various priorities and flooding parameters.  An
   encoding format for IS-IS Multi-Flooding Instance Identifier (MFI-ID)
   TLV and Update Process are specified in this document.





Please note that it may take a couple of minutes from the time of 
submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[wangyali]

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. 

Hence in the previous mail I said that 'Because different information 
advertisements are categorized into different MFI, so an LSP in MFI A and 
another LSP in MFI B have different flooding topology, flooding parameters, and 
prioritization for processing LSP. Each flooding instance is associated with a 
MFI-specific LSDB, which is trying to subdivide the LSDB.' Hence, I'm trying to 
say each Update process associated with a MFI operates on a logically 
subdivided LSDB.

Therefore I clarify that MFIs share a common adjacencies, and a single LSDB. 
And each MFI can have its own flooding sub topology and its customized flooding 
parameters.

Best regards,
Yali

-Original Message-
From: wangyali 
Sent: Thursday, February 25, 2021 1:24 PM
To: Tony Li 
Cc: lsr@ietf.org; Huzhibo ; Aijun Wang 
; Tianran Zhou 
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Tony,

Thanks for your questions and comments. Please see inline >>Yali.

Best regards,
Yali

-Original Message-
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of Tony Li
Sent: Wednesday, February 24, 2021 6:08 AM
To: wangyali 
Cc: lsr@ietf.org; Huzhibo ; Aijun Wang 
; Tianran Zhou 
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt


Hi,

Thank you for contributing your draft. I’m writing because I’m having trouble 
understanding the motivation for this work.

First off, I do NOT want to argue about carrying unnecessary information in 
IS-IS. IMHO, it is unmitigated evil and an attempt to destroy the viability of 
the protocol by creating arbitrary complexity and scale. But never mind that, 
I’ll stipulate for this discussion that we want to do so.

Given this, what is it that you’re trying to accomplish?  You’ve called this a 
‘multi-flooding instance’, but it’s very unclear about what that means.  You 
say that multiple MFIs exist within a single IS-IS instance.
>>Yali: The ‘multi-flooding instance' means that multiple Update process are 
>>allowed operating within the zero IS-IS instance. Each Update process is 
>>associated with a topology and a LSDB. Flooding parameters of each Update 
>>process can be different and customized based on different information needed 
>>to be advertised in the associated Flooding Instance. 
Although each Flooding Instance has its own separate Update process, flooding 
topology and LSDB, these multiple flooding instances share a common adjacencies.

You obviously want data flooded. So what is the difference between an LSP in 
MFI A and another LSP in MFI B? Are there separate flooding topologies but a 
common LSDB? Or are you trying to subdivide the LSDB?
>>Yali: Because different information advertisements are categorized into 
>>different MFI, so an LSP in MFI A and another LSP in MFI B have different 
>>flooding topology, flooding parameters, and prioritization for processing 
>>LSP. 
Each flooding instance is associated with a MFI-specific LSDB, which is trying 
to subdivide the LSDB.

You mention that there is only a single update process in an instance. AFAICT, 
that’s only a model, not a requirement. There’s no prohibition that I know of 
against an implementation using a process per interface if iit wanted to.
>>Yali: As mentioned in draft, the each flooding instance support one update 
>>process operation on a LSDB.

What problem are you solving?
>>Yali: The problem we are trying to solve is how to isolate application 
>>information flooding from the routing information flooding through multiple 
>>flooding instance.

Regards,
Tony



> On Feb 22, 2021, at 11:10 PM, wangyali  wrote:
> 
> Hi all,
> 
> In order to separate multiple flooding instances for dissemination of routing 
> information and other types of application-specific information to minimizes 
> the impact of non-routing information flooding on the routing convergence and 
> stability, We submitted a new IS-IS flooding mechanism implemented in the 
> zero IS-IS instance, named as IS-IS Multi-flooding Instances (MFIs).
> 
> An encoding format for IS-IS MFI-ID TLV and MFIs Update Process defined in 
> this draft could be found in 
> https://datatracker.ietf.org/doc/draft-wang-lsr-isis-mfi/ .
> 
> Any questions and comments are welcome.
> 
> Thanks,
> Yali
> 
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, February 22, 2021 9:59 AM
> To: Aijun Wang ; Tianran Zhou 
> ; wangyali ; Huzhibo 
> 
> Subject: New Version Notification for draft-wang-lsr-isis-mfi-00.txt
> 
> 
> A new version of I-D, draft-wang-lsr-isis-mfi-00.txt has been successfully 
> submitted by Yali Wang and posted to the IETF repository.
> 
> Name: