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
> 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
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 ...
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
> 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
t;>> 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
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
t 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
>&g
; > >
>> > > 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 would prefer? Yes -
>> bu
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 acceptabl
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 Hopps
> > Cc: lsr@ietf.o
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
> > Subject: 答
sberg)
> ; 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 do no
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-node-cap
; 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 protoc
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
> 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
>
> -邮件原件-
> 发件人: 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-isis-ifit-node-capability-02
>
> Hi
gards,
> 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-isis-ifit-node-c
work.
>
> Best regards,
> Yali
>
> 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> 发送时间: 2020年3月10日 5:07
> 收件人: wangyali ; lsr@ietf.org
> 主题: RE: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
>
> Yali –
>
> What is missing for me
?
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 submitted
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-capab
37 matches
Mail list logo
