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

[Robert Raszuk <[e-mail]>]

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) <[e-mail]>
wrote:

> Robert -
>
> First, +1 to what Chris has said.
>
> There is nothing in the lfit-capability draft that defines any information
> that can be used by IGPs to do what you suggest.
> Perhaps it is possible that 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
>
>