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= 40cisco....@dmarc.ietf.org> 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 <wangyal...@huawei.com> > > Sent: Wednesday, April 01, 2020 8:12 PM > > To: Acee Lindem (acee) <a...@cisco.com>; Les Ginsberg (ginsberg) > > <ginsb...@cisco.com>; Christian Hopps <cho...@chopps.org> > > Cc: lsr@ietf.org; Tianran Zhou <zhoutian...@huawei.com> > > 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:a...@cisco.com] > > 发送时间: 2020年4月1日 20:29 > > 收件人: Tianran Zhou <zhoutian...@huawei.com>; Les Ginsberg (ginsberg) > > <ginsb...@cisco.com>; Christian Hopps <cho...@chopps.org> > > 抄送: lsr@ietf.org; wangyali <wangyal...@huawei.com> > > 主题: 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)" <a...@cisco.com> 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-boun...@ietf.org > > on behalf of zhoutian...@huawei.com> 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:ginsb...@cisco.com] > > Sent: Wednesday, April 1, 2020 1:47 PM > > To: Tianran Zhou <zhoutian...@huawei.com>; Christian Hopps > > <cho...@chopps.org> > > Cc: wangyali <wangyal...@huawei.com>; lsr@ietf.org > > Subject: RE: [Lsr] A new version of I-D, > draft-liu-lsr-isis-ifit-node- > > capability-02 > > > > Tianran - > > > > I am very much in agreement with the points Chris has made. > > > > IGPs do not exist to advertise capabilities/configure > applications - which > > seems to me to be what you 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 <zhoutian...@huawei.com> > > > Sent: Tuesday, March 31, 2020 7:53 PM > > > To: Christian Hopps <cho...@chopps.org> > > > Cc: wangyali <wangyal...@huawei.com>; Les Ginsberg (ginsberg) > > > <ginsb...@cisco.com>; lsr@ietf.org > > > 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:cho...@chopps.org] > > > Sent: Wednesday, April 1, 2020 10:00 AM > > > To: Tianran Zhou <zhoutian...@huawei.com> > > > Cc: Christian Hopps <cho...@chopps.org>; wangyali > > > <wangyal...@huawei.com>; Les Ginsberg (ginsberg) > > <ginsb...@cisco.com>; > > > lsr@ietf.org > > > 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 > > <zhoutian...@huawei.com> > > > 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 > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
