Robert,
On 04/03/2021 10:50, Robert Raszuk wrote:
Peter,
Sorry but the draft does not have a disclaimer section which states:
"Extensions defined below are only applicable to networks with not even
a single emulated circuit in the IGP."
> Obviously, if the min delay fluctuates wildly, one can not achieve
delay optimized
> forwarding no matter what.
If VPWS provider's IP network reconverges once per day or per hour I see
nothing wrong with flooding new link delays and recomputing the topology
of the network running on top of such constructs.
the question is how much sense would it make to try to optimize based on
delay if it fluctuates every ms and we optimize once per day. But feel
free to give it a shot if you believe it's a good idea.
Peter
My point is that
changes are real, pretty unpredictable and in ms or 10s of ms. And IMO
the proposal on the table is specifically designed to catch and address
those cases - not just dismiss it as you can not use it in your network
- sorry mr customer. >
Best,
R.
On Thu, Mar 4, 2021 at 10:41 AM Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>> wrote:
Robert,
On 04/03/2021 10:23, Robert Raszuk wrote:
> Peter,
>
> Completely disagree.
that's what you seem to be doing from the beginning of this
conversation ;)
>
> Real say enterprise networks are being build with emulated circuits
> (example VPWS). In one company I was working at it was about 80% of
> emulated links all over the world in their WAN. Yes for me it was a
> shock as I did not realize how much this emulated links took over
the
> world. In most geographies you even can not get any link of less
then
> 10Gbps to be real any more. Only emulated option is on the table.
>
> Emulated circuits run over someone's IP backbones. You can
understand
> the consequences of this. Not only link delay changes a lot but
you run
> into very interesting set of issues.
look at it from the opposite direction. The provider of the VPWS is the
one who can use this technology to guarantee the delay bound of the
WPWs
service. And if it does, the user of the WPWs would not experience the
wild variation in the min delay.
So you have to apply right set of tools at right location.
Obviously, if
the min delay fluctuates wildly, one can not achieve delay optimized
forwarding no matter what. That does not mean that the network will get
unstable.
Peter
>
> Maybe you think of the backbones of the 90s or 2000s where dark
fiber or
> SDH or SONET were in use for interconnects.
>
> Well no more. IETF came with such brilliant ideas to emulate L2
over L3
> and here we go.
>
> Reality is not what we wish it to be.
>
> Cheers,
> R.
>
>
> On Thu, Mar 4, 2021 at 10:07 AM Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>> wrote:
>
> Robert,
>
> On 03/03/2021 20:57, Robert Raszuk wrote:
> > Peter,
> >
> > > that differ by few microsecond
> >
> > Really you normalize only single digit microseconds ???
> >
> > What if link delay changes in milliseconds scale ? Do you
want to
> > compute new topology every few milliseconds ?
>
> let me repeat again.
>
> Min delay is not something that changes every few milliseconds
> significantly. It's a semi static variable that reflects the
> property of
> the underlying physical path. It only changes when the
physical path
> properties changes - e.g. the optical path reroutes, etc. We
> deliberately picked Min delay for flex-algo purposes for this
semi
> static property.
>
> The small, non significant changes can be filtered by the
normalization.
>
> If the min delay changes significantly every few milliseconds
there's
> something wrong with the link itself - we have standard dampening
> mechanisms in LS protocols to deal with unstable links that
would kick
> in. Similar to what we do if the link flaps every few
milliseconds.
>
> >
> > Out of curiosity as this is not a secret - What are your
default
> min
> > delay normalization timers (if user does not overwrite
with their
> own).
>
> there is no timer needed for the normalization itself.
>
> You are likely referring TWAMP computation interval which is
30 sec,
> with probes being sent every 3 seconds in our implementation by
> default,
> if I'm not mistaken.
>
> Normalization is applied to the value that come from the above.
>
> thanks,
> Peter
>
>
>
> > Likewise how Junos or Arista normalizes it today ?
> >
> > Thx,
> > R.
> >
> > On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak
<ppse...@cisco.com <mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>
> > <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>
<mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>>> wrote:
> >
> > Tony,
> >
> > On 03/03/2021 19:14, Tony Li wrote:
> > >
> > > Peter,
> > >
> > >>> There are several link types in use that exhibit
variable
> > delay: satellite links (e.g., Starlink), microwave
links, and
> > ancient link layers that deliver reliability through
> retransmission.
> > >>> Any of these (and probably a lot more) can create a
> noticeable
> > and measurable difference in TWAMP. That would be
reflected
> in an FA
> > metric change. If you imagine a situation with
multiiple parallel
> > paths with nearly identical delays, you can easily
imagine an
> > oscillatory scenario. IMHO, this is an outstanding
concern
> with FA.
> > >> yes, and that is what I referred to as "delay
normalization",
> > which can avoid that oscillation.
> > >
> > >
> > > It can also negate the benefits of the feature. One
might well
> > imagine that Starlink would want to follow a min-delay
path for
> > optimality. If the delay variations are “normalized”
out of
> > existence, then the benefits are lost. The whole
point is to
> track
> > the dynamics.
> >
> > for all practical purposes that we use it for, the two
values
> of min
> > delay that differ by few microsecond can be treated as
same
> without any
> > loss of functionality. So it's about the required
normalization
> > interval
> > - something that can be controlled by the user.
> >
> > thanks,
> > Peter
> >
> >
> >
> > >
> > >
> > >>> Please note that I’m NOT recommending that we
back away.
> > Rather, we should seek to solve the long-standing issue of
> > oscillatory routing.
> > >>
> > >> not that I disagree. History tells us that the generic
> case of
> > oscillation which is caused by the traffic itself is a
hard
> problem
> > to solve.
> > >
> > >
> > > Any oscillation is difficult to solve. Positive
feedback
> > certainly can exacerbate the problem. But solving hard
> problems is
> > why we are here.
> > >
> > > Yours in control theory,
> > > Tony
> > >
> > >
> > >
> >
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr