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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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