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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
