Subject: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

From: Tianran Zhou <[email-masked]>
Date: Wed, 1 Apr 2020 08:00:16 +0000

Hi Les,

Thanks very much for your suggestion. I have a quick look at rfc6823. Sounds like a good idea. I will think about it.

Cheers,
Tianran

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, April 1, 2020 1:47 PM
To: Tianran Zhou <[email-masked]>; Christian Hopps <[email-masked]>
Cc: wangyali <[email-masked]>; [email-masked]
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 are proposing here.
The fact that you can easily define the encodings does not make it the right thing to do.

This issue was discussed at length in the context of https://tools.ietf.org/html/rfc6823 . If you were proposing to use GENAPP I would not object - though I do think Chris has correctly pointed out that NETCONF/YANG is likely a more appropriate solution for your use case.

   Les

> -----Original Message-----
> From: Tianran Zhou <[email-masked]>
> Sent: Tuesday, March 31, 2020 7:53 PM
> To: Christian Hopps <[email-masked]>
> Cc: wangyali <[email-masked]>; Les Ginsberg (ginsberg) 
> <[email-masked]>; [email-masked]
> Subject: RE: [Lsr] A new version of I-D, 
> draft-liu-lsr-isis-ifit-node-capability-02
> 
> Hi Chris,
> Thanks for your quick reply, and please see inline.
> 
> Cheers,
> Tianran
> 
> -----Original Message-----
> From: Christian Hopps [mailto:[email-masked]]
> Sent: Wednesday, April 1, 2020 10:00 AM
> To: Tianran Zhou <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; wangyali 
> <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; 
> [email-masked]
> Subject: 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 <[email-masked]>
> 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 available and useful.
> 
> I'm not sure what you mean by boiling the ocean. I'm saying that YANG 
> is built and intended for querying capabilities and configuring 
> routers. Why isn't that where you are looking first for configuring your monitoring application?
> 
> ZTR> I know NETCONF can do both query and configuration. And I know
> resent YANG-Push improvements to reduce the polling.  But routing 
> protocol solutions are also widely used for this. There are already 
> many RFCs and implementation practices. We considered both ways, and 
> aimed for different scenarios.
> 
> You don't see the major difference between writing a YANG model vs 
> modifying all of the standard IETF routing protocols?
> 
> ZTR> I know many differences between NETCONF and routing protocol.
> There are many details on both interfaces, implementations, scenarios 
> when comparing them. That's what I mean boil the ocean.
> Here I do not know what's the "major difference" you mean?
> 
> Thanks,
> Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 1 Apr 2020 12:08:25 +0000

There is also a difference between some of the existing applications advertised in IGP capabilities. For example, MSD is used with the routing information to construct SR paths. The information for all these OAM mechanisms doesn't share this affinity. Also, it seems like a slippery slope in what is needed for each of the mechanism. 
Thanks,
Acee

On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Les,

    Cheers,
    Tianran
    
    -----Original Message-----
    From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
    Sent: Wednesday, April 1, 2020 1:47 PM
    To: Tianran Zhou <[email-masked]>; Christian Hopps <[email-masked]>
    Cc: wangyali <[email-masked]>; [email-masked]
    Subject: RE: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
    
    Tianran -

    
    
       Les

    > Here I do not know what's the "major difference" you mean?
    
    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 1 Apr 2020 12:28:35 +0000

Speak as WG Member... 

On 4/1/20, 8:08 AM, "Acee Lindem (acee)" <[email-masked]> wrote:

    
        Hi Les,

        Cheers,
        Tianran
        
        -----Original Message-----
        From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
        Sent: Wednesday, April 1, 2020 1:47 PM
        To: Tianran Zhou <[email-masked]>; Christian Hopps <[email-masked]>
        Cc: wangyali <[email-masked]>; [email-masked]
        Subject: RE: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
        
        Tianran -

        
        
           Les

---

From: wangyali <[email-masked]>
Date: Thu, 2 Apr 2020 03:11:59 +0000

Hi Acee, Chris and Les,

This is Yali. Many thanks for your kind comments and suggestion. 

Besides of signaling MSD by IGP node CAPABILITY TLV, we learned that there's another RFC7883 that advertising S-BFD discriminators in IS-IS. In my understand, BFD is a protocol to detect faults in the bidirectional path between two forwarding engines, including interface, data links, etc.

Similarly, IFIT provides a complete framework of a family of on-path telemetry techniques, which are used to monitoring performance metrics of service flows, e.g. packet loss, delay. So we consider there's a same methodology with S-BFD that advertising IFIT node capabilities.

Please let us know your comments and opinion. Thanks.

Best regards,
Yali

-----邮件原件-----
发件人: Acee Lindem (acee) [mailto:[email-masked]] 
发送时间: 2020年4月1日 20:29
收件人: Tianran Zhou <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>
抄送: [email-masked]; wangyali <[email-masked]>
主题: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Speak as WG Member... 

    
    
        Hi Les,

        Cheers,
        Tianran
        
        -----Original Message-----
        From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
        Sent: Wednesday, April 1, 2020 1:47 PM
        To: Tianran Zhou <[email-masked]>; Christian Hopps <[email-masked]>
        Cc: wangyali <[email-masked]>; [email-masked]
        Subject: RE: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
        
        Tianran -

        
        
           Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 2 Apr 2020 06:31:56 +0000

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 are not the first to find using IGPs to flood application information very convenient.  But this is not the appropriate role for the IGPs and over the years we have consistently resisted 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 would prefer? Yes - but there has always been at least a close relationship to routing protocol function.
Here there is none.

If you feel compelled to use IGPs to advertise application information, you have RF6823 available (at least for IS-IS). But it is a "high bar" since it requires you also to use a separate IS-IS instance dedicated to advertising the application information (see RFC8202).
I think Chris Hopps's suggestion to use Netconf/YANG to configure/retrieve what you need is most likely more attractive - but I will leave that for you to decide.

Using IGP Router Capabilities here is wrong in my view.

   Les

> From: wangyali <[email-masked]>
> Sent: Wednesday, April 01, 2020 8:12 PM
> To: Acee Lindem (acee) <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; Christian Hopps <[email-masked]>
> Cc: [email-masked]; Tianran Zhou <[email-masked]>
> Subject: 答复: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-
> 02
> 
> Hi Acee, Chris and Les,
> 
> Besides of signaling MSD by IGP node CAPABILITY TLV, we learned that
> there's another RFC7883 that advertising S-BFD discriminators in IS-IS. In my
> understand, BFD is a protocol to detect faults in the bidirectional path
> between two forwarding engines, including interface, data links, etc.
> 
> Similarly, IFIT provides a complete framework of a family of on-path
> telemetry techniques, which are used to monitoring performance metrics of
> service flows, e.g. packet loss, delay. So we consider there's a same
> methodology with S-BFD that advertising IFIT node capabilities.
> 
> 收件人: Tianran Zhou <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; Christian Hopps <[email-masked]>
>     There is also a difference between some of the existing applications
> advertised in IGP capabilities. For example, MSD is used with the routing
> information to construct SR paths. The information for all these OAM
> mechanisms doesn't share this affinity. Also, it seems like a slippery slope in
> what is needed for each of the mechanism.
>     Thanks,
>     Acee
> 
>     On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou" <[email-masked]
> on behalf of [email-masked]> wrote:
> 
>         Hi Les,
> 
>         Thanks very much for your suggestion. I have a quick look at rfc6823.
> Sounds like a good idea. I will think about it.
> 
>         Cheers,
>         Tianran
> 
>         IGPs do not exist to advertise capabilities/configure applications - which
> seems to me to be what you are proposing here.
>         This issue was discussed at length in the context of
> https://tools.ietf.org/html/rfc6823 . If you were proposing to use GENAPP I
> would not object - though I do think Chris has correctly pointed out that
> NETCONF/YANG is likely a more appropriate solution for your use case.
> 
>            Les
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 2 Apr 2020 11:17:52 +0200

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 static link metrics which in vast majority of cases
today are emulated circuits on someone else IP backbone. It was a great
idea when you constructed the network with connection oriented paradigm
(Sonet,SDH, dark fiber, TDM ...) not connection less often best effort one.

So I find this proposal very useful and would vote for adopting it in LSR
WG. To me in-situ telemetry is not just some monitoring tool. It is an
extremely important element to influence how we compute reachability or at
least how we choose active forwarding paths from protocol RIBs to main RIB.

If we extended IGPs to carry TE information, if we extended them to enable
flexible algorithm based path computation I fail to understand why would we
resist to natively enable all of the above with getting the inputs from
real networks to be used as to the parameters to the above mentioned tools.

Kind regards,
R.

On Thu, Apr 2, 2020 at 8:32 AM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> 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 are not the first to find using IGPs to flood application information
> very convenient.  But this is not the appropriate role for the IGPs and
> over the years we have consistently resisted 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 would prefer? Yes - but
> there has always been at least a close relationship to routing protocol
> function.
> Here there is none.
>
> If you feel compelled to use IGPs to advertise application information,
> you have RF6823 available (at least for IS-IS). But it is a "high bar"
> since it requires you also to use a separate IS-IS instance dedicated to
> advertising the application information (see RFC8202).
> I think Chris Hopps's suggestion to use Netconf/YANG to configure/retrieve
> what you need is most likely more attractive - but I will leave that for
> you to decide.
>
> > 主题: Re: [Lsr] A new version of I-D,
> >         The fact that you can easily define the encodings does not make
> it the
> > right thing to do.
> >
> >         > routers. Why isn't that where you are looking first for
> configuring your
> > monitoring application?
> >         >
> >         > many RFCs and implementation practices. We considered both
> ways,
> > and

---

From: Christian Hopps <[email-masked]>
Date: Thu, 2 Apr 2020 08:12:44 -0400

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 say that it isn't, but that seems orthogonal to this discussion.

Thanks,
Chris.
[as WG member]

> On Apr 2, 2020, at 5:17 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Les,
> 
> 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 static link metrics which in vast majority of cases today are emulated circuits on someone else IP backbone. It was a great idea when you constructed the network with connection oriented paradigm (Sonet,SDH, dark fiber, TDM ...) not connection less often best effort one. 
> 
> So I find this proposal very useful and would vote for adopting it in LSR WG. To me in-situ telemetry is not just some monitoring tool. It is an extremely important element to influence how we compute reachability or at least how we choose active forwarding paths from protocol RIBs to main RIB. 
> 
> If we extended IGPs to carry TE information, if we extended them to enable flexible algorithm based path computation I fail to understand why would we resist to natively enable all of the above with getting the inputs from real networks to be used as to the parameters to the above mentioned tools. 
> 
> Kind regards,
> R.
> 
> On Thu, Apr 2, 2020 at 8:32 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> Yali -
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 2 Apr 2020 12:46:53 +0000

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 you suggest - 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

> From: Christian Hopps <[email-masked]>
> Sent: Thursday, April 02, 2020 5:13 AM
> To: Robert Raszuk <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; wangyali <[email-masked]>; Acee Lindem
> (acee) <[email-masked]>; [email-masked]; Tianran Zhou
> <[email-masked]>
> Subject: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
> 
> 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 say that it isn't,
> but that seems orthogonal to this discussion.
> 
> Thanks,
> Chris.
> [as WG member]
> 
> 
> > 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.
> >
> today are emulated circuits on someone else IP backbone. It was a great idea
> when you constructed the network with connection oriented paradigm
> > So I find this proposal very useful and would vote for adopting it in LSR WG.
> To me in-situ telemetry is not just some monitoring tool. It is an extremely
> important element to influence how we compute reachability or at least how
> we choose active forwarding paths from protocol RIBs to main RIB.
> >
> > If we extended IGPs to carry TE information, if we extended them to
> enable flexible algorithm based path computation I fail to understand why
> would we resist to natively enable all of the above with getting the inputs
> from real networks to be used as to the parameters to the above mentioned
> tools.
> >
> > Kind regards,
> > R.
> >
> > On Thu, Apr 2, 2020 at 8:32 AM Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]> wrote:
> > Yali -
> >
> advertise a set of capabilities/options for a telemetry application which has
> no direct bearing on the function of the routing protocol.
> >
> > You are not the first to find using IGPs to flood application information very
> convenient.  But this is not the appropriate role for the IGPs and over the
> years we have consistently resisted attempts to do so.
> >
> > If you feel compelled to use IGPs to advertise application information, you
> have RF6823 available (at least for IS-IS). But it is a "high bar" since it requires
> you also to use a separate IS-IS instance dedicated to advertising the
> application information (see RFC8202).
> what you need is most likely more attractive - but I will leave that for you to
> decide.
> >
> > >         The fact that you can easily define the encodings does not make it
> the
> > > right thing to do.
> > >
> > >         > routers. Why isn't that where you are looking first for configuring
> your
> > > monitoring application?
> > >         >

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 2 Apr 2020 09:11:03 -0400

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 this data to be a necessity for routing and you simply treat it
as some opaque telemetry. If we would think of it in the latter sense sure
you would be right. IGP is not a configuration push protocol. Sufficient to
observe how BGP became one :)

Many thx,
R.

On Thu, Apr 2, 2020 at 8:46 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> 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 you suggest
> - 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
>
> idea
> you to
> > > > Subject: 答复: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-
> > capability-
> > > > 02
> > > >
> > > > Hi Acee, Chris and Les,
> > > >
> > > > there's another RFC7883 that advertising S-BFD discriminators in
> IS-IS. In
> > my
> > > > telemetry techniques, which are used to monitoring performance
> metrics
> > of
> > > > mechanisms doesn't share this affinity. Also, it seems like a
> slippery slope
> > in
> > > >         IGPs do not exist to advertise capabilities/configure
> applications -
> > which
> > > >         > routing protocol with some TLVs is a heavy work, or more
> complex
> > than
> > > >         > I'm not sure what you mean by boiling the ocean. I'm
> saying that
> > YANG
> configuring
> > > >         > ZTR> I know NETCONF can do both query and configuration.
> And I
> > > > know
> > > >         > You don't see the major difference between writing a YANG
> model
> > vs

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 2 Apr 2020 14:00:26 -0700

Robert,

This is unnecessary leakage of management plane into control plane.
The role of a routing protocol is to distribute: reachability (doh :-)) and any additional data that could influence routing decision wrt reachability.
There are precedences of using IGP’s for different tasks, e.g. RFC 5088 and similar, however should we do it again?

Specifically to use case described - I really don’t see how this information would be used in routing decisions (PCE computation). Moreover, if the end-goal is to build a connected graph of the devices that have a coherent iFIT feature set it would require reoptimization on every change and quite complex computation logic (talking SR - on top of regular constrains, MSD, etc).I’d also think that there’s mandatory configuration of name-spaces and features supported, in other words - autodiscovery is meaningless, it would still require as per device configuration (hello YANG). Most of telemetry solutions are designed to pass thought nodes that don’t support it transparently, so the real requirement is really to know the sink-node (the one that is egress of the telemetry domain and must remove all additional encapsulations).

As to the last point - we already have a kitchen-sink routing protocol  ;-)

Cheers,
Jeff
On Apr 2, 2020, 6:10 AM -0700, Robert Raszuk <[email-masked]>, wrote:
>
> 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 consider this data to be a necessity for routing and you simply treat it as some opaque telemetry. If we would think of it in the latter sense sure you would be right. IGP is not a configuration push protocol. Sufficient to observe how BGP became one :)
>
> Many thx,
> R.
>
>
> > On Thu, Apr 2, 2020 at 8:46 AM Les Ginsberg (ginsberg) <[email-masked]> wrote:
> > > Robert -
> > >
> > > 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 capabilities of the lfit application on a given node..
> > >
> > >    Les
> > >
> > > > (acee) <[email-masked]>; lsr@ietf..org; Tianran Zhou
> > > > <[email-masked]>
> > > > > >         > -----Original Message-----
> > > > > >         > From: Tianran Zhou <[email-masked]>
> > > > > >         > Sent: Tuesday, March 31, 2020 7:53 PM
> > > > > >         > To: Christian Hopps <[email-masked]>
> > > > > >         > Cc: wangyali <[email-masked]>; Les Ginsberg (ginsberg)
> > > > > >         > <[email-masked]>; [email-masked]
> > > > > >         > Subject: RE: [Lsr] A new version of I-D,
> > > > > >         > draft-liu-lsr-isis-ifit-node-capability-02
> > > > > >         >
> > > > > >         > Hi Chris,
> > > > > >         > Thanks for your quick reply, and please see inline.
> > > > > >         >
> > > > > >         > Cheers,
> > > > > >         > Tianran
> > > > > >         >
> > > > > >         > -----Original Message-----
> > > > > >         > From: Christian Hopps [mailto:[email-masked]]
> > > > > >         > Sent: Wednesday, April 1, 2020 10:00 AM
> > > > > >         > To: Tianran Zhou <[email-masked]>
> > > > > >         > Cc: Christian Hopps <[email-masked]>; wangyali
> > > > > >         > <[email-masked]>; Les Ginsberg (ginsberg)
> > > > > > <[email-masked]>;
> > > > > >         > [email-masked]
> > > > > >         > Subject: 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
> > > > > > <[email-masked]>
> > > > > >         > 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 available and useful.
> > > > > >         >
> > > > > >         > I'm not sure what you mean by boiling the ocean. I'm saying that
> > > > YANG
> > > > > >         > is built and intended for querying capabilities and configuring
> > > > > >         > routers. Why isn't that where you are looking first for configuring
> > > > your
> > > > > > monitoring application?
> > > > > >         >
> > > > > >         > ZTR> I know NETCONF can do both query and configuration. And I
> > > > > > know
> > > > > >         > resent YANG-Push improvements to reduce the polling.  But
> > > > routing
> > > > > >         > protocol solutions are also widely used for this. There are already
> > > > > >         > many RFCs and implementation practices. We considered both
> > > > ways,
> > > > > > and
> > > > > >         > aimed for different scenarios.
> > > > > >         >
> > > > > >         > You don't see the major difference between writing a YANG model
> > > > vs
> > > > > >         > modifying all of the standard IETF routing protocols?
> > > > > >         >
> > > > > >         > ZTR> I know many differences between NETCONF and routing
> > > > > > protocol.
> > > > > >         > There are many details on both interfaces, implementations,
> > > > scenarios
> > > > > >         > when comparing them. That's what I mean boil the ocean.
> > > > > >         > Here I do not know what's the "major difference" you mean?
> > > > > >         >
> > > > > >         > Thanks,
> > > > > >         > Chris.
> > > > > >
> > > > > >         https://www..ietf.org/mailman/listinfo/lsr
> > > > > >
> > > > > >
> > > > > >
> > > > >

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 2 Apr 2020 23:17:13 +0200

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. Moreover today routers are asked to use
custom/flexible algorithm to choose reachability paths.

So just imagine an operator who says:

Please compute my SPT with the consideration that end to end inband jitter
is not greater then 10 ms otherwise I do not want to see nodes which do not
meet that criteria in the reachability graph for application X.

or

Please compute my SPT with the consideration that end to end drop rate is
not greater then  5pps otherwise I do not want to see nodes which do not
meet that criteria in the reachability graph for application Y.

etc ...

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.

Hint: All per link extensions which were added to IGPs are not going to
help here as drops or jitter may equally happen in the routers fabric on
fabric to LC boundaries or on the line cards and links. So you need end to
end test stream.

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.

On Thu, Apr 2, 2020 at 11:00 PM Jeff Tantsura <[email-masked]>
wrote:

> The role of a routing protocol is to distribute: reachability (doh :-))
> and any additional data that could influence routing decision wrt
> reachability.
> There are precedences of using IGP’s for different tasks, e.g. RFC 5088
> and similar, however should we do it again?
>
> Specifically to use case described - I really don’t see how this
> information would be used in routing decisions (PCE computation). Moreover,
> if the end-goal is to build a connected graph of the devices that have a
> coherent iFIT feature set it would require reoptimization on every change
> and quite complex computation logic (talking SR - on top of regular
> constrains, MSD, etc).I’d also think that there’s mandatory configuration
> of name-spaces and features supported, in other words - autodiscovery is
> meaningless, it would still require as per device configuration (hello
> YANG). Most of telemetry solutions are designed to pass thought nodes that
> don’t support it transparently, so the real requirement is really to know
> the sink-node (the one that is egress of the telemetry domain and must
> remove all additional encapsulations).
>
>> There is nothing in the lfit-capability draft that defines any
>> information that can be used by IGPs to do what you suggest.
>> given node..
>> > (acee) <[email-masked]>; lsr@ietf..org <[email-masked]>; Tianran Zhou
>> > <[email-masked]>
>> > > > capability-02
>> > > >         > There are many details on both interfaces,
>> implementations,
>> > scenarios
>> <https://www.ietf..org/mailman/listinfo/lsr>
>> > > >
>> > > >
>> > > >
>> > >

---

From: Christian Hopps <[email-masked]>
Date: Thu, 2 Apr 2020 17:56:46 -0400

> On Apr 2, 2020, at 5:17 PM, Robert Raszuk <[email-masked]> wrote:
> 
> Jeff.
> 
> > and any additional data that could influence routing decision wrt reachability.  
> 
> Today routers already compute CSPF. Moreover today routers are asked to use custom/flexible algorithm to choose reachability paths. 
> 
> Please compute my SPT with the consideration that end to end inband jitter is not greater then 10 ms otherwise I do not want to see nodes which do not meet that criteria in the reachability graph for application X.
> 
> or 
> 
> Please compute my SPT with the consideration that end to end drop rate is not greater then  5pps otherwise I do not want to see nodes which do not meet that criteria in the reachability graph for application Y. 
> 
> etc ... 
> 
> 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 that shifting traffic to a router is not going to affect it's jitter/drop rate?

> Hint: All per link extensions which were added to IGPs are not going to help here as drops or jitter may equally happen in the routers fabric on fabric to LC boundaries or on the line cards and links. So you need end to end test stream. 
> 
> 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. 

will reply separately to this.

Thanks,
Chris.

> 
> On Thu, Apr 2, 2020 at 11:00 PM Jeff Tantsura <[email-masked]> wrote:
> Robert,
>

---

From: Christian Hopps <[email-masked]>
Date: Thu, 2 Apr 2020 18:00:03 -0400

> 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 to hear this! We had 64 participants, at least at one point that I saw. I set the meeting up, and I don't believe there is any way to exclude anyone in particular, I certainly would never have chosen to do that.

However, Webex has a password requirement when setting up meetings (I guess, I tried to not have one, it wouldn't let me) which we included in all the details wherever the details were posted, it was "linkstate".

I did notice an email, from webex, during the meeting about a request from Bruno to join as guest, but he was in the participant list when I then checked. I didn't receive any other emails like that (and FWIW I had 5 windows over 2 monitors going at once trying to manage all this, so noticing the 1 email was lucky).

Did it let you skip entering a password (or did it not offer the option in the first place)?

It would be good to figure this out before the next interim.

Thanks,
Chris.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 3 Apr 2020 00:09:55 +0200

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 <[email-masked]> wrote:

> I am very sorry to hear this! We had 64 participants, at least at one
> point that I saw. I set the meeting up, and I don't believe there is any
> way to exclude anyone in particular, I certainly would never have chosen to
> do that.
>
> However, Webex has a password requirement when setting up meetings (I
> guess, I tried to not have one, it wouldn't let me) which we included in
> all the details wherever the details were posted, it was "linkstate".
>
> I did notice an email, from webex, during the meeting about a request from
> Bruno to join as guest, but he was in the participant list when I then
> checked. I didn't receive any other emails like that (and FWIW I had 5
> windows over 2 monitors going at once trying to manage all this, so
> noticing the 1 email was lucky).
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 3 Apr 2020 00:16:55 +0200

> going to affect it's jitter/drop rate?

Well this is actually the other way around.

First you have your default topology. They you are asked to construct new
one based on applied constrains.

So you create complete TE coverage and start running end to end data plane
probing over all TE paths (say SR-TE for specific example). Once you start
collecting the probe results you can start excluding paths which do not
meet your applied constraints. And that process continues.

To your specific question - It is not that unusual where routers degrade
their performance with time and in many cases the traffic is not the cause
for it but internal bugs and malfunctions.

Best,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 2 Apr 2020 22:21:38 +0000

As host of the meeting, I didn’t see any indication that you were waiting in the lobby.
Thanks,
Acee

From: Robert Raszuk <[email-masked]>
Date: Thursday, April 2, 2020 at 6:10 PM
To: Christian Hopps <[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, Jeff Tantsura <[email-masked]>, Tianran Zhou <[email-masked]>, Acee Lindem <[email-masked]>, wangyali <[email-masked]>
Subject: Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

Hi Chris,

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 <[email-masked]<mailto:[email-masked]>> wrote:

> On Apr 2, 2020, at 5:17 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
>
> Many thx,
> R.
>

Thanks,
Chris.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 2 Apr 2020 15:24:18 -0700

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 used by CSPF are coming from outside (end2end latency measurement/$$ of a link  as an example) we don’t feed them back into IGP, telemetry analysis (done by an external system) are of no business of IGP and should be fed (normalized) into PCE directly.
We are not discussing the value of telemetry, which is obvious, but need to autodiscover telemetry capability’s and feed (pollute) them into IGP->BGP-LS->controller.
I don’t see how this information would be used in route/path computation and hence IMHO it doesn’t belong in IGP. Given the need for configuration (besides ability to support particular technology) makes this a clear candidate for management plane operations. (Chris’ comment about YANG)

Cheers,
Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 3 Apr 2020 00:28:49 +0200

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 and
sufficient information (not only static data) for routers itself to be able
to adjust forwarding state based on the live path constraints.

I realize I am thinking outside of the box here but hopefully one day this
will become a norm rather then abstraction :)

Best,
R.,

On Fri, Apr 3, 2020 at 12:24 AM Jeff Tantsura <[email-masked]>
wrote:

> 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 used by CSPF are coming from outside
> (end2end latency measurement/$$ of a link  as an example) we don’t feed
> them back into IGP, telemetry analysis (done by an external system) are of
> no business of IGP and should be fed (normalized) into PCE directly.
> We are not discussing the value of telemetry, which is obvious, but need
> to autodiscover telemetry capability’s and feed (pollute) them into
> IGP->BGP-LS->controller.
> I don’t see how this information would be used in route/path computation
> and hence IMHO it doesn’t belong in IGP. Given the need for configuration
> (besides ability to support particular technology) makes this a clear
> candidate for management plane operations. (Chris’ comment about YANG)
>
> Cheers,
> Jeff
> Today routers already compute CSPF. Moreover today routers are asked to
> use custom/flexible algorithm to choose reachability paths.
>
>> 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 consider this data to be a necessity for routing and you simply treat
>> it as some opaque telemetry. If we would think of it in the latter sense
>> sure you would be right. IGP is not a configuration push protocol.
>> Sufficient to observe how BGP became one :)
>>
>> Many thx,
>> R.
>>
>>
>>> > > >         > > ZTR> Let's not boil the ocean to compare NETCONF/YANG
>>> or
>>> > routing
>>> > > >         > You don't see the major difference between writing a
>>> YANG model
>>> > vs

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 3 Apr 2020 00:34:32 +0200

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, Apr 3, 2020 at 12:22 AM Acee Lindem (acee) <[email-masked]> wrote:

> *From: *Robert Raszuk <[email-masked]>
> *Date: *Thursday, April 2, 2020 at 6:10 PM
> *To: *Christian Hopps <[email-masked]>
> *Cc: *"Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <
> [email-masked]>, Jeff Tantsura <[email-masked]>, Tianran Zhou <
> [email-masked]>, Acee Lindem <[email-masked]>, wangyali <
> [email-masked]>
> *Subject: *Re: [Lsr] problem joining interim [Re: A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02]
>
>
>
> Hi Chris,
>
>
>

---

From: Christian Hopps <[email-masked]>
Date: Thu, 2 Apr 2020 18:49:14 -0400

> On Apr 2, 2020, at 6:28 PM, Robert Raszuk <[email-masked]> 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 and sufficient information (not only static data) for routers itself to be able to adjust forwarding state based on the live path constraints. 
> 
> I realize I am thinking outside of the box here but hopefully one day this will become a norm rather then abstraction :)

You don't need the IGP advertising this stuff in order to do anything you've suggested.

Thanks,
Chris.
[as WG member]

> Best,
> R.,
> 
> On Fri, Apr 3, 2020 at 12:24 AM Jeff Tantsura <[email-masked]> wrote:
> Robert,
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Apr 2020 15:57:32 -0700

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 constructed to prefer
   ifit-capable nodes comparing to nodes that are not?

Thank you for your kind consideration of my questions.

Regards,
Greg

On Wed, Apr 1, 2020 at 8:13 PM wangyali <[email-masked]> wrote:

> there's another RFC7883 that advertising S-BFD discriminators in IS-IS. In
> my understand, BFD is a protocol to detect faults in the bidirectional path
> 收件人: Tianran Zhou <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; Christian Hopps <[email-masked]>
> mechanisms doesn't share this affinity. Also, it seems like a slippery
> slope in what is needed for each of the mechanism.
>     Thanks,
>     Acee
>
>     On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>         Hi Les,
>
>         Thanks very much for your suggestion. I have a quick look at
> rfc6823. Sounds like a good idea. I will think about it.
>
>         Cheers,
>         Tianran
>
>         IGPs do not exist to advertise capabilities/configure applications
> - which seems to me to be what you are proposing here.
> the right thing to do.
> https://tools.ietf.org/html/rfc6823 . If you were proposing to use GENAPP
> I would not object - though I do think Chris has correctly pointed out that
> configuring your monitoring application?
>         >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 2 Apr 2020 18:59:19 -0400

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 coming in to all of those routers, so that you can make global 
decisions sensibly.
Which is why we use quasi-centralized path computation engines.

Yours,
Joel

On 4/2/2020 6:16 PM, Robert Raszuk wrote:
> 
>      > 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 that shifting traffic to a router is
>     not going to affect it's jitter/drop rate?
> 
> 
> First you have your default topology. They you are asked to 
> construct new one based on applied constrains.
> 
> So you create complete TE coverage and start running end to end data 
> plane probing over all TE paths (say SR-TE for specific example). Once 
> you start collecting the probe results you can start excluding paths 
> which do not meet your applied constraints. And that process continues.
> 
> their performance with time and in many cases the traffic is not the 
> cause for it but internal bugs and malfunctions.
> 
> Best,
> R.
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 3 Apr 2020 01:03:23 +0200

Hi Joel,

> 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 would be consistent.

I am only asking for TE headends to be able to select end to end paths
based on the end to end inband telemetry data. I find this a useful
requirement missing from any of today's operational deployments.

Many thx,
R.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Apr 2020 16:08:44 -0700

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 <[email-masked]> wrote:

>> > which do not meet your applied constraints. And that process continues..
>> >

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 3 Apr 2020 01:11:48 +0200

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.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Apr 2020 16:13:32 -0700

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
instantiate. One needs active OAM to collect such information.

Regards,
Greg

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 3 Apr 2020 01:16:47 +0200

> 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

On Fri, Apr 3, 2020 at 1:13 AM Greg Mirsky <[email-masked]> wrote:

>>> To restate ... I am not asking to have a synchronized input to all
>>> routes in the domain such that their computation would be consistent.
>>>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Apr 2020 16:22:12 -0700

Hi Robert,
"collected only on active paths" is not something I propose but is the
property of on-path telemetry collection method.

Regards,
Greg

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 3 Apr 2020 01:32:31 +0200

> "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 topology may have N active paths while
application specific topologies M where M is a subset of N meeting required
end to end constraints.

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 delivering
such type of services.

Kind regards,
R.

---

From: [email-masked]
Date: Thu, 2 Apr 2020 16:43:04 -0700

> 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 delivering such type of services. 

AFAICT, we put a lot of effort into making headend path computation useful and, for the most part, it was and is not necessary.

Even with legacy mechanisms, people decided that they need global optimization and that head-end path computation was Not That Interesting.

It’s now 20 years later, the network is even more dynamic, the expectations about response time are that much higher, and concerns about link state database stability and scalability have increased.  Modern telemetry is definitely not suitable to be passed in the IGP anymore.  

Thus, it seems like the IGP can provide base topology information and traffic engineering constructs should leverage that and provide an independent telemetry collection plane. Within that plane, telemetry capabilities can and should be confined to the telemetry plane.

As we’ve said many times before: BGP is not a dump truck. Analogously, the IGP isn’t even an SUV.

;-)

Regards,
Tony

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 2 Apr 2020 17:18:35 -0700

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 distributed PCE or anything else that could make use of it. Do you see IGP anywhere in between?

Regards,
Jeff

> On Apr 2, 2020, at 16:03, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Joel,
> 
> To restate ... I am not asking to have a synchronized input to all routes in the domain such that their computation would be consistent. 
> 
> I am only asking for TE headends to be able to select end to end paths based on the end to end inband telemetry data. I find this a useful requirement missing from any of today's operational deployments. 
> 
> Many thx,
> R. 
> 
> 
> 
> 
> 
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Apr 2020 17:27:27 -0700

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 ... flooded using IGP (no, I
didn't say that!).

Regards,
Greg

On Thu, Apr 2, 2020 at 5:19 PM Jeff Tantsura <[email-masked]>
wrote:

> 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 distributed PCE or anything else that
> could make use of it. Do you see IGP anywhere in between?
>
>
> Regards,
> Jeff
>
>> > which do not meet your applied constraints. And that process
>> continues...
>> >

---

From: Aijun Wang <[email-masked]>
Date: Fri, 3 Apr 2020 10:38:58 +0800

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.

Aijun Wang
China Telecom

> On Apr 3, 2020, at 08:20, Jeff Tantsura <[email-masked]> wrote:
> 
> Robert, 
> 
> We are deviating ;-)
> 
>>> > which do not meet your applied constraints. And that process continues...
>>> >

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 3 Apr 2020 06:22:59 +0000

Hi Robert,

You provide the perfect examples. That is exactly what we want to do with the IFIT control plane.
While we used to consider resources as the cost(static or dynamic) for the path computation, here we also need to consider the IFIT capability that the node can support.
We want to achieve the SLA assurance network, not only we can compute a best performance path, but also we can provide corresponding SLA visibility and measurement on this path.

Cheers,
Tianran

From: Robert Raszuk [mailto:[email-masked]]
Sent: Friday, April 3, 2020 5:17 AM
To: Jeff Tantsura <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; Christian Hopps <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Tianran Zhou <[email-masked]>; wangyali <[email-masked]>
Subject: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Jeff.

or

etc ...

Many thx,
R.

On Thu, Apr 2, 2020 at 11:00 PM Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Cheers,
Jeff
On Apr 2, 2020, 6:10 AM -0700, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, wrote:

Hi Les,

Ok very well.

Hi Chris,

Many thx,
R.

On Thu, Apr 2, 2020 at 8:46 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert -

   Les

> From: Christian Hopps <[email-masked]<mailto:[email-masked]>>
> To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
> Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg)
> <[email-masked]<mailto:[email-masked]>>; wangyali <[email-masked]<mailto:[email-masked]>>; Acee Lindem
> (acee) <[email-masked]<mailto:[email-masked]>>; lsr@ietf..org<mailto:[email-masked]>; Tianran Zhou
> <[email-masked]<mailto:[email-masked]>>
> > On Apr 2, 2020, at 5:17 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi Les,
> >
> <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
> > Yali -
> >
> > > From: wangyali <[email-masked]<mailto:[email-masked]>>
> > > To: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg)
> > > <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>
> > > Cc: [email-masked]<mailto:[email-masked]>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>
> > > 发件人: Acee Lindem (acee) [mailto:[email-masked]<mailto:[email-masked]>]
> > > 发送时间: 2020年4月1日 20:29
> > > 收件人: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Les Ginsberg
> (ginsberg)
> > > <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>
> > > 抄送: [email-masked]<mailto:[email-masked]>; wangyali <[email-masked]<mailto:[email-masked]>>
> > > On 4/1/20, 8:08 AM, "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > >     On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou" <lsr-
> [email-masked]<mailto:[email-masked]>
> > > on behalf of [email-masked]<mailto:[email-masked]>> wrote:
> > >
> > >         Hi Les,
> > >
> > >         From: Les Ginsberg (ginsberg) [mailto:[email-masked]<mailto:[email-masked]>]
> > >         To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Christian Hopps
> > > <[email-masked]<mailto:[email-masked]>>
> > >         Cc: wangyali <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > >         > From: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
> > >         > To: Christian Hopps <[email-masked]<mailto:[email-masked]>>
> > >         > Cc: wangyali <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg)
> > >         > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > >         > From: Christian Hopps [mailto:[email-masked]<mailto:[email-masked]>]
> > >         > To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
> > >         > Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>; wangyali
> > >         > <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg)
> > > <[email-masked]<mailto:[email-masked]>>;
> > >         > [email-masked]<mailto:[email-masked]>
> > >         > > On Mar 31, 2020, at 9:28 PM, Tianran Zhou
> > > <[email-masked]<mailto:[email-masked]>>
> > >         > wrote:
> > >         > >
> > >         https://www..ietf.org/mailman/listinfo/lsr<https://www.ietf..org/mailman/listinfo/lsr>
> > >
> > >
> > >
> >

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 3 Apr 2020 06:33:37 +0000

Hi Greg,

Good questions. Please see my reply in line.

Thanks,
Tianran

From: Greg Mirsky [mailto:[email-masked]]
Sent: Friday, April 3, 2020 6:58 AM
To: wangyali <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]; Tianran Zhou <[email-masked]>
Subject: Re: [Lsr] 答复: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

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?
What’s the context with this question? Frankly, I did not have a deep well thinking on this question. But in our case, I wish it’s mandatory.

  *   Do you expect that a segment route to be constructed to prefer ifit-capable nodes comparing to nodes that are not?
Yes. This is one use case. As my echo to Robert, we want to achieve the SLA assurance network. We think the capability for visibility to verify the SLA compliance, and also the capability to get the accurate measurement for path computation should be considered. Should be considered from the very beginning when we compute the path.
Thank you for your kind consideration of my questions.

Regards,
Greg

On Wed, Apr 1, 2020 at 8:13 PM wangyali <[email-masked]<mailto:[email-masked]>> wrote:
Hi Acee, Chris and Les,

Best regards,
Yali

-----邮件原件-----
发件人: Acee Lindem (acee) [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2020年4月1日 20:29
收件人: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>; wangyali <[email-masked]<mailto:[email-masked]>>
主题: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Speak as WG Member...

    On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

        Hi Les,

        Cheers,
        Tianran

        -----Original Message-----
        From: Les Ginsberg (ginsberg) [mailto:[email-masked]<mailto:[email-masked]>]
        Sent: Wednesday, April 1, 2020 1:47 PM
        To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>
        Cc: wangyali <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
        Subject: RE: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

        Tianran -

           Les

        > <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>;
        > > On Mar 31, 2020, at 9:28 PM, Tianran Zhou <[email-masked]<mailto:[email-masked]>>
        > wrote:
        > >

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 2 Apr 2020 23:43:06 -0700

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 <[email-masked]> wrote:
> 
> Hi, Jeff:

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 3 Apr 2020 07:32:36 +0000

Hi Les,

Please let me justify.
IMHO, compute a path based on the IFIT capability is the first step that we can correctly get the in-situ telemetry information.
And then, based on the reactive control mentioned in the IFIT framework, we can adjust/re-compute the path according to the update of the telemetry information.

Tianran

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Thursday, April 2, 2020 8:47 PM
To: Christian Hopps <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: wangyali <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]; Tianran Zhou <[email-masked]>
Subject: RE: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Robert -

   Les

> 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 say 
> that it isn't, but that seems orthogonal to this discussion.
> 
> Thanks,
> Chris.
> [as WG member]
> 
> 
> perspective of not taking into consideration real performance 
> today are emulated circuits on someone else IP backbone. It was a 
> great idea when you constructed the network with connection oriented 
> paradigm (Sonet,SDH, dark fiber, TDM ...) not connection less often best effort one.
> >
> To me in-situ telemetry is not just some monitoring tool. It is an 
> extremely important element to influence how we compute reachability 
> or at least how we choose active forwarding paths from protocol RIBs to main RIB.
> >
> enable flexible algorithm based path computation I fail to understand 
> why would we resist to natively enable all of the above with getting 
> the inputs from real networks to be used as to the parameters to the 
> above mentioned tools.
> >
> > Kind regards,
> > R.
> >
> 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.
> >
> convenient.  But this is not the appropriate role for the IGPs and 
> relationship with the operation of the protocol. Do some of the 
> existing advertisements "bend the rules" a bit more than I would 
> prefer? Yes - but there has always been at least a close relationship 
> to routing protocol function.
> > Here there is none.
> >
> have RF6823 available (at least for IS-IS). But it is a "high bar" 
> since it requires you also to use a separate IS-IS instance dedicated 
> to advertising the application information (see RFC8202).
> what you need is most likely more attractive - but I will leave that 
> for you to decide.
> >
> > > Besides of signaling MSD by IGP node CAPABILITY TLV, we learned 
> > > that there's another RFC7883 that advertising S-BFD discriminators 
> > > in IS-IS. In
> my
> > > understand, BFD is a protocol to detect faults in the 
> > > bidirectional path between two forwarding engines, including interface, data links, etc.
> > >
> > > Similarly, IFIT provides a complete framework of a family of 
> > > on-path telemetry techniques, which are used to monitoring 
> > > performance metrics
> of
> > > service flows, e.g. packet loss, delay. So we consider there's a 
> > > same methodology with S-BFD that advertising IFIT node capabilities.
> > >
> > >     There is also a difference between some of the existing 
> > > applications advertised in IGP capabilities. For example, MSD is 
> > > used with the routing information to construct SR paths. The 
> > > information for all these OAM mechanisms doesn't share this 
> > > affinity. Also, it seems like a slippery slope
> in
> [email-masked]
> > > would not object - though I do think Chris has correctly pointed 
> > > out that NETCONF/YANG is likely a more appropriate solution for your use case.
> > >
> > >            Les
> > >
> > >
> > > And I know
> > >         > resent YANG-Push improvements to reduce the polling.  
> > > But
> routing

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 3 Apr 2020 11:59:24 +0200

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 be running telemetry -
it will be just consumer of other subsystem product.
https://tools.ietf.org/html/draft-wang-lsr-ifit-node-capability-advertisement-00
just signals capability. It does not even have a trunk for any type of dump
:)

Global optimization makes a lot of sense for traffic spread across given
network - 100%. But it is not the best place to only select if one path is
eligible and the other is not in given topology. That decision should
happen on the headends and should be as much distributed as possible. And
the data here as input to the decision is only valid on specific headend
probes depart from. Besides it has usually a very short life.

Even if we move cspf to historic just very recently flexible algorithm was
proposed and I think is progressing fine. So my examples of use cases to
choose paths with min drops or bound jitter are real.

Hi Jeff,

If I look at one of the in situ data plane proposals it does send the
results to the sender/originator vs some
collector. draft-lapukhov-dataplane-probe-01 This is besides the point of
this discussion as we are not asking for IGP to carry the results. Hint:
Each headend can be a collector or nothing breaks in the design if headend
get's this data out of band from central collector.

Thx,
R.

On Fri, Apr 3, 2020 at 1:43 AM <[email-masked]> wrote:

> AFAICT, we put a lot of effort into making headend path computation useful
> and, for the most part, it was and is not necessary.
>
> Even with legacy mechanisms, people decided that they need global
> optimization and that head-end path computation was Not That Interesting.
>
> It’s now 20 years later, the network is even more dynamic, the
> expectations about response time are that much higher, and concerns about
> link state database stability and scalability have increased.  Modern
> telemetry is definitely not suitable to be passed in the IGP anymore.
>
> Thus, it seems like the IGP can provide base topology information and
> traffic engineering constructs should leverage that and provide an
> independent telemetry collection plane. Within that plane, telemetry
> capabilities can and should be confined to the telemetry plane.
>

---

From: <[email-masked]>
Date: Fri, 3 Apr 2020 10:14:17 +0000

Chris, 

Please see inline.

> From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
> Sent: Friday, April 3, 2020 12:00 AM
> To: Robert Raszuk
> 
> 
> 
> I did notice an email, from webex, during the meeting about a request from Bruno to join as guest, but he was in the participant list when I then checked.
> 

So may be my experience may help for next time(s). See below.

An email from the IESG secretary was sent on 2020-03-19, saying "Information about remote participation: https://ietf.webex.com/meet/lsr "
Hence I used that URL.
On this webex, the meeting did not start on time so I've waited for some time. Then 10-15 minutes past the start, I decided to 'notify the host', but never got accepted on the webex.
At that point I assumed a technical issue with webex and monitored the mailing list, but no one was complaining, which is not inline with typical IETF reaction ;-) .
So I assumed the error was only on my side and I searched for more emails and found one from Chris (2020-03-31) saying that the URL was https://ietf.webex.com/ietf/j.php?MTID=mbef20efa9e66c7e97f9d6b18ea84eca8 
And this one worked fine.
My guess is that the 'interim' webex did not use the 'lsr' webex. Also the 'official' notification from the IESG secretary with the incorrect webex URL did not helped.

--Bruno
 
> I didn't receive any other emails like that (and FWIW I had 5 windows over 2 monitors going at once trying to manage all this, so noticing the 1 email was lucky).
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 3 Apr 2020 12:22:44 +0200

Ahh for the record I used that URL yesterday:

An email from the IESG secretary was sent on 2020-03-19, saying
"Information about remote participation: https://ietf.webex.com/meet/lsr "

On Fri, Apr 3, 2020 at 12:14 PM <[email-masked]> wrote:

> > I did notice an email, from webex, during the meeting about a request
> from Bruno to join as guest, but he was in the participant list when I then
> checked.
> >
>
> An email from the IESG secretary was sent on 2020-03-19, saying
> "Information about remote participation: https://ietf.webex.com/meet/lsr "
> Hence I used that URL.
> On this webex, the meeting did not start on time so I've waited for some
> time. Then 10-15 minutes past the start, I decided to 'notify the host',
> but never got accepted on the webex.
> At that point I assumed a technical issue with webex and monitored the
> mailing list, but no one was complaining, which is not inline with typical
> IETF reaction ;-) .
> So I assumed the error was only on my side and I searched for more emails
> and found one from Chris (2020-03-31) saying that the URL was
> https://ietf.webex.com/ietf/j.php?MTID=mbef20efa9e66c7e97f9d6b18ea84eca8
> My guess is that the 'interim' webex did not use the 'lsr' webex. Also the
> 'official' notification from the IESG secretary with the incorrect webex
> URL did not helped.
>
> --Bruno
>
> > I didn't receive any other emails like that (and FWIW I had 5 windows
> over 2 monitors going at once trying to manage all this, so noticing the 1
> email was lucky).
> >
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Christian Hopps <[email-masked]>
Date: Fri, 3 Apr 2020 06:26:12 -0400

Hi Bruno,

This is very useful feedback. It looks like that link the secretary posted simply tries to join a standing open room associated with the LSR webex account. This is frustrating b/c I sent an email to the secretary asking if I'd done things correctly. I'm not sure they are aware that the link they send is no good so I will contact them again.

Thanks,
Chris.

> On Apr 3, 2020, at 6:14 AM, [email-masked] wrote:
> 
> Chris, 
> 
> Please see inline.
> 
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 03 Apr 2020 06:38:41 -0400

Fwiw I used the link in the agenda without issue.  I did the same for RAW 
last week.  Also, as host of a different wg interim right before lsr, I 
didn't have to do anything to let people in to the session - they just 
showed up....

Lou

----------
On April 2, 2020 6:10:43 PM Robert Raszuk <[email-masked]> wrote:

> ----------

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 3 Apr 2020 11:00:03 +0000

This also explains the mystery of why some Bruno, Robert, and possibly others were having problems joining. 
Thanks,
Acee

On 4/3/20, 6:26 AM, "Christian Hopps" <[email-masked]> wrote:

    Hi Bruno,

    Thanks,
    Chris.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 3 Apr 2020 12:07:09 -0700

Same here

Regards,
Jeff

> On Apr 3, 2020, at 03:38, Lou Berger <[email-masked]> wrote:
> 
> 
> Fwiw I used the link in the agenda without issue.  I did the same for RAW last week.  Also, as host of a different wg interim right before lsr, I didn't have to do anything to let people in to the session - they just showed up....
> 
> Lou
> 
>> I never noticed the password .... 
>> 
>> R..
>>> However, Webex has a password requirement when setting up meetings (I guess, I tried to not have one, it wouldn't let me) which we included in all the details wherever the details were posted, it was "linkstate"..
>>>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 3 Apr 2020 15:12:32 -0700

Hi Tianran,
thank you for your kind attention to my questions. Please find my notes
in-lined below under the GIM>> tag.

Kind regards,
Greg

On Thu, Apr 2, 2020 at 11:33 PM Tianran Zhou <[email-masked]> wrote:

> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Friday, April 3, 2020 6:58 AM
> *To:* wangyali <[email-masked]>
> *Cc:* Acee Lindem (acee) <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; Christian Hopps <[email-masked]>; [email-masked];
> Tianran Zhou <[email-masked]>
> *Subject:* Re: [Lsr] 答复: A new version of I-D,
> What’s the context with this question? Frankly, I did not have a deep well
> thinking on this question. But in our case, I wish it’s mandatory.
>
GIM>> If it is mandatory, then all nodes in a domain support IFIT and,
consequently, there's no need to advertise the capability in the
homogeneous, IFIT-wise, domain. Would you agree?

> Yes. This is one use case. As my echo to Robert, we want to achieve the
> SLA assurance network. We think the capability for visibility to verify the
> SLA compliance, and also the capability to get the accurate measurement for
> path computation should be considered. Should be considered from the very
> beginning when we compute the path.
>
GIM>> I understand that IFIT-capability might be used as one of CSPF
constraints. But, as I think of it, it can simply be discovered in the
course of running on-path telemetry collection. Would you agree?