Hi, Jeff:
The draft only propose to transfer the iFIT capability of the Node via the IGP
protocol, not the telemetry data.
As described in the draft, flooding such capability can assist the
controller(it collects such information via the BGP-LS) to deploy the iFIT
function at the path headend.
Hi Jeff,
excellent question, thank you!
If one wants to empower headends with all the telemetry, then there's no
need to collect it. A method that triggers node-local measurement is
sufficient to calculate node-local performance metrics that may be
periodically exported to a Collector or ...
Robert,
We are deviating ;-)
There’s no feedback loop from telemetry producers back to the TE headend.
The telemetry, either end2end or postcards is sent to a collector that has the
context of the data and normalizes it so it can be consumed by an external
system, being centralized or
Hi,
In this morning’s session, Acee asked a question about node selection as part
of path computation. I would like to expound a bit in the spirit of full
transparency.
First off, the selection of nodes is NOT vital to the algorithm. That said, we
found that applying some heuristics helped
> Sure it is possible to discover if my tailends are capable of handling in
> band telemetry by off line means. But what I am struggling to see why we
> allowed so much TE stuff into IGPs and we do not want to make it easier for
> headends to operate without PCE at all for the purpose of
> "collected only on active paths" is not something I propose but is the
property of on-path
> telemetry collection method.
That is all fine. The point is that the notion of active paths in the
network may represent those in default topology over any path. That can be
computed by PCE.
So default
Hi Robert,
"collected only on active paths" is not something I propose but is the
property of on-path telemetry collection method.
Regards,
Greg
On Thu, Apr 2, 2020 at 4:16 PM Robert Raszuk wrote:
> > collected only on active paths
>
> Here we clearly diverge :)
>
> The notion of default
> collected only on active paths
Here we clearly diverge :)
The notion of default active paths in my view represents many more
alternative paths constructed based on the default topology while cspf or
flex algo products may consist only of subset of those per applied
constraints.
Thx,
Robert
And another note regarding the use of on-path collected telemetry
information. I'd point that that information is collected only on active
paths. Thus it characterizes the conditions experienced by already existing
flows. Hence it might not be related to a path that the system intends to
Hi Robert,
I think that there's no apparent requirement to collect performance
information form each node in the network in order to select a path with
bounded delay and packet loss. Would you agree?
Regards,
Greg
On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk wrote:
> Hi Joel,
>
> > Robert, you
Hi Joel,
> Robert, you seem to be asking that we pass full information about the
> dynamic network state to all routers
No not at all.
Only TE headends need this information.
To restate ... I am not asking to have a synchronized input to all routes
in the domain such that their computation
Robert, you seem to be asking that we pass full information about the
dynamic network state to all routers so that they can, if needed, serve
as fully intelligent path computation engines. If you want to do that,
you will need more than just the telemetry. You will need the demands
that are
Hi Yali, et al,
thank you for the interesting discussion. I have several questions about
the purpose of advertising ifit capabilities in IGP (and in general):
- Do you see a capability to export telemetry information as a
mandatory or optional?
- Do you expect that a segment route to be
> On Apr 2, 2020, at 6:28 PM, Robert Raszuk wrote:
>
> Well Jeff if you would completely remove CSPF and Flex Algo from IGPs I am
> fully with you.
>
> But till we still have them running in the routers I am of the opinion that
> we need both ... bigger and slower PCE based path computation
Well I did not knock (notify the host and politely ask to join) as I
assumed IETF WG meeting doors should be open. I figured maybe host just
does not like me to join the party :-)
I think my mistake was that I did not expect password to be needed. Learned
something new then !
Cheers,
R.
On Fri,
Robert,
That is why we have a possibility to signal in-band/as per device data that
could be used by PCE to compute a path that meets the constrains (RFC
7471/7810), e.g per node BW reserved/available or cumulative delay, and
similar, computed by the PCE.
However if the objective functions
> > If you consider such constrains to provide reachability for applications
> you will likely see value that in-situ telemetry is your friend here.
> Really best friend as without him you can not do the proper end to end path
> exclusion for SPT computations.
>
> [as wg member] Are you thinking
Hi Chris,
I never noticed the password ...
Just few days back I participated in IDR and no password was needed or
perhaps webex invite link contained a token relaxing from needing one.
Cheers,
R.
On Fri, Apr 3, 2020 at 12:00 AM Christian Hopps wrote:
>
>
> > On Apr 2, 2020, at 5:17 PM,
Hi,
I’d like to comment on the process for moving forward for the abstraction
proposals that we are discussing (TTZ, Area proxy, flooding reduction, …).
My understanding of the block on collaboration is that we are prohibited from
collaborating privately. We MAY have open, public
> On Apr 2, 2020, at 5:17 PM, Robert Raszuk wrote:
>
> Many thx,
> R.
>
> PS. As we are talking LSR here it is strange that joining virtual LSR meeting
> is not for everyone. I was waiting and tried three times today for host
> approval to join which was not granted.
>
I am very sorry
> On Apr 2, 2020, at 5:17 PM, Robert Raszuk wrote:
>
> Jeff.
>
> > The role of a routing protocol is to distribute: reachability (doh :-))
> > and any additional data that could influence routing decision wrt
> > reachability.
>
> The bolded text is precisely the point here.
>
> So let
Jeff.
> The role of a routing protocol is to distribute: reachability (doh :-))
> *and any additional data that could influence routing decision wrt
reachability. *
The bolded text is precisely the point here.
So let me provide a very simple example.
Today routers already compute CSPF.
Les:
Hi!
Just to close this loop: I looked at -12 and we’re good. :-)
I’ll now wait for draft-ietf-ospf-te-link-attr-reuse to catch up to process
both documents together.
Thanks!!
Alvaro.
On March 21, 2020 at 1:09:56 PM, Les Ginsberg (ginsberg) (ginsb...@cisco.com)
wrote:
Following some
Hi Les,
Ok very well.
So till this draft provides a text or reference to some other document how
IGPs may use inband telemetry data for real path selection it does not fit
to LSR charter. Fair.
Hi Chris,
I am afraid we are looking at this from completely different perspectives.
I consider
Robert -
First, +1 to what Chris has said.
There is nothing in the lfit-capability draft that defines any information that
can be used by IGPs to do what you suggest.
Perhaps it is possible that information gleaned via a telemetry application
could be used by the IGPs to do something like what
We have defined a perfectly acceptable and quite powerful way to do query and
configuration for routers, it's YANG. I'd like to hear why the the IETF
standard mechanism for query and configuration can't work for this application.
Telemetry is important, I don't think anyone has said or would
Hi Les,
I would like to respectfully disagree with your assessment.
The fact that today's IGP (or for that matter BGP) routing is static from
the perspective of not taking into consideration real performance
measurements from the data plane to me is a bug not a feature.
Building SPT based on
Yali -
There is a very significant difference between having IGPs advertise an
identifier for a service that they use as clients (BFD) and having IGPs
advertise a set of capabilities/options for a telemetry application which has
no direct bearing on the function of the routing protocol.
You
28 matches
Mail list logo
