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

[Tianran Zhou <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, April 2, 2020 8:47 PM
To: Christian Hopps <[e-mail]>; Robert Raszuk <[e-mail]>
Cc: wangyali <[e-mail]>; Acee Lindem (acee) <[e-mail]>; [e-mail]; Tianran Zhou <[e-mail]>
Subject: RE: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

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

> -----Original Message-----
> From: Christian Hopps <[e-mail]>
> Sent: Thursday, April 02, 2020 5:13 AM
> To: Robert Raszuk <[e-mail]>
> Cc: Christian Hopps <[e-mail]>; Les Ginsberg (ginsberg) 
> <[e-mail]>; wangyali <[e-mail]>; Acee Lindem
> (acee) <[e-mail]>; [e-mail]; Tianran Zhou 
> <[e-mail]>
> 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]
> 
> 
> > On Apr 2, 2020, at 5:17 AM, Robert Raszuk <[e-mail]> wrote:
> >
> > 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=[e-mail]> 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.
> >
> > Using IGP Router Capabilities here is wrong in my view.
> >
> >    Les
> >
> >
> > > -----Original Message-----
> > > From: wangyali <[e-mail]>
> > > Sent: Wednesday, April 01, 2020 8:12 PM
> > > To: Acee Lindem (acee) <[e-mail]>; Les Ginsberg (ginsberg) 
> > > <[e-mail]>; Christian Hopps <[e-mail]>
> > > Cc: [e-mail]; Tianran Zhou <[e-mail]>
> > > 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.
> > >
> > > 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:[e-mail]]
> > > 发送时间: 2020年4月1日 20:29
> > > 收件人: Tianran Zhou <[e-mail]>; Les Ginsberg
> (ginsberg)
> > > <[e-mail]>; Christian Hopps <[e-mail]>
> > > 抄送: [e-mail]; wangyali <[e-mail]>
> > > 主题: Re: [Lsr] A new version of I-D, 
> > > draft-liu-lsr-isis-ifit-node-capability-
> 02
> > >
> > > Speak as WG Member...
> > >
> > > On 4/1/20, 8:08 AM, "Acee Lindem (acee)" <[e-mail]> wrote:
> > >
> > >     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" <lsr-
> [e-mail]
> > > on behalf of [e-mail]> 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
> > >
> > >         -----Original Message-----
> > >         From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > >         Sent: Wednesday, April 1, 2020 1:47 PM
> > >         To: Tianran Zhou <[e-mail]>; Christian Hopps 
> > > <[e-mail]>
> > >         Cc: wangyali <[e-mail]>; [e-mail]
> > >         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 <[e-mail]>
> > >         > Sent: Tuesday, March 31, 2020 7:53 PM
> > >         > To: Christian Hopps <[e-mail]>
> > >         > Cc: wangyali <[e-mail]>; Les Ginsberg (ginsberg)
> > >         > <[e-mail]>; [e-mail]
> > >         > 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:[e-mail]]
> > >         > Sent: Wednesday, April 1, 2020 10:00 AM
> > >         > To: Tianran Zhou <[e-mail]>
> > >         > Cc: Christian Hopps <[e-mail]>; wangyali
> > >         > <[e-mail]>; Les Ginsberg (ginsberg) 
> > > <[e-mail]>;
> > >         > [e-mail]
> > >         > 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 
> > > <[e-mail]>
> > >         > 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.
> > >
> > >         _______________________________________________
> > >         Lsr mailing list
> > >         [e-mail]
> > >         https://www.ietf.org/mailman/listinfo/lsr
> > >
> > >
> > >
> >
> > _______________________________________________
> > Lsr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lsr