HI, Thanks for your response. Additional comments inline. I removed sections that do not seem to need further discussion.
Thanks! Ben. > On Dec 14, 2017, at 8:33 AM, [email protected] wrote: > […] > > Substantive Comments: > > > - [BC] General: I note there has been discussion about why this draft is > Informational rather than something else. There's an explanation in the > shepherd's writeup. It would be helpful to have the same explanation as a > note in the draft. (People rarely read the shepherd's report once an RFC is > published.) > > [RG] I'd suggest to add this explanation as a last section of the > Introduction: > > [I-D.ietf-mpls-spring-lsp-ping] discusses SR OAM applicability and > MPLS traceroute enhancements adding functionality to the use cases > described by this document. > > 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 seems appropriate. That helps, thanks! You might consider changing “seems appropriate” to “is appropriate." > > - [BC] 3, last paragraph: " Further options, like deployment of a PMS > connecting to the MPLS domain by a tunnel only require more thought, as this > implies security aspects." I have trouble parsing that. Is it intended as an > open issue, or a statement that the "further options" are out of scope? Also, > consider deleting the word "only". > > [RG] > > OLD: Further options, like > deployment of a PMS connecting to the MPLS domain by a tunnel only > require more thought, as this implies security aspects. MPLS so far > separates networks securely by avoiding tunnel access to MPLS > domains. > > NEW: The option to connect a PMS to an MPLS domain by a tunnel may be > attractive to some operators. MPLS so far separates networks securely by > avoiding tunnel access to MPLS domains. Tunnel based access of a PMS to an > MPLS domain is out of scope of this document, as it implies additional > security aspects. That helps, thanks! > > > - [BC] 4.1, 2nd to last paragraph: > I'm not sure what to make of the "In theory at least," prefix. Normally IETF > RFCs are about what (we hope) works in _practice_. > > [RG] > OLD: In theory at least, a single PMS is able to monitor data plane > availability of all LSPs in the domain. The PMS may be a router, ..... > > NEW: 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, ….. That works, but you might consider changing the first two sentences along the following lines: “While a single PMS can detect … , a reliable deployment requires two separated PMS." > > > -- [BC] 10, last paragraph: I don't understand the intent of this paragraph. > > [RG] > > 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. 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? […]
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
