Subject: [spring] Questions

From: Sam Aldrin <[email-masked]>
Date: Wed, 9 Jul 2014 14:02:01 -0700

Hi Authors,

I have few questions about this draft.

1. The title is confusing to me. It says OAM use case but in section #1 it says the following

<snip>
This document describes a solution to this problem statement and
   illustrates it with use-cases.

   The solution is described for a single IGP MPLS domain.

   The solution applies to monitoring of LDP LSP's as well as to
   monitoring of Segment Routed LSP's.
<end snip>

In fact the draft is describing a solution to certain scenarios and not just providing use cases/scenarios. My understanding was, use case draft should document scenarios where it will drive new requirements. Solutions could be covered with existing toolset or defined newly, depending on the GAP analysis. But that should be separate as there could be more than 1 solution, where as this document could just focus on use cases only.

If infact this is supposed to be a solution document, then changing the title would be more meaningful. That's my observation.

2. w.r.t. Section number #2, the same problem is being solved with "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in this section could be done with the proxy ping(solution wise) where, request could be sent to monitor LER i and LER j segment, from a PMS. Is my understanding right? If not, how is it different here?

3. When the response is sent back to PMS which is not part of MPLS or segment domain, there is a serious security aspect, which needs to considered. I believe it applies to sending a request too. Will you be documenting that aspect?

4. Sec 3.2 to monitor bundle links, one could perform that with RFC4379 ping with multpath + proxy ping. Could you kindly differentiate if there is something new the solution brings here?

5. sec #5, Is the requirement here only for PMS to learn the topology, in the case of mixed env? 

6. In sec 3.1, 
<snip>
Determining a path to be executed prior to a measurement may also be
   done by setting up a label including all node SIDs along that path
   (if LER1 has Node SID 40 in the example and it should be passed
   between LER i and LER j, the label stack is 20 - 40 - 30 - 10).  The
   advantage of this method is, that it does not involve MPLS OAM
   functionality and it is independent of ECMP functionalities.  The
   method still is able to monitor all link combinations of all paths of
   an MPLS domain.  If correct forwarding along the desired paths has to
   be checked, RFC4739 functionality should be applied also in this
   case.

<end snip>

In the above you mention that it does not involve MPLS OAM. But later you say, RFC4379 functionality could be used. Could you clarify how could you verify a path, if MPLS validation is not done. More text will help. Also, more importantly, the text earlier to the above says, for valid result, MPLS OAM has to be performed for topology changes etc. If so, it contradicts here.

7. Last but not the least, how different is PMS from EMS and NMS? Somehow I couldn’t find the difference what PMS could do and NMS/EMS couldn’t.

cheers
-sam