Hi Sam,
my replies are marked [RG] and added to your text.
- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for every
SR data plane (MPLS + IPv6). We'll clarify that in the draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use case
can use any OAM (in particular, specific good uses for BFD, and ICMPv6)
Based on that, it¹s a solution with broader scope and better fit for SPRING as
a whole.
As you write, SR based OAM partially offers similar functions as proxy-lsp.
Without requiring the additional messages and LER/LSR processing introduced by
proxy-lsp.
Regards,
Ruediger
Sam Aldrin wrote:
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.
[RG] Thanks. It's a use case document. We'll review the text of section 1.
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?
[RG] The PMS is able to set up packets which stay in data plane and execute a
desired
chain of MPLS LSPs.
[RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping
[RFC4379] to
allow a third party to remotely cause an MPLS Echo Request message to
be sent down a LSP or part of an LSP.
[RG] I take it as saying that if you'd like to remotely execute RFC4379
functionality on any LSP, you could either use the PMS or proxy-ping. The PMS
however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like proxy-ping to
check data
plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS
implementation.
b) once PMS detected data plane liveliness and correctness of MPLS topology by
RFC4379,
it can continue to execute arbitrary LSP combinations and the monitoring
packets stay
in data plane. Please point me to the text in proxy-ping offering this
feature.
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?
[RG] That's a valid point. The domain external system is one option and the
team will deal with the security aspects raised by this option once we are in
solution space. We will not analyse this in depth for a use case document.
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?
[RG] The SR OAM author team has provided text how to monitor a bundled link in
the use case draft. You are a co-author of proxy-lsp. I couldn't find explicit
text on how to detect and monitor a bundled link in draft-proxy-lsp. Please
describe how proxy-lsp can be used to monitor a bundled link (sorry if this is
obvious and I missed it). If there are differences to the SR OAM approach,
we'll discuss them.
5. sec #5, Is the requirement here only for PMS to learn the topology,
in the
case of mixed env?
[RG] MPLS topology awareness is the precondition to set up packets with label
stacks executing a desired chain of LSPs. If suitable Label/FEC/node relation
is known to the PMS, that LSP can be executed from that node on by a PMS
monitoring packet.
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.
[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based on
control plane information.
- if the operator wants to make sure that data plane corresponds to control
plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states something
different, I'll try to reword it.
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.
[RG] I've never heard of an EMS/NMS which is MPLS topology aware and uses this
topology awareness to create data plane packets executing LSP combinations as
desired by an operator. Had this feature been commercially available, the
company I work for wouldn't have been developing a PMS.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
