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 protected]] Sent: Thursday, April 2, 2020 8:47 PM To: Christian Hopps <[email protected]>; Robert Raszuk <[email protected]> Cc: wangyali <[email protected]>; Acee Lindem (acee) <[email protected]>; [email protected]; Tianran Zhou <[email protected]> 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 <[email protected]> > Sent: Thursday, April 02, 2020 5:13 AM > To: Robert Raszuk <[email protected]> > Cc: Christian Hopps <[email protected]>; Les Ginsberg (ginsberg) > <[email protected]>; wangyali <[email protected]>; Acee Lindem > (acee) <[email protected]>; [email protected]; Tianran Zhou > <[email protected]> > 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 <[email protected]> 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) > <[email protected]> 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 <[email protected]> > > > Sent: Wednesday, April 01, 2020 8:12 PM > > > To: Acee Lindem (acee) <[email protected]>; Les Ginsberg (ginsberg) > > > <[email protected]>; Christian Hopps <[email protected]> > > > Cc: [email protected]; Tianran Zhou <[email protected]> > > > 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:[email protected]] > > > 发送时间: 2020年4月1日 20:29 > > > 收件人: Tianran Zhou <[email protected]>; Les Ginsberg > (ginsberg) > > > <[email protected]>; Christian Hopps <[email protected]> > > > 抄送: [email protected]; wangyali <[email protected]> > > > 主题: 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)" <[email protected]> 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- > [email protected] > > > on behalf of [email protected]> 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:[email protected]] > > > Sent: Wednesday, April 1, 2020 1:47 PM > > > To: Tianran Zhou <[email protected]>; Christian Hopps > > > <[email protected]> > > > Cc: wangyali <[email protected]>; [email protected] > > > 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 protected]> > > > > Sent: Tuesday, March 31, 2020 7:53 PM > > > > To: Christian Hopps <[email protected]> > > > > Cc: wangyali <[email protected]>; Les Ginsberg (ginsberg) > > > > <[email protected]>; [email protected] > > > > 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 protected]] > > > > Sent: Wednesday, April 1, 2020 10:00 AM > > > > To: Tianran Zhou <[email protected]> > > > > Cc: Christian Hopps <[email protected]>; wangyali > > > > <[email protected]>; Les Ginsberg (ginsberg) > > > <[email protected]>; > > > > [email protected] > > > > 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 protected]> > > > > 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
