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

[<[e-mail]>]

Hi Ben,

again thanks for your comments. Please find new text proposals below. A line indent followed by [RG] marks the starting point for proposed text changes.

Nits: comment followed by a brief statement, beginning with [RG].

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Ben Campbell [mailto:[e-mail]] 
Gesendet: Donnerstag, 14. Dezember 2017 04:46
An: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Betreff: Ben Campbell's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

[snip]

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

- [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. 

- [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, .....


-- [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.

Editorial Comments and Nits:
- section1, first sentence: s/operator/operators       [RG] ok
-- same section, first bullet: "operators" is repeated twice. (i.e. "operators operators")    [RG] ok
-- third bullet: "allows to transport" should be either "allows <something> to transport" or "allows the transport".  [RG] "allows the transport of" ok

- 4th bullet, last
sentence: I suggest the following: OLD: [...] since both sender and receiver have the same clock, sequence numbers to ease the measurement...). NEW: [...] since both sender and receiver have the same clock and sequence numbers to ease the measurement.).  
[RG] ok

-10, 2nd paragraph: " The PMS allows to insert "
That should either be "allows <something> to insert" or "Allows the insertion"         [RG] "allows the insertion of" ok

-- 3rd paragraph: I can't parse the sentence. Should "avoid a PMS to insert traffic" be "prevent a PMS from inserting traffic"?   [RG] "prevent..." ok.

 -- 4th paragraph:  s/personal/personnel   [RG] ok  (Takeshi caught this nit too)

-- 5th paragraph: I can't parse the last sentence.  [RG] mee too (and I author it...). Takeshi commented this sentence too, new text proposal was distributed.

-- 6th paragraph: "As soon as the PMS has an indication, that its IGP or MPLS topology are stale..." The comma between "indication" and "that" should be removed.    [RG] ok