Re: [spring] Ben Campbell's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

[Ben Campbell <[e-mail]>]

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, [e-mail] 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?

[…]