Hi Ruediger, Thanks for the quick response. Please find my responses inline.
On Thu, Jul 10, 2014 at 7:15 AM, <ruediger.g...@telekom.de> wrote: > 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. %sam - I believe you say it is use case document below. Then solution is too premature at this point of time, as we haven't deliberated on the requirements either. > > 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. > %sam - OK. then I'd like to see any specific solution content removed, that way we dont have to discuss what other solutions does either or compare with :D > 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. > %sam - Execute you mean traverse? or perform something else? > > [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. > %sam - If it is proposing extensions, it has to be solution document and cannot claim to be use case document. Also this document is on information track. > > [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. > %sam - RFC4379 performs validation of dataplane and also find out lot more errors. You need additional information to perform validation checks. For liveness detection, BFD is preferred tool, atleast in present deployments.So are you saying, PMS solution is designed for liveness detection and not to perform validation of data plane to control plane, etc? (I think you agree to this in the later part of the doc also) > 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. > %sam - This you could perform even without proxy ping. The function you are describing is, how you use lsp ping rather than what lsp ping does. Again I am not talking about non-mpls topology. To answer your question, how you perform. - Perform treetrace with rfc4379 to get topology info - pick any arbitary LSP paths discovered along with its multipath implementation. - perform ping with right selectors for the path and use TTL for limiting the hop [LER j]. - if you want to perform from LER i to LER j as in your draft, use proxy ping to start from LER i > > 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. > %sam - nod > > 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. > %sam - The same steps described above could be used if each bundled link member is identified with a unique label. While performing tree trace or ping with multipath, LER i will respond with DDMAP info for each of the links and the multipath info for the same. If you say that each link member has same label stack, then you could use lsp selectors as defined in RFC4379, in this case it is local host dest ip addr, to identify each link member. Now if the MPLS forwarding layer sees the bundled link as one interface but cannot discern its link members, then you could only validate the interface and not its individual members. Same applies in your case too. Cannot see how it is different. > > > 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. > %sam - So, you are saying that you still need to perform RFC4379 trace or treetrace to get topology. I do not think IGP extensions being proposed in SPRING export any of the info other than label stack. And the proposed PMS solution (not use case) is that, it performs on demand per segment, which Proxy ping also does, albeit only for MPLS topology. The case you are making is that no need of bells and whistles of RFC4379. Question I have for you is, if data plane packets are getting dropped and PMS packets going through, for a given LSP or Segment, how do you know there is a problem? if you know, how do you figure out where it is? At least with RFC4379 and/or proxy ping, you could validate each hop because of the bells and whistles it carries along with the 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. > %sam - The problem I am having is, in the case of MPLS, for OAM, you have to validate the lsp. I definitely see a specific need for SPRING, but what I feel is, the use case is too much catered to a specific envisioned solution. Once you remove solution or suggested enhancements, hope it should be clear on what is being solved and scope out clear requirements for a solution. For solution part, please publish a separate ID. > > 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. > %sam - There are tools which are part of NMS/OSS, which performs MPLS topology specific operations for a given set of LSP's. They perform Treetrace and perform ping with multipath. Also perform LSP specific validation by crafting packets with data available with treetrace and ping with multipath. You could automate the workflow without the need for OSS/PMS, by using probe technology. Will not say beyond that :D cheers -sam
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
