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

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Dec 2017 19:45:31 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-spring-oam-usecase-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/

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

Substantive Comments:

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

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

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

-10, last paragraph: I don't understand the intent of this paragraph.

Editorial Comments and Nits:
- section1, first sentence: s/operator/operators
- same section, first bullet: "operators" is repeated twice. (i.e. "operators
operators") -- third bullet: "allows to transport" should be either "allows
<something> to transport" or "allows the transport". -- 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.).

-10, 2nd paragraph: " The PMS allows to insert "
That should either be "allows <something> to insert" or "Allows the insertion"
-- 3rd paragraph: I can't parse the sentence. Should "avoid a PMS to insert
traffic" be "prevent a PMS from inserting traffic"? -- 4th paragraph:
s/personal/personnel -- 5th paragraph: I can't parse the last sentence. -- 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.

---

From: <[email-masked]>
Date: Thu, 14 Dec 2017 09:56:28 +0000

Hi Ben,

thanks for your comments. I started to agree text changes with my co-editor. Takeshi and you commented on the same sentence, which can't be parsed. 

   Your comment: -10 --5th paragraph: I can't parse the last sentence.
   Takeshi's comment: 3. This sentence "As it is necessary to know that the information is
      stale is order to follow the instruction, as is the case with for
      example convergence events that may be ongoing at the time of
      diagnostic measurement." is not easy to understand for me. I see some typo
      in this sentence as well.

This text proposal has been agreed between Carlos and me:

OLD: As it is necessary to know that the information is
   stale is order to follow the instruction, as is the case with for
   example convergence events that may be ongoing at the time of
   diagnostic measurement.

NEW: To carry out a desired measurement properly, the PMS must be aware of and respect the actual route changes, convergence events, as well as the assignment of Segment IDs relevant for measurements. At a minimum, the PMS must be able to listen to IGP topology changes, or pull routing and segment information from routers signaling topology changes.

Regards,

Ruediger

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

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Substantive Comments:

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

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

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

Editorial Comments and Nits:
- section1, first sentence: s/operator/operators
- same section, first bullet: "operators" is repeated twice. (i.e. "operators
operators") -- third bullet: "allows to transport" should be either "allows <something> to transport" or "allows the transport". -- 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.).

-10, 2nd paragraph: " The PMS allows to insert "
That should either be "allows <something> to insert" or "Allows the insertion"
-- 3rd paragraph: I can't parse the sentence. Should "avoid a PMS to insert traffic" be "prevent a PMS from inserting traffic"? -- 4th paragraph:
s/personal/personnel -- 5th paragraph: I can't parse the last sentence. -- 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.

---

From: <[email-masked]>
Date: Thu, 14 Dec 2017 14:33:58 +0000

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:[email-masked]] 
Gesendet: Donnerstag, 14. Dezember 2017 04:46
An: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Ben Campbell's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

[snip]

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Dec 2017 17:27:05 -0600

> On Dec 14, 2017, at 3:56 AM, [email-masked] wrote:
> 
> Hi Ben,
> 

Hi,

That’s much easier to understand, thanks!

Ben.

[…]

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Dec 2017 17:34:00 -0600

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-masked] wrote:
> 

[…]

>    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…

That helps, thanks! You might consider changing “seems appropriate” to “is appropriate."

>    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 base…

That helps, thanks!

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

>   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…

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?

[…]

---

From: <[email-masked]>
Date: Fri, 15 Dec 2017 07:19:54 +0000

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]
>

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