Robert, That is why we have a possibility to signal in-band/as per device data that could be used by PCE to compute a path that meets the constrains (RFC 7471/7810), e.g per node BW reserved/available or cumulative delay, and similar, computed by the PCE. However if the objective functions used by CSPF are coming from outside (end2end latency measurement/$$ of a link as an example) we don’t feed them back into IGP, telemetry analysis (done by an external system) are of no business of IGP and should be fed (normalized) into PCE directly. We are not discussing the value of telemetry, which is obvious, but need to autodiscover telemetry capability’s and feed (pollute) them into IGP->BGP-LS->controller. I don’t see how this information would be used in route/path computation and hence IMHO it doesn’t belong in IGP. Given the need for configuration (besides ability to support particular technology) makes this a clear candidate for management plane operations. (Chris’ comment about YANG)
Cheers, Jeff On Apr 2, 2020, 2:17 PM -0700, Robert Raszuk <[email protected]>, wrote: > Jeff. > > > The role of a routing protocol is to distribute: reachability (doh :-)) > > and any additional data that could influence routing decision wrt > > reachability. > > The bolded text is precisely the point here. > > So let me provide a very simple example. > > Today routers already compute CSPF. Moreover today routers are asked to use > custom/flexible algorithm to choose reachability paths. > > So just imagine an operator who says: > > Please compute my SPT with the consideration that end to end inband jitter is > not greater then 10 ms otherwise I do not want to see nodes which do not meet > that criteria in the reachability graph for application X. > > or > > Please compute my SPT with the consideration that end to end drop rate is not > greater then 5pps otherwise I do not want to see nodes which do not meet > that criteria in the reachability graph for application Y. > > etc ... > > If you consider such constrains to provide reachability for applications you > will likely see value that in-situ telemetry is your friend here. Really best > friend as without him you can not do the proper end to end path exclusion for > SPT computations. > > Hint: All per link extensions which were added to IGPs are not going to help > here as drops or jitter may equally happen in the routers fabric on fabric to > LC boundaries or on the line cards and links. So you need end to end test > stream. > > Many thx, > R. > > PS. As we are talking LSR here it is strange that joining virtual LSR meeting > is not for everyone. I was waiting and tried three times today for host > approval to join which was not granted. > > > On Thu, Apr 2, 2020 at 11:00 PM Jeff Tantsura <[email protected]> > > wrote: > > > Robert, > > > > > > This is unnecessary leakage of management plane into control plane. > > > The role of a routing protocol is to distribute: reachability (doh :-)) > > > and any additional data that could influence routing decision wrt > > > reachability. > > > There are precedences of using IGP’s for different tasks, e..g. RFC 5088 > > > and similar, however should we do it again? > > > > > > Specifically to use case described - I really don’t see how this > > > information would be used in routing decisions (PCE computation). > > > Moreover, if the end-goal is to build a connected graph of the devices > > > that have a coherent iFIT feature set it would require reoptimization on > > > every change and quite complex computation logic (talking SR - on top of > > > regular constrains, MSD, etc).I’d also think that there’s mandatory > > > configuration of name-spaces and features supported, in other words - > > > autodiscovery is meaningless, it would still require as per device > > > configuration (hello YANG). Most of telemetry solutions are designed to > > > pass thought nodes that don’t support it transparently, so the real > > > requirement is really to know the sink-node (the one that is egress of > > > the telemetry domain and must remove all additional encapsulations). > > > > > > As to the last point - we already have a kitchen-sink routing protocol > > > ;-) > > > > > > Cheers, > > > Jeff > > > On Apr 2, 2020, 6:10 AM -0700, Robert Raszuk <[email protected]>, wrote: > > > > > > > > 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) > > > > > <[email protected]> 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 <[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
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
