Hi Ben, thanks for your help. I repeat sections with agreed text following your suggestions below. I’d like to start with your question related to the content:
> -- [BC 1] 10, last paragraph: I don't understand the intent of this > paragraph. > > [RG 1] > > OLD: A PMS may operate routine measurements. If these are automated, > care > must be taken to avoid unintended traffic insertion. On the other > hand, large scale operation based on operator configuration itself is > a source of unintended misconfigurations and should be avoided. > > NEW: A PMS may be configured to permanently surveil a set of LSPs. Changes > of the Segment Routing topology may occur at any time. The PMS design must > stop a permanent LSP measurement, as soon as it detects that its locally > stored SR domain topology information related to an LSP to be monitored is > stale. [BC 2] Sorry, I’m still not following it. Is the point that a PMS may continuously monitor a set of LSPs, but it needs to stop doing that for a particular LSP if that LSP changes? [RG 2] Yes, that’s the point. There are global segments and these should be stable. An LSP then may be broken, if a router is completely disconnected and a measurement packet might be dropped, which is a valid result. However a node may also assign local segments and their values might be dynamic. Reading these labels from a PMS likely requires access to the router management plane. That is feasible and that’s what our (LDP label) PMS implementation does. If the value of these labels changes after a router re-start, a PMS not adapting its topology database may misinsert packets at that router. This must be avoided, I think. Guts feeling tells me, the danger is biggest with automated measurement set up. The good case of a measurement set up with a stable label base is easier to implement than detection of topology change events, evaluation of that change, adaptation of measurements (stop, wait for topology recovery, repeat measurement set up, log event…). Would a longer explanation help? Regards, Ruediger NEW: The document describes both use cases and a standalone monitoring framework. The monitoring system re-uses existing IETF OAM protocols and leverage Segment Routing (Source Routing) to allow a single device to both sends and receives its own probing packets. As a consequence, there are no new interoperability considerations. Standard Track is not required and Informational status _is_ appropriate. NEW: _While_ a single PMS can detect the complete MPLS control- and data plane topology _, a_ reliable deployment requires two separated PMS. Scalable permanent surveillance of a set of LSPs could require deployment of several PMS. The PMS may be a router, …..
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
