Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Hi Tony, I think there is still some disconnect - so in an attempt to at least make sure that we have difference of opinions let me try to restate what I was suggesting. IGP would only carry indication if tail can do inband telemetry or not - it would *not* carry any telemetry data. IGP would not be running telemetry - it will be just consumer of other subsystem product. https://tools.ietf.org/html/draft-wang-lsr-ifit-node-capability-advertisement-00 just signals capability. It does not even have a trunk for any type of dump :) Global optimization makes a lot of sense for traffic spread across given network - 100%. But it is not the best place to only select if one path is eligible and the other is not in given topology. That decision should happen on the headends and should be as much distributed as possible. And the data here as input to the decision is only valid on specific headend probes depart from. Besides it has usually a very short life. Even if we move cspf to historic just very recently flexible algorithm was proposed and I think is progressing fine. So my examples of use cases to choose paths with min drops or bound jitter are real. Hi Jeff, If I look at one of the in situ data plane proposals it does send the results to the sender/originator vs some collector. draft-lapukhov-dataplane-probe-01 This is besides the point of this discussion as we are not asking for IGP to carry the results. Hint: Each headend can be a collector or nothing breaks in the design if headend get's this data out of band from central collector. Thx, R. On Fri, Apr 3, 2020 at 1:43 AM wrote: > > Sure it is possible to discover if my tailends are capable of handling in > band telemetry by off line means. But what I am struggling to see why we > allowed so much TE stuff into IGPs and we do not want to make it easier for > headends to operate without PCE at all for the purpose of delivering > such type of services. > > > > AFAICT, we put a lot of effort into making headend path computation useful > and, for the most part, it was and is not necessary. > > Even with legacy mechanisms, people decided that they need global > optimization and that head-end path computation was Not That Interesting. > > It’s now 20 years later, the network is even more dynamic, the > expectations about response time are that much higher, and concerns about > link state database stability and scalability have increased. Modern > telemetry is definitely not suitable to be passed in the IGP anymore. > > Thus, it seems like the IGP can provide base topology information and > traffic engineering constructs should leverage that and provide an > independent telemetry collection plane. Within that plane, telemetry > capabilities can and should be confined to the telemetry plane. > > As we’ve said many times before: BGP is not a dump truck. Analogously, the > IGP isn’t even an SUV. > > ;-) > > Regards, > Tony > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
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:ginsb...@cisco.com] Sent: Thursday, April 2, 2020 8:47 PM To: Christian Hopps ; Robert Raszuk Cc: wangyali ; Acee Lindem (acee) ; lsr@ietf.org; Tianran Zhou 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 > Sent: Thursday, April 02, 2020 5:13 AM > To: Robert Raszuk > Cc: Christian Hopps ; Les Ginsberg (ginsberg) > ; wangyali ; Acee Lindem > (acee) ; lsr@ietf.org; Tianran Zhou > > 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 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) > 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 -
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Hi Aijun, I understand very well what you are trying to achieve and don’t argue the need for it. My point however - routing protocols are not the most suitable transport for it. Regards, Jeff > On Apr 2, 2020, at 19:39, Aijun Wang wrote: > > Hi, Jeff: > The draft only propose to transfer the iFIT capability of the Node via the > IGP protocol, not the telemetry data. > As described in the draft, flooding such capability can assist the > controller(it collects such information via the BGP-LS) to deploy the iFIT > function at the path headend. > > Aijun Wang > China Telecom > >>> On Apr 3, 2020, at 08:20, Jeff Tantsura wrote: >>> >> Robert, >> >> We are deviating ;-) >> >> There’s no feedback loop from telemetry producers back to the TE headend. >> The telemetry, either end2end or postcards is sent to a collector that has >> the context of the data and normalizes it so it can be consumed by an >> external system, being centralized or distributed PCE or anything else that >> could make use of it. Do you see IGP anywhere in between? >> >> >> Regards, >> Jeff >> On Apr 2, 2020, at 16:03, Robert Raszuk wrote: >>> >>> Hi Joel, >>> >>> > Robert, you seem to be asking that we pass full information about the >>> > dynamic network state to all routers >>> >>> No not at all. >>> >>> Only TE headends need this information. >>> >>> To restate ... I am not asking to have a synchronized input to all routes >>> in the domain such that their computation would be consistent. >>> >>> I am only asking for TE headends to be able to select end to end paths >>> based on the end to end inband telemetry data. I find this a useful >>> requirement missing from any of today's operational deployments. >>> >>> Many thx, >>> R. >>> >>> >>> >>> >>> >>> On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern wrote: Robert, you seem to be asking that we pass full information about the dynamic network state to all routers so that they can, if needed, serve as fully intelligent path computation engines. If you want to do that, you will need more than just the telemetry. You will need the demands that are coming in to all of those routers, so that you can make global decisions sensibly. Which is why we use quasi-centralized path computation engines. Yours, Joel On 4/2/2020 6:16 PM, Robert Raszuk wrote: > > > 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.. > > [as wg member] Are you thinking that shifting traffic to a router is > not going to affect it's jitter/drop rate? > > > Well this is actually the other way around. > > First you have your default topology. They you are asked to > construct new one based on applied constrains. > > So you create complete TE coverage and start running end to end data > plane probing over all TE paths (say SR-TE for specific example). Once > you start collecting the probe results you can start excluding paths > which do not meet your applied constraints. And that process continues... > > To your specific question - It is not that unusual where routers degrade > their performance with time and in many cases the traffic is not the > cause for it but internal bugs and malfunctions. > > Best, > R. > > ___ > 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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Hi Robert, You provide the perfect examples. That is exactly what we want to do with the IFIT control plane. While we used to consider resources as the cost(static or dynamic) for the path computation, here we also need to consider the IFIT capability that the node can support. We want to achieve the SLA assurance network, not only we can compute a best performance path, but also we can provide corresponding SLA visibility and measurement on this path. Cheers, Tianran From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Friday, April 3, 2020 5:17 AM To: Jeff Tantsura Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org; Christian Hopps ; Acee Lindem (acee) ; Tianran Zhou ; wangyali Subject: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02 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 mailto:jefftant.i...@gmail.com>> 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 mailto:rob...@raszuk.net>>, 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) mailto:ginsb...@cisco.com>> 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 Messag
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Hi, Jeff: The draft only propose to transfer the iFIT capability of the Node via the IGP protocol, not the telemetry data. As described in the draft, flooding such capability can assist the controller(it collects such information via the BGP-LS) to deploy the iFIT function at the path headend. Aijun Wang China Telecom > On Apr 3, 2020, at 08:20, Jeff Tantsura wrote: > > Robert, > > We are deviating ;-) > > There’s no feedback loop from telemetry producers back to the TE headend. > The telemetry, either end2end or postcards is sent to a collector that has > the context of the data and normalizes it so it can be consumed by an > external system, being centralized or distributed PCE or anything else that > could make use of it. Do you see IGP anywhere in between? > > > Regards, > Jeff > >>> On Apr 2, 2020, at 16:03, Robert Raszuk wrote: >>> >> >> Hi Joel, >> >> > Robert, you seem to be asking that we pass full information about the >> > dynamic network state to all routers >> >> No not at all. >> >> Only TE headends need this information. >> >> To restate ... I am not asking to have a synchronized input to all routes in >> the domain such that their computation would be consistent. >> >> I am only asking for TE headends to be able to select end to end paths based >> on the end to end inband telemetry data. I find this a useful requirement >> missing from any of today's operational deployments. >> >> Many thx, >> R. >> >> >> >> >> >> >>> On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern >>> wrote: >>> Robert, you seem to be asking that we pass full information about the >>> dynamic network state to all routers so that they can, if needed, serve >>> as fully intelligent path computation engines. If you want to do that, >>> you will need more than just the telemetry. You will need the demands >>> that are coming in to all of those routers, so that you can make global >>> decisions sensibly. >>> Which is why we use quasi-centralized path computation engines. >>> >>> Yours, >>> Joel >>> >>> On 4/2/2020 6:16 PM, Robert Raszuk wrote: >>> > >>> > > 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.. >>> > >>> > [as wg member] Are you thinking that shifting traffic to a router is >>> > not going to affect it's jitter/drop rate? >>> > >>> > >>> > Well this is actually the other way around. >>> > >>> > First you have your default topology. They you are asked to >>> > construct new one based on applied constrains. >>> > >>> > So you create complete TE coverage and start running end to end data >>> > plane probing over all TE paths (say SR-TE for specific example). Once >>> > you start collecting the probe results you can start excluding paths >>> > which do not meet your applied constraints. And that process continues >>> > >>> > To your specific question - It is not that unusual where routers degrade >>> > their performance with time and in many cases the traffic is not the >>> > cause for it but internal bugs and malfunctions. >>> > >>> > Best, >>> > R. >>> > >>> > ___ >>> > 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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Hi Jeff, excellent question, thank you! If one wants to empower headends with all the telemetry, then there's no need to collect it. A method that triggers node-local measurement is sufficient to calculate node-local performance metrics that may be periodically exported to a Collector or ... flooded using IGP (no, I didn't say that!). Regards, Greg On Thu, Apr 2, 2020 at 5:19 PM Jeff Tantsura wrote: > Robert, > > We are deviating ;-) > > There’s no feedback loop from telemetry producers back to the TE headend. > The telemetry, either end2end or postcards is sent to a collector that > has the context of the data and normalizes it so it can be consumed by an > external system, being centralized or distributed PCE or anything else that > could make use of it. Do you see IGP anywhere in between? > > > Regards, > Jeff > > On Apr 2, 2020, at 16:03, Robert Raszuk wrote: > > > Hi Joel, > > > Robert, you seem to be asking that we pass full information about the > > dynamic network state to all routers > > No not at all. > > Only TE headends need this information. > > To restate ... I am not asking to have a synchronized input to all routes > in the domain such that their computation would be consistent. > > I am only asking for TE headends to be able to select end to end paths > based on the end to end inband telemetry data. I find this a useful > requirement missing from any of today's operational deployments. > > Many thx, > R. > > > > > > > On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern > wrote: > >> Robert, you seem to be asking that we pass full information about the >> dynamic network state to all routers so that they can, if needed, serve >> as fully intelligent path computation engines. If you want to do that, >> you will need more than just the telemetry. You will need the demands >> that are coming in to all of those routers, so that you can make global >> decisions sensibly. >> Which is why we use quasi-centralized path computation engines. >> >> Yours, >> Joel >> >> On 4/2/2020 6:16 PM, Robert Raszuk wrote: >> > >> > > 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.. >> > >> > [as wg member] Are you thinking that shifting traffic to a router is >> > not going to affect it's jitter/drop rate? >> > >> > >> > Well this is actually the other way around. >> > >> > First you have your default topology. They you are asked to >> > construct new one based on applied constrains. >> > >> > So you create complete TE coverage and start running end to end data >> > plane probing over all TE paths (say SR-TE for specific example). Once >> > you start collecting the probe results you can start excluding paths >> > which do not meet your applied constraints. And that process >> continues... >> > >> > To your specific question - It is not that unusual where routers >> degrade >> > their performance with time and in many cases the traffic is not the >> > cause for it but internal bugs and malfunctions. >> > >> > Best, >> > R. >> > >> > ___ >> > 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 > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Robert, We are deviating ;-) There’s no feedback loop from telemetry producers back to the TE headend. The telemetry, either end2end or postcards is sent to a collector that has the context of the data and normalizes it so it can be consumed by an external system, being centralized or distributed PCE or anything else that could make use of it. Do you see IGP anywhere in between? Regards, Jeff > On Apr 2, 2020, at 16:03, Robert Raszuk wrote: > > > Hi Joel, > > > Robert, you seem to be asking that we pass full information about the > > dynamic network state to all routers > > No not at all. > > Only TE headends need this information. > > To restate ... I am not asking to have a synchronized input to all routes in > the domain such that their computation would be consistent. > > I am only asking for TE headends to be able to select end to end paths based > on the end to end inband telemetry data. I find this a useful requirement > missing from any of today's operational deployments. > > Many thx, > R. > > > > > > >> On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern wrote: >> Robert, you seem to be asking that we pass full information about the >> dynamic network state to all routers so that they can, if needed, serve >> as fully intelligent path computation engines. If you want to do that, >> you will need more than just the telemetry. You will need the demands >> that are coming in to all of those routers, so that you can make global >> decisions sensibly. >> Which is why we use quasi-centralized path computation engines. >> >> Yours, >> Joel >> >> On 4/2/2020 6:16 PM, Robert Raszuk wrote: >> > >> > > 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.. >> > >> > [as wg member] Are you thinking that shifting traffic to a router is >> > not going to affect it's jitter/drop rate? >> > >> > >> > Well this is actually the other way around. >> > >> > First you have your default topology. They you are asked to >> > construct new one based on applied constrains. >> > >> > So you create complete TE coverage and start running end to end data >> > plane probing over all TE paths (say SR-TE for specific example). Once >> > you start collecting the probe results you can start excluding paths >> > which do not meet your applied constraints. And that process continues... >> > >> > To your specific question - It is not that unusual where routers degrade >> > their performance with time and in many cases the traffic is not the >> > cause for it but internal bugs and malfunctions. >> > >> > Best, >> > R. >> > >> > ___ >> > 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
> Sure it is possible to discover if my tailends are capable of handling in > band telemetry by off line means. But what I am struggling to see why we > allowed so much TE stuff into IGPs and we do not want to make it easier for > headends to operate without PCE at all for the purpose of delivering such > type of services. AFAICT, we put a lot of effort into making headend path computation useful and, for the most part, it was and is not necessary. Even with legacy mechanisms, people decided that they need global optimization and that head-end path computation was Not That Interesting. It’s now 20 years later, the network is even more dynamic, the expectations about response time are that much higher, and concerns about link state database stability and scalability have increased. Modern telemetry is definitely not suitable to be passed in the IGP anymore. Thus, it seems like the IGP can provide base topology information and traffic engineering constructs should leverage that and provide an independent telemetry collection plane. Within that plane, telemetry capabilities can and should be confined to the telemetry plane. As we’ve said many times before: BGP is not a dump truck. Analogously, the IGP isn’t even an SUV. ;-) Regards, Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
> "collected only on active paths" is not something I propose but is the property of on-path > telemetry collection method. That is all fine. The point is that the notion of active paths in the network may represent those in default topology over any path. That can be computed by PCE. So default topology may have N active paths while application specific topologies M where M is a subset of N meeting required end to end constraints. Sure it is possible to discover if my tailends are capable of handling in band telemetry by off line means. But what I am struggling to see why we allowed so much TE stuff into IGPs and we do not want to make it easier for headends to operate without PCE at all for the purpose of delivering such type of services. Kind regards, R. On Fri, Apr 3, 2020 at 1:22 AM Greg Mirsky wrote: > Hi Robert, > "collected only on active paths" is not something I propose but is the > property of on-path telemetry collection method. > > Regards, > Greg > > On Thu, Apr 2, 2020 at 4:16 PM Robert Raszuk wrote: > >> > collected only on active paths >> >> Here we clearly diverge :) >> >> The notion of default active paths in my view represents many more >> alternative paths constructed based on the default topology while cspf or >> flex algo products may consist only of subset of those per applied >> constraints. >> >> Thx, >> Robert >> >> >> On Fri, Apr 3, 2020 at 1:13 AM Greg Mirsky wrote: >> >>> And another note regarding the use of on-path collected telemetry >>> information. I'd point that that information is collected only on active >>> paths. Thus it characterizes the conditions experienced by already existing >>> flows. Hence it might not be related to a path that the system intends to >>> instantiate. One needs active OAM to collect such information. >>> >>> Regards, >>> Greg >>> >>> On Thu, Apr 2, 2020 at 4:08 PM Greg Mirsky >>> wrote: >>> Hi Robert, I think that there's no apparent requirement to collect performance information form each node in the network in order to select a path with bounded delay and packet loss. Would you agree? Regards, Greg On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk wrote: > Hi Joel, > > > Robert, you seem to be asking that we pass full information about the > > dynamic network state to all routers > > No not at all. > > Only TE headends need this information. > > To restate ... I am not asking to have a synchronized input to all > routes in the domain such that their computation would be consistent. > > I am only asking for TE headends to be able to select end to end paths > based on the end to end inband telemetry data. I find this a useful > requirement missing from any of today's operational deployments. > > Many thx, > R. > > > > > > > On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern > wrote: > >> Robert, you seem to be asking that we pass full information about the >> dynamic network state to all routers so that they can, if needed, >> serve >> as fully intelligent path computation engines. If you want to do >> that, >> you will need more than just the telemetry. You will need the >> demands >> that are coming in to all of those routers, so that you can make >> global >> decisions sensibly. >> Which is why we use quasi-centralized path computation engines. >> >> Yours, >> Joel >> >> On 4/2/2020 6:16 PM, Robert Raszuk wrote: >> > >> > > 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.. >> > >> > [as wg member] Are you thinking that shifting traffic to a >> router is >> > not going to affect it's jitter/drop rate? >> > >> > >> > Well this is actually the other way around. >> > >> > First you have your default topology. They you are asked to >> > construct new one based on applied constrains. >> > >> > So you create complete TE coverage and start running end to end >> data >> > plane probing over all TE paths (say SR-TE for specific example). >> Once >> > you start collecting the probe results you can start >> excluding paths >> > which do not meet your applied constraints. And that process >> continues.. >> > >> > To your specific question - It is not that unusual where routers >> degrade >> > their performance with time and in many cases the traffic is not >> the >> > cause for it but internal bugs and malfunctions. >> > >> > Best, >> > R. >> > >> > ___ >> > Lsr mailing list >> > Lsr@ietf.org
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Hi Robert, "collected only on active paths" is not something I propose but is the property of on-path telemetry collection method. Regards, Greg On Thu, Apr 2, 2020 at 4:16 PM Robert Raszuk wrote: > > collected only on active paths > > Here we clearly diverge :) > > The notion of default active paths in my view represents many more > alternative paths constructed based on the default topology while cspf or > flex algo products may consist only of subset of those per applied > constraints. > > Thx, > Robert > > > On Fri, Apr 3, 2020 at 1:13 AM Greg Mirsky wrote: > >> And another note regarding the use of on-path collected telemetry >> information. I'd point that that information is collected only on active >> paths. Thus it characterizes the conditions experienced by already existing >> flows. Hence it might not be related to a path that the system intends to >> instantiate. One needs active OAM to collect such information. >> >> Regards, >> Greg >> >> On Thu, Apr 2, 2020 at 4:08 PM Greg Mirsky wrote: >> >>> Hi Robert, >>> I think that there's no apparent requirement to collect performance >>> information form each node in the network in order to select a path with >>> bounded delay and packet loss. Would you agree? >>> >>> Regards, >>> Greg >>> >>> On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk wrote: >>> Hi Joel, > Robert, you seem to be asking that we pass full information about the > dynamic network state to all routers No not at all. Only TE headends need this information. To restate ... I am not asking to have a synchronized input to all routes in the domain such that their computation would be consistent. I am only asking for TE headends to be able to select end to end paths based on the end to end inband telemetry data. I find this a useful requirement missing from any of today's operational deployments. Many thx, R. On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern wrote: > Robert, you seem to be asking that we pass full information about the > dynamic network state to all routers so that they can, if needed, > serve > as fully intelligent path computation engines. If you want to do > that, > you will need more than just the telemetry. You will need the demands > that are coming in to all of those routers, so that you can make > global > decisions sensibly. > Which is why we use quasi-centralized path computation engines. > > Yours, > Joel > > On 4/2/2020 6:16 PM, Robert Raszuk wrote: > > > > > 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.. > > > > [as wg member] Are you thinking that shifting traffic to a > router is > > not going to affect it's jitter/drop rate? > > > > > > Well this is actually the other way around. > > > > First you have your default topology. They you are asked to > > construct new one based on applied constrains. > > > > So you create complete TE coverage and start running end to end data > > plane probing over all TE paths (say SR-TE for specific example). > Once > > you start collecting the probe results you can start excluding paths > > which do not meet your applied constraints. And that process > continues.. > > > > To your specific question - It is not that unusual where routers > degrade > > their performance with time and in many cases the traffic is not the > > cause for it but internal bugs and malfunctions. > > > > Best, > > R. > > > > ___ > > 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
> collected only on active paths Here we clearly diverge :) The notion of default active paths in my view represents many more alternative paths constructed based on the default topology while cspf or flex algo products may consist only of subset of those per applied constraints. Thx, Robert On Fri, Apr 3, 2020 at 1:13 AM Greg Mirsky wrote: > And another note regarding the use of on-path collected telemetry > information. I'd point that that information is collected only on active > paths. Thus it characterizes the conditions experienced by already existing > flows. Hence it might not be related to a path that the system intends to > instantiate. One needs active OAM to collect such information. > > Regards, > Greg > > On Thu, Apr 2, 2020 at 4:08 PM Greg Mirsky wrote: > >> Hi Robert, >> I think that there's no apparent requirement to collect performance >> information form each node in the network in order to select a path with >> bounded delay and packet loss. Would you agree? >> >> Regards, >> Greg >> >> On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk wrote: >> >>> Hi Joel, >>> >>> > Robert, you seem to be asking that we pass full information about the >>> > dynamic network state to all routers >>> >>> No not at all. >>> >>> Only TE headends need this information. >>> >>> To restate ... I am not asking to have a synchronized input to all >>> routes in the domain such that their computation would be consistent. >>> >>> I am only asking for TE headends to be able to select end to end paths >>> based on the end to end inband telemetry data. I find this a useful >>> requirement missing from any of today's operational deployments. >>> >>> Many thx, >>> R. >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern >>> wrote: >>> Robert, you seem to be asking that we pass full information about the dynamic network state to all routers so that they can, if needed, serve as fully intelligent path computation engines. If you want to do that, you will need more than just the telemetry. You will need the demands that are coming in to all of those routers, so that you can make global decisions sensibly. Which is why we use quasi-centralized path computation engines. Yours, Joel On 4/2/2020 6:16 PM, Robert Raszuk wrote: > > > 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.. > > [as wg member] Are you thinking that shifting traffic to a router is > not going to affect it's jitter/drop rate? > > > Well this is actually the other way around. > > First you have your default topology. They you are asked to > construct new one based on applied constrains. > > So you create complete TE coverage and start running end to end data > plane probing over all TE paths (say SR-TE for specific example). Once > you start collecting the probe results you can start excluding paths > which do not meet your applied constraints. And that process continues.. > > To your specific question - It is not that unusual where routers degrade > their performance with time and in many cases the traffic is not the > cause for it but internal bugs and malfunctions. > > Best, > R. > > ___ > 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
And another note regarding the use of on-path collected telemetry information. I'd point that that information is collected only on active paths. Thus it characterizes the conditions experienced by already existing flows. Hence it might not be related to a path that the system intends to instantiate. One needs active OAM to collect such information. Regards, Greg On Thu, Apr 2, 2020 at 4:08 PM Greg Mirsky wrote: > Hi Robert, > I think that there's no apparent requirement to collect performance > information form each node in the network in order to select a path with > bounded delay and packet loss. Would you agree? > > Regards, > Greg > > On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk wrote: > >> Hi Joel, >> >> > Robert, you seem to be asking that we pass full information about the >> > dynamic network state to all routers >> >> No not at all. >> >> Only TE headends need this information. >> >> To restate ... I am not asking to have a synchronized input to all routes >> in the domain such that their computation would be consistent. >> >> I am only asking for TE headends to be able to select end to end paths >> based on the end to end inband telemetry data. I find this a useful >> requirement missing from any of today's operational deployments. >> >> Many thx, >> R. >> >> >> >> >> >> >> On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern >> wrote: >> >>> Robert, you seem to be asking that we pass full information about the >>> dynamic network state to all routers so that they can, if needed, serve >>> as fully intelligent path computation engines. If you want to do that, >>> you will need more than just the telemetry. You will need the demands >>> that are coming in to all of those routers, so that you can make global >>> decisions sensibly. >>> Which is why we use quasi-centralized path computation engines. >>> >>> Yours, >>> Joel >>> >>> On 4/2/2020 6:16 PM, Robert Raszuk wrote: >>> > >>> > > 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.. >>> > >>> > [as wg member] Are you thinking that shifting traffic to a router >>> is >>> > not going to affect it's jitter/drop rate? >>> > >>> > >>> > Well this is actually the other way around. >>> > >>> > First you have your default topology. They you are asked to >>> > construct new one based on applied constrains. >>> > >>> > So you create complete TE coverage and start running end to end data >>> > plane probing over all TE paths (say SR-TE for specific example). Once >>> > you start collecting the probe results you can start excluding paths >>> > which do not meet your applied constraints. And that process >>> continues.. >>> > >>> > To your specific question - It is not that unusual where routers >>> degrade >>> > their performance with time and in many cases the traffic is not the >>> > cause for it but internal bugs and malfunctions. >>> > >>> > Best, >>> > R. >>> > >>> > ___ >>> > 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Hi Robert, I think that there's no apparent requirement to collect performance information form each node in the network in order to select a path with bounded delay and packet loss. Would you agree? Regards, Greg On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk wrote: > Hi Joel, > > > Robert, you seem to be asking that we pass full information about the > > dynamic network state to all routers > > No not at all. > > Only TE headends need this information. > > To restate ... I am not asking to have a synchronized input to all routes > in the domain such that their computation would be consistent. > > I am only asking for TE headends to be able to select end to end paths > based on the end to end inband telemetry data. I find this a useful > requirement missing from any of today's operational deployments. > > Many thx, > R. > > > > > > > On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern > wrote: > >> Robert, you seem to be asking that we pass full information about the >> dynamic network state to all routers so that they can, if needed, serve >> as fully intelligent path computation engines. If you want to do that, >> you will need more than just the telemetry. You will need the demands >> that are coming in to all of those routers, so that you can make global >> decisions sensibly. >> Which is why we use quasi-centralized path computation engines. >> >> Yours, >> Joel >> >> On 4/2/2020 6:16 PM, Robert Raszuk wrote: >> > >> > > 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.. >> > >> > [as wg member] Are you thinking that shifting traffic to a router is >> > not going to affect it's jitter/drop rate? >> > >> > >> > Well this is actually the other way around. >> > >> > First you have your default topology. They you are asked to >> > construct new one based on applied constrains. >> > >> > So you create complete TE coverage and start running end to end data >> > plane probing over all TE paths (say SR-TE for specific example). Once >> > you start collecting the probe results you can start excluding paths >> > which do not meet your applied constraints. And that process continues.. >> > >> > To your specific question - It is not that unusual where routers >> degrade >> > their performance with time and in many cases the traffic is not the >> > cause for it but internal bugs and malfunctions. >> > >> > Best, >> > R. >> > >> > ___ >> > 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Hi Joel, > Robert, you seem to be asking that we pass full information about the > dynamic network state to all routers No not at all. Only TE headends need this information. To restate ... I am not asking to have a synchronized input to all routes in the domain such that their computation would be consistent. I am only asking for TE headends to be able to select end to end paths based on the end to end inband telemetry data. I find this a useful requirement missing from any of today's operational deployments. Many thx, R. On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern wrote: > Robert, you seem to be asking that we pass full information about the > dynamic network state to all routers so that they can, if needed, serve > as fully intelligent path computation engines. If you want to do that, > you will need more than just the telemetry. You will need the demands > that are coming in to all of those routers, so that you can make global > decisions sensibly. > Which is why we use quasi-centralized path computation engines. > > Yours, > Joel > > On 4/2/2020 6:16 PM, Robert Raszuk wrote: > > > > > 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.. > > > > [as wg member] Are you thinking that shifting traffic to a router is > > not going to affect it's jitter/drop rate? > > > > > > Well this is actually the other way around. > > > > First you have your default topology. They you are asked to > > construct new one based on applied constrains. > > > > So you create complete TE coverage and start running end to end data > > plane probing over all TE paths (say SR-TE for specific example). Once > > you start collecting the probe results you can start excluding paths > > which do not meet your applied constraints. And that process continues. > > > > To your specific question - It is not that unusual where routers degrade > > their performance with time and in many cases the traffic is not the > > cause for it but internal bugs and malfunctions. > > > > Best, > > R. > > > > ___ > > 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Robert, you seem to be asking that we pass full information about the dynamic network state to all routers so that they can, if needed, serve as fully intelligent path computation engines. If you want to do that, you will need more than just the telemetry. You will need the demands that are coming in to all of those routers, so that you can make global decisions sensibly. Which is why we use quasi-centralized path computation engines. Yours, Joel On 4/2/2020 6:16 PM, Robert Raszuk wrote: > 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.. [as wg member] Are you thinking that shifting traffic to a router is not going to affect it's jitter/drop rate? Well this is actually the other way around. First you have your default topology. They you are asked to construct new one based on applied constrains. So you create complete TE coverage and start running end to end data plane probing over all TE paths (say SR-TE for specific example). Once you start collecting the probe results you can start excluding paths which do not meet your applied constraints. And that process continues. To your specific question - It is not that unusual where routers degrade their performance with time and in many cases the traffic is not the cause for it but internal bugs and malfunctions. Best, R. ___ 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
aces 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 , 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) >>> 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 >>> > Sent: Thursday, April 02, 2020 5:13 AM >>> > To: Robert Raszuk >>> > Cc: Christian Hopps ; Les Ginsberg (ginsberg) >>> > ; wangyali ; Acee Lindem >>> > (acee) ; l...@ietf..org; Tianran Zhou >>> > >>> > 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 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 algo
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
ta 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) > > > > > 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 > > > > > > > Sent: Thursday, April 02, 2020 5:13 AM > > > > > > > To: Robert Raszuk > > > > > > > Cc: Christian Hopps ; Les Ginsberg (ginsberg) > > > > > > > ; wangyali ; Acee > > > > > > > Lindem > > > > > > > (acee) ; l...@ietf..org; Tianran Zhou > > > > > > > > > > > > > > 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 > > > > > > > > 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
> > 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. > > [as wg member] Are you thinking that shifting traffic to a router is not > going to affect it's jitter/drop rate? > Well this is actually the other way around. First you have your default topology. They you are asked to construct new one based on applied constrains. So you create complete TE coverage and start running end to end data plane probing over all TE paths (say SR-TE for specific example). Once you start collecting the probe results you can start excluding paths which do not meet your applied constraints. And that process continues. To your specific question - It is not that unusual where routers degrade their performance with time and in many cases the traffic is not the cause for it but internal bugs and malfunctions. Best, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
> On Apr 2, 2020, at 5:17 PM, Robert Raszuk 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. [as wg member] Are you thinking that shifting traffic to a router is not going to affect it's jitter/drop rate? > 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. will reply separately to this. Thanks, Chris. > > On Thu, Apr 2, 2020 at 11:00 PM Jeff Tantsura 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 , 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) >> 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.. >> >>
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
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 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 , 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) > 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 >> > Sent: Thursday, April 02, 2020 5:13 AM >> > To: Robert Raszuk >> > Cc: Christian Hopps ; Les Ginsberg (ginsberg) >> > ; wangyali ; Acee Lindem >> > (acee) ; l...@ietf..org ; Tianran Zhou >> > >> > 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 >>
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
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) 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 > > Sent: Thursday, April 02, 2020 5:13 AM > > To: Robert Raszuk > > Cc: Christian Hopps ; Les Ginsberg (ginsberg) > > ; wangyali ; Acee Lindem > > (acee) ; lsr@ietf.org; Tianran Zhou > > > > 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 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) > > 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 >
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 > Sent: Thursday, April 02, 2020 5:13 AM > To: Robert Raszuk > Cc: Christian Hopps ; Les Ginsberg (ginsberg) > ; wangyali ; Acee Lindem > (acee) ; lsr@ietf.org; Tianran Zhou > > 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 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) > 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 > > > Sent: Wednesday, April 01, 2020 8:12 PM > > > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > > > ; Christian Hopps > > > Cc: lsr@ietf.org; Tianran Zhou > > > 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 suggesti
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 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) > 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 > > Sent: Wednesday, April 01, 2020 8:12 PM > > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > > ; Christian Hopps > > Cc: lsr@ietf.org; Tianran Zhou > > 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 ; Les Ginsberg (ginsberg) > > ; Christian Hopps > > 抄送: lsr@ietf.org; wangyali > > 主题: Re: [Lsr] A new version of I-D, > > draft-liu-lsr-isis-ifit-node-cap
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
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) 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 > > Sent: Wednesday, April 01, 2020 8:12 PM > > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > > ; Christian Hopps > > Cc: lsr@ietf.org; Tianran Zhou > > 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 ; Les Ginsberg (ginsberg) > > ; Christian Hopps > > 抄送: lsr@ietf.org; wangyali > > 主题: 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)" 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 Zh
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
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 > Sent: Wednesday, April 01, 2020 8:12 PM > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > ; Christian Hopps > Cc: lsr@ietf.org; Tianran Zhou > 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 ; Les Ginsberg (ginsberg) > ; Christian Hopps > 抄送: lsr@ietf.org; wangyali > 主题: 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)" 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" 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 ; Christian Hopps > > Cc: wangyali ; 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 > > Sent: Tuesday, March 31, 2020 7:53 PM > > To: Christian Hopps > > Cc: wangyali ; Les Ginsberg (ginsberg) > > ; lsr@ietf.org &g
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)" 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" 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 ; Christian Hopps
Cc: wangyali ; 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
> Sent: Tuesday, March 31, 2020 7:53 PM
> To: Christian Hopps
> Cc: wangyali ; Les Ginsberg (ginsberg)
> ; 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
> Cc: Christian Hopps ; wangyali
> ; Les Ginsberg (ginsberg)
;
> 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
> 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
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" 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 ; Christian Hopps
Cc: wangyali ; 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
> Sent: Tuesday, March 31, 2020 7:53 PM
> To: Christian Hopps
> Cc: wangyali ; Les Ginsberg (ginsberg)
> ; 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
> Cc: Christian Hopps ; wangyali
> ; Les Ginsberg (ginsberg) ;
> 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
> 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
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 ; Christian Hopps Cc: wangyali ; 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 > Sent: Tuesday, March 31, 2020 7:53 PM > To: Christian Hopps > Cc: wangyali ; Les Ginsberg (ginsberg) > ; 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 > Cc: Christian Hopps ; wangyali > ; Les Ginsberg (ginsberg) ; > 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 > 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
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 > Sent: Tuesday, March 31, 2020 7:53 PM > To: Christian Hopps > Cc: wangyali ; Les Ginsberg (ginsberg) > ; 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 > Cc: Christian Hopps ; wangyali > ; Les Ginsberg (ginsberg) ; > 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 > 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
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 Cc: Christian Hopps ; wangyali ; Les Ginsberg (ginsberg) ; 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 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
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Sorry that was "as WG member" btw. > On Mar 31, 2020, at 9:59 PM, Christian Hopps wrote: > > > >> On Mar 31, 2020, at 9:28 PM, Tianran Zhou 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? > > You don't see the major difference between writing a YANG model vs modifying > all of the standard IETF routing protocols? > > Thanks, > Chris. > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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 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? You don't see the major difference between writing a YANG model vs modifying all of the standard IETF routing protocols? Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Hi Chris, Please see in line. Thanks, Tianran -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Tuesday, March 31, 2020 7:00 PM To: wangyali Cc: Les Ginsberg (ginsberg) ; Christian Hopps ; 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 6:31 AM, wangyali wrote: > > Hi Christian, > > Many thanks for your interest and question. I think netconf could also be a > valid option. > > However, this draft is not "configuring applications in the network". Yes, and please note that I recognized that later in my email. However, while this particular draft is not trying to directly configure an application, it's only use is in support of that function, so in a sense it *is* about configuring an application in the network. > The proposed solution is an easy and efficient way to advertise and collect > IFIT node capabilities. The method is same as discussed in RFC8491 to signal > MSD information. MSD is directly related to forwarding packets. Monitoring the network is generally seen as a separate application. The IGPs always represent an "easy" way to advertise anything you want about a node, but that's not justification to do so. ZTR> I actually do not understand how "directly related to forwarding packets" relates to *suitable for IGP*, otherwise not. But IFIT is a special monitoring application. It will add telemetry instructions directly into the forwarding packets. So that device can process the packet when forwarding it. Since the instruction is attached at the ingress, the egress node need to remove it to prevent the info leak. In this sense, I would conclude this IFIT capability is directly related to forwarding packets. There are other ways to query a router for it's capabilities for configuring applications that run on it, YANG is an industry standard low-bar solution, that doesn't require you change the routing protocols. 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. > One use case is to add IFIT into SR-policy through both PCEP and BGP. So when > SR-policy is deployed, IFIT functionality can be triggered automatically for > the candidate path. From this point, both the path computation and IFIT > option selection may take the IFIT node capability into consideration. Perhaps this isn't the right way to go about configuring IFIT, as it requires changes to all the routing protocols. There are other ways to do this that doesn't require changing or impacting all the routing protocols. ZTR> I feel it's very elegant to integrate IFIT into SR-Policy. So that the monitoring works close with the traffic engineering. There are already BGP and PECP extensions for SR-Policy (WG adopted). Very small changes are needed for IFIT extensions, e.g. https://datatracker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/ Cheers, Tianran Thanks, Chris. [as WG member] > > Best regards, > Yali > > > -邮件原件- > 发件人: Christian Hopps [mailto:cho...@chopps.org] > 发送时间: 2020年3月30日 17:48 > 收件人: wangyali > 抄送: Christian Hopps ; Les Ginsberg (ginsberg) > ; lsr@ietf.org > 主题: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02 > > Hi Yali, > > I think the overall concept of ifit is interesting enough. My concern is that > we aren't adding things to routing protocols (in particular IGPs) simply to > allow for another way of configuring applications in the network. This is > what netconf/YANG etc, are for. > > If I were trying to code this system up as a solution to sell it to customers > (I'm not but..), rather than starting off by trying to modify all the IETF > routing protocols to add capability advertisements (hard sell), I'd use the > protocols for router discovery (already done, no standards action needed), > and then netconf/restconf/whatever YANG to determine the router's capability > for doing IFIT stuff, just as I would to configure those same capabilities. > > Since you aren't trying to enable/disable/configure IFIT protocols with the > IGP/routing protocols (this is good!), why can't you just use the same > mechanism you use for enable/disable/configure for discovery as well? > > Thanks, > Chris. > [as WG member] > > >> On Mar 10, 2020, at 4:57 AM, wangyali wrote: >> >> Dear Les, >> >> Thanks a lot for your comments. I will take your suggestion to add >> description on how to use the IFIT Capability information when the >> submission is opened. >> >> As d
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
> On Mar 31, 2020, at 6:31 AM, wangyali wrote: > > Hi Christian, > > Many thanks for your interest and question. I think netconf could also be a > valid option. > > However, this draft is not "configuring applications in the network". Yes, and please note that I recognized that later in my email. However, while this particular draft is not trying to directly configure an application, it's only use is in support of that function, so in a sense it *is* about configuring an application in the network. > The proposed solution is an easy and efficient way to advertise and collect > IFIT node capabilities. The method is same as discussed in RFC8491 to signal > MSD information. MSD is directly related to forwarding packets. Monitoring the network is generally seen as a separate application. The IGPs always represent an "easy" way to advertise anything you want about a node, but that's not justification to do so. There are other ways to query a router for it's capabilities for configuring applications that run on it, YANG is an industry standard low-bar solution, that doesn't require you change the routing protocols. > One use case is to add IFIT into SR-policy through both PCEP and BGP. So when > SR-policy is deployed, IFIT functionality can be triggered automatically for > the candidate path. From this point, both the path computation and IFIT > option selection may take the IFIT node capability into consideration. Perhaps this isn't the right way to go about configuring IFIT, as it requires changes to all the routing protocols. There are other ways to do this that doesn't require changing or impacting all the routing protocols. Thanks, Chris. [as WG member] > > Best regards, > Yali > > > -邮件原件- > 发件人: Christian Hopps [mailto:cho...@chopps.org] > 发送时间: 2020年3月30日 17:48 > 收件人: wangyali > 抄送: Christian Hopps ; Les Ginsberg (ginsberg) > ; lsr@ietf.org > 主题: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02 > > Hi Yali, > > I think the overall concept of ifit is interesting enough. My concern is that > we aren't adding things to routing protocols (in particular IGPs) simply to > allow for another way of configuring applications in the network. This is > what netconf/YANG etc, are for. > > If I were trying to code this system up as a solution to sell it to customers > (I'm not but..), rather than starting off by trying to modify all the IETF > routing protocols to add capability advertisements (hard sell), I'd use the > protocols for router discovery (already done, no standards action needed), > and then netconf/restconf/whatever YANG to determine the router's capability > for doing IFIT stuff, just as I would to configure those same capabilities. > > Since you aren't trying to enable/disable/configure IFIT protocols with the > IGP/routing protocols (this is good!), why can't you just use the same > mechanism you use for enable/disable/configure for discovery as well? > > Thanks, > Chris. > [as WG member] > > >> On Mar 10, 2020, at 4:57 AM, wangyali wrote: >> >> Dear Les, >> >> Thanks a lot for your comments. I will take your suggestion to add >> description on how to use the IFIT Capability information when the >> submission is opened. >> >> As described in my reply to Acee, following is my quick reply: >> >> IFIT is deployed in a specific domain referred as the IFIT domain. One >> network domain may consists of multiple IFIT domain. Within the IFIT domain, >> one or more IFIT-options are added into packet at the IFIT-enabled head node >> that is referred to as the “IFIT encapsulating node”. Then IFIT data fields >> MAY be updated by IFIT transit nodes that the packet traverses. Finally, the >> data fields are removed at a device that is referred to as the “IFIT >> decapsulating node”. >> >> The IFIT data fields must not leak to other domains. So, the IFIT >> encapsulating node need to know if the decapsulating node is able to support >> the IFIT capability. So that it can decide whether to add the IFIT-option or >> not. >> >> The solution is similar to RFC8491. We use IGP to advertise the capability, >> so that head node can use. By using BGP-LS, a centralized controller can >> also learn the IFIT Capability of nodes to determine whether a particular >> IFIT Option type can be supported in a given network. >> >> Best regards, >> Yali >> >> 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] >> 发送时间: 2020年3月10日 5:07 >> 收件人: wangyali ; lsr@ietf.org >> 主题: RE: A new version of I-D, draft-liu-lsr-isis-ifit-node-ca
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Hi Yali, I think the overall concept of ifit is interesting enough. My concern is that we aren't adding things to routing protocols (in particular IGPs) simply to allow for another way of configuring applications in the network. This is what netconf/YANG etc, are for. If I were trying to code this system up as a solution to sell it to customers (I'm not but..), rather than starting off by trying to modify all the IETF routing protocols to add capability advertisements (hard sell), I'd use the protocols for router discovery (already done, no standards action needed), and then netconf/restconf/whatever YANG to determine the router's capability for doing IFIT stuff, just as I would to configure those same capabilities. Since you aren't trying to enable/disable/configure IFIT protocols with the IGP/routing protocols (this is good!), why can't you just use the same mechanism you use for enable/disable/configure for discovery as well? Thanks, Chris. [as WG member] > On Mar 10, 2020, at 4:57 AM, wangyali wrote: > > Dear Les, > > Thanks a lot for your comments. I will take your suggestion to add > description on how to use the IFIT Capability information when the submission > is opened. > > As described in my reply to Acee, following is my quick reply: > > IFIT is deployed in a specific domain referred as the IFIT domain. One > network domain may consists of multiple IFIT domain. Within the IFIT domain, > one or more IFIT-options are added into packet at the IFIT-enabled head node > that is referred to as the “IFIT encapsulating node”. Then IFIT data fields > MAY be updated by IFIT transit nodes that the packet traverses. Finally, the > data fields are removed at a device that is referred to as the “IFIT > decapsulating node”. > > The IFIT data fields must not leak to other domains. So, the IFIT > encapsulating node need to know if the decapsulating node is able to support > the IFIT capability. So that it can decide whether to add the IFIT-option or > not. > > The solution is similar to RFC8491. We use IGP to advertise the capability, > so that head node can use. By using BGP-LS, a centralized controller can also > learn the IFIT Capability of nodes to determine whether a particular IFIT > Option type can be supported in a given network. > > Best regards, > Yali > > 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > 发送时间: 2020年3月10日 5:07 > 收件人: wangyali ; lsr@ietf.org > 主题: RE: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02 > > Yali – > > What is missing for me is an explanation of why IFIT Capability information > is something that is appropriate to be sent using IGP Router Capability > advertisements. > > Generally speaking, we prefer to restrict IGP advertisements to information > which is of direct use to the protocol. However, it is fair to say that we > have relaxed this restriction in some cases e.g.: > > https://www.iana.org/go/rfc7883 > https://www.iana.org/go/rfc8491 > > However, even in these cases the information advertised is of value to some > entity executing on the protocol peers – even if not directly by the IGP > itself. > > I see no such value add here i.e., the IFIT capability information may well > be of value to a controller but I do not see any use case for any entity on > protocol peers. > So why should we use IGPs to send this information to all other IGP peers > when none of them can make use of this information? > > Les > > > From: Lsr On Behalf Of wangyali > Sent: Monday, March 09, 2020 1:21 AM > To: lsr@ietf.org > Subject: [Lsr] A new version of I-D, > draft-liu-lsr-isis-ifit-node-capability-02 > > Dear all, > > I’m Yali. Following is a new version of I-D, > draft-liu-lsr-isis-ifit-node-capability-02 I submitted recently. > > Please let me know your questions and comments. Thank you. > > >>>>>>>>> > Name: draft-liu-lsr-isis-ifit-node-capability > Revision: 02 > Title: IS-IS Extensions for Advertising IFIT Node Capability > Document date: 2020-03-09 > Group: Individual Submission > Pages: 7 > URL: > https://www.ietf.org/internet-drafts/draft-liu-lsr-isis-ifit-node-capability-02.txt > Status: > https://datatracker.ietf.org/doc/draft-liu-lsr-isis-ifit-node-capability/ > Htmlized: > https://tools.ietf.org/html/draft-liu-lsr-isis-ifit-node-capability-02 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-liu-lsr-isis-ifit-node-capability > Diff: > https://www.ietf.org/rfcdiff?url2=draft-liu-lsr-isis-ifit-node-capability-02 > > Abstract: >This
Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Yali - What is missing for me is an explanation of why IFIT Capability information is something that is appropriate to be sent using IGP Router Capability advertisements. Generally speaking, we prefer to restrict IGP advertisements to information which is of direct use to the protocol. However, it is fair to say that we have relaxed this restriction in some cases e.g.: https://www.iana.org/go/rfc7883 https://www.iana.org/go/rfc8491 However, even in these cases the information advertised is of value to some entity executing on the protocol peers - even if not directly by the IGP itself. I see no such value add here i.e., the IFIT capability information may well be of value to a controller but I do not see any use case for any entity on protocol peers. So why should we use IGPs to send this information to all other IGP peers when none of them can make use of this information? Les From: Lsr On Behalf Of wangyali Sent: Monday, March 09, 2020 1:21 AM To: lsr@ietf.org Subject: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02 Dear all, I'm Yali. Following is a new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02 I submitted recently. Please let me know your questions and comments. Thank you. >>>>>>>>> Name: draft-liu-lsr-isis-ifit-node-capability Revision: 02 Title: IS-IS Extensions for Advertising IFIT Node Capability Document date: 2020-03-09 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-liu-lsr-isis-ifit-node-capability-02.txt Status: https://datatracker.ietf.org/doc/draft-liu-lsr-isis-ifit-node-capability/ Htmlized: https://tools.ietf.org/html/draft-liu-lsr-isis-ifit-node-capability-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-liu-lsr-isis-ifit-node-capability Diff: https://www.ietf.org/rfcdiff?url2=draft-liu-lsr-isis-ifit-node-capability-02 Abstract: This document defines a way for an Intermediate System to Intermediate System (IS-IS) routers to advertise IFIT(in-situ Flow Information Telemetry) capabilities. This document extends a new optional sub-TLV in the IS-IS Router CAPABILITY TLV [RFC7981], which allows a router to announce its IFIT node capabilities within an IS- IS level or the entire routing domain. Such advertisements enable IFIT applications in the network domain. Best Regards, Yali WANG E: wangyal...@huawei.com<mailto:wangyal...@huawei.com> ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Dear all, I'm Yali. Following is a new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02 I submitted recently. Please let me know your questions and comments. Thank you. >>>>>>>>> Name: draft-liu-lsr-isis-ifit-node-capability Revision: 02 Title: IS-IS Extensions for Advertising IFIT Node Capability Document date: 2020-03-09 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-liu-lsr-isis-ifit-node-capability-02.txt Status: https://datatracker.ietf.org/doc/draft-liu-lsr-isis-ifit-node-capability/ Htmlized: https://tools.ietf.org/html/draft-liu-lsr-isis-ifit-node-capability-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-liu-lsr-isis-ifit-node-capability Diff: https://www.ietf.org/rfcdiff?url2=draft-liu-lsr-isis-ifit-node-capability-02 Abstract: This document defines a way for an Intermediate System to Intermediate System (IS-IS) routers to advertise IFIT(in-situ Flow Information Telemetry) capabilities. This document extends a new optional sub-TLV in the IS-IS Router CAPABILITY TLV [RFC7981], which allows a router to announce its IFIT node capabilities within an IS- IS level or the entire routing domain. Such advertisements enable IFIT applications in the network domain. Best Regards, Yali WANG E: wangyal...@huawei.com<mailto:wangyal...@huawei.com> ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
