Hi Tony,
I think there is still some disconnect - so in an attempt to at least make
sure that we have difference of opinions let me try to restate what I was
suggesting.
IGP would only carry indication if tail can do inband telemetry or not - it
would *not* carry any telemetry data. IGP would not
> Sent: Thursday, April 02, 2020 5:13 AM
> To: Robert Raszuk
> Cc: Christian Hopps ; Les Ginsberg (ginsberg)
> ; wangyali ; Acee Lindem
> (acee) ; lsr@ietf.org; Tianran Zhou
>
> Subject: Re: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02
>
> We
Hi Aijun,
I understand very well what you are trying to achieve and don’t argue the need
for it. My point however - routing protocols are not the most suitable
transport for it.
Regards,
Jeff
> On Apr 2, 2020, at 19:39, Aijun Wang wrote:
>
> Hi, Jeff:
> The draft only propose to transfer t
Ginsberg (ginsberg) ; lsr@ietf.org; Christian Hopps
; Acee Lindem (acee) ; Tianran Zhou
; wangyali
Subject: Re: [Lsr] A new version of I-D,
draft-liu-lsr-isis-ifit-node-capability-02
Jeff.
> The role of a routing protocol is to distribute: reachability (doh :-))
> and any additional data that
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 ... floode
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 distrib
> 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 delive
> "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 active
> 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
O
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
instantiat
Hi Greg,
That is 100% correct. That in fact goes well against the main principle of
end to end path based measurements in the data plane.
Collecting information by all nodes would inherently not include their own
forwarding characteristics so in my books is of very marginal use.
Thx,
R.
On Fri
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 woul
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 c
wrote:
>>> 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 i
u suggest.
>>> Perhaps it is possible that information gleaned via a telemetry
>>> application could be used by the IGPs to do something like what you suggest
>>> - but this draft is not discussing/defining that. It is simply proposing to
>>> advertise information about the capab
t; >
> > > > > > 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
> > > >
> > 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 th
- but this
>> draft is not discussing/defining that. It is simply proposing to advertise
>> information about the capabilities of the lfit application on a given node..
>>
>>Les
>>
>> > -Original Message-
>> > From: Christian Hopps
&
ted attempts to do so.
>> > >
>> > > Everything advertised in Router Capabilities today has some close
>> > relationship with the operation of the protocol. Do some of the existing
>> > advertisements "bend the rules" a bit more than I w
pplication on a given node..
> > >
> > > Les
> > >
> > > > -Original Message-
> > > > From: Christian Hopps
> > > > Sent: Thursday, April 02, 2020 5:13 AM
> > > > To: Robert Raszuk
> > > > Cc: Christian
Message-
> > From: Christian Hopps
> > Sent: Thursday, April 02, 2020 5:13 AM
> > To: Robert Raszuk
> > Cc: Christian Hopps ; Les Ginsberg (ginsberg)
> > ; wangyali ; Acee Lindem
> > (acee) ; lsr@ietf.org; Tianran Zhou
> >
> > Subject: Re: [Lsr] A new
; To: Robert Raszuk
> Cc: Christian Hopps ; Les Ginsberg (ginsberg)
> ; wangyali ; Acee Lindem
> (acee) ; lsr@ietf.org; Tianran Zhou
>
> Subject: Re: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02
>
> We have defined a perfectly acceptable and
t; to decide.
>
> Using IGP Router Capabilities here is wrong in my view.
>
>Les
>
>
> > -----Original Message-----
> > From: wangyali
> > Sent: Wednesday, April 01, 2020 8:12 PM
> > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg)
> > ; Christian
wrong in my view.
>
>Les
>
>
> > -Original Message-
> > From: wangyali
> > Sent: Wednesday, April 01, 2020 8:12 PM
> > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg)
> > ; Christian Hopps
> > Cc: lsr@ietf.org; Tianran Zhou
> >
(ginsberg)
> ; Christian Hopps
> Cc: lsr@ietf.org; Tianran Zhou
> Subject: 答复: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-
> 02
>
> Hi Acee, Chris and Les,
>
> This is Yali. Many thanks for your kind comments and suggestion.
>
>
To: Tianran Zhou ; Christian Hopps
Cc: wangyali ; lsr@ietf.org
Subject: RE: [Lsr] A new version of I-D,
draft-liu-lsr-isis-ifit-node-capability-02
Tianran -
I am very much in agreement with the points Chris has made.
IGPs
rs,
Tianran
-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, April 1, 2020 1:47 PM
To: Tianran Zhou ; Christian Hopps
Cc: wangyali ; lsr@ietf.org
Subject: RE: [Lsr] A new version of I-D,
draft-liu-lsr-isis-ifit-nod
; Christian Hopps
Cc: wangyali ; lsr@ietf.org
Subject: RE: [Lsr] A new version of I-D,
draft-liu-lsr-isis-ifit-node-capability-02
Tianran -
I am very much in agreement with the points Chris has made.
IGPs do not exist to advertise capabilities/configure applications - which
seems to me to be what you
age-
> From: Tianran Zhou
> Sent: Tuesday, March 31, 2020 7:53 PM
> To: Christian Hopps
> Cc: wangyali ; Les Ginsberg (ginsberg)
> ; lsr@ietf.org
> Subject: RE: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02
>
> Hi Chris,
> Thanks for
: Re: [Lsr] A new version of I-D,
draft-liu-lsr-isis-ifit-node-capability-02
> On Mar 31, 2020, at 9:28 PM, Tianran Zhou wrote:
>
> ZTR> Let's not boil the ocean to compare NETCONF/YANG or routing protocol,
> which is better. But I did not see the modification to routing p
Sorry that was "as WG member" btw.
> On Mar 31, 2020, at 9:59 PM, Christian Hopps wrote:
>
>
>
>> On Mar 31, 2020, at 9:28 PM, Tianran Zhou wrote:
>>
>> ZTR> Let's not boil the ocean to compare NETCONF/YANG or routing protocol,
>> which is better. But I did not see the modification to routi
> On Mar 31, 2020, at 9:28 PM, Tianran Zhou wrote:
>
> ZTR> Let's not boil the ocean to compare NETCONF/YANG or routing protocol,
> which is better. But I did not see the modification to routing protocol with
> some TLVs is a heavy work, or more complex than NETCONF/YANG. I see both are
>
> Best regards,
> Yali
>
>
> -邮件原件-
> 发件人: Christian Hopps [mailto:cho...@chopps.org]
> 发送时间: 2020年3月30日 17:48
> 收件人: wangyali
> 抄送: Christian Hopps ; Les Ginsberg (ginsberg)
> ; lsr@ietf.org
> 主题: Re: [Lsr] A new version of I-D, draft-liu-lsr-isi
WG member]
>
> Best regards,
> Yali
>
>
> -邮件原件-
> 发件人: Christian Hopps [mailto:cho...@chopps.org]
> 发送时间: 2020年3月30日 17:48
> 收件人: wangyali
> 抄送: Christian Hopps ; Les Ginsberg (ginsberg)
> ; lsr@ietf.org
> 主题: Re: [Lsr] A new version of I-D, draft-li
this information to all other IGP peers
> when none of them can make use of this information?
>
> Les
>
>
> From: Lsr On Behalf Of wangyali
> Sent: Monday, March 09, 2020 1:21 AM
> To: lsr@ietf.org
> Subject: [Lsr] A new version of I-D,
> draft-liu-
?
Les
From: Lsr On Behalf Of wangyali
Sent: Monday, March 09, 2020 1:21 AM
To: lsr@ietf.org
Subject: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Dear all,
I'm Yali. Following is a new version of I-D,
draft-liu-lsr-isis-ifit-node-capability-02 I subm
Dear all,
I'm Yali. Following is a new version of I-D,
draft-liu-lsr-isis-ifit-node-capability-02 I submitted recently.
Please let me know your questions and comments. Thank you.
>
Name: draft-liu-lsr-isis-ifit-node-capability
Revision: 02
Title: IS-IS
40 matches
Mail list logo
