Hi Acee, >Why wouldn’t you just provision it via a YANG subscription?
YANG subscription is about exporting data to the collector. Here we firstly need to enable IFIT measurement along the path. >An SR Policy could be identified by a <color, endpoint> tuple in the >subscription? There can be many candidate SR policies but only the best-path >is active. You’d need to update all the candidate policies in order to assure >your iFIT tracing is enabled on the corresponding SR path. Yes. But that’s how SR-Policy encoded in BGP and PCEP. There may be different algorithms/logic from the path computation entities, which generate multiple candidate paths. I think both granularity, SR-policy and Candidate Path, are useful. Like the discussion on node or link granularity. >Why would you want to put this in BGP? SR-Policy is encoded in BGP. And not just BGP, but also PCEP. https://datatracker.ietf.org/doc/draft-chen-pce-sr-policy-ifit/ Best Wishes, Tianran From: Acee Lindem (acee) [mailto:[email protected]] Sent: Wednesday, April 8, 2020 4:25 AM To: Tianran Zhou <[email protected]>; Jeff Tantsura <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Tony Li <[email protected]> Cc: Greg Mirsky <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link? Speaking as WG member: Hi Tianran, The more I look, the less I like this. We have a YANG infra-structure for telemetry data using YANG pub/sub. It is being implement and deployed over both NETCONF and proprietary transports. Why would we want to take just this type of telemetry out and handle it differently??? See an inline below… From: Tianran Zhou <[email protected]<mailto:[email protected]>> Date: Tuesday, April 7, 2020 at 3:22 AM To: Acee Lindem <[email protected]<mailto:[email protected]>>, Jeff Tantsura <[email protected]<mailto:[email protected]>>, "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>, Tony Li <[email protected]<mailto:[email protected]>> Cc: Greg Mirsky <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [Lsr] I,Scope of FIT Capability: a node or a link? Hi Acee, About the “IFIT specific information channel”, as in https://datatracker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/ we propose to use bgp enabled sr-policy for IFIT auto deployment. It’s reasonable to incorporate both traffic engineering and monitoring. I think this is a terrible idea. Why wouldn’t you just provision it via a YANG subscription? An SR Policy could be identified by a <color, endpoint> tuple in the subscription? There can be many candidate SR policies but only the best-path is active. You’d need to update all the candidate policies in order to assure your iFIT tracing is enabled on the corresponding SR path. Why would you want to put this in BGP? Acee Thanks, Tianran 发件人: Acee Lindem (acee) [mailto:[email protected]] 发送时间: 2020年4月7日 2:54 收件人: Jeff Tantsura <[email protected]<mailto:[email protected]>>; Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>; Tony Li <[email protected]<mailto:[email protected]>> 抄送: Greg Mirsky <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Tianran Zhou <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 主题: Re: [Lsr] I,Scope of FIT Capability: a node or a link? Speaking as WG member – It seems that additional IFIT-specific information is required to make this useful and the IGPs are certainly not the case. Additionally, the point was made that an IFIT specific information channel would anyway be required to provision the telemetry generation. Thanks, Acee From: Lsr <[email protected]<mailto:[email protected]>> on behalf of Jeff Tantsura <[email protected]<mailto:[email protected]>> Date: Monday, April 6, 2020 at 2:33 PM To: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>, Tony Li <[email protected]<mailto:[email protected]>> Cc: Greg Mirsky <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Tianran Zhou <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link? +1 Please do not take my comments about link vs node capabilities, as support for the solution, they are semantical. Cheers, Jeff On Apr 6, 2020, 8:58 AM -0700, Tony Li <[email protected]<mailto:[email protected]>>, wrote: This discussion is interesting, but please do not ignore the considerable feedback from multiple folks indicating that this advertisement does not belong in the IGP at all (regardless of scope). My opinion on that has not changed. +1 IS-IS is not the correct place to implement Service Discovery mechanisms. The management plane already has ample mechanisms for service and capability discovery. Tony _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
