Hi Sam, Just to point out one thing about this document …
The test packet generated from a PMS/NMS/EMS/network-device can have the complete segment stack on how to traverse the network as well as how to come back to self without any further signaling, OAM state maintenance on network nodes nor OAM involvement by network nodes. That makes this approach quite different from using proxy LSP ping. This certainly has some pros and cons but can be quite useful as one of the OAMs (yes plural) used to monitor the network. Thanks! -Nobo From: spring [mailto:[email protected]] On Behalf Of Sam Aldrin Sent: Thursday, July 10, 2014 2:13 PM To: [email protected] Cc: spring; draft-geib-spring-oam-usecase Subject: Re: [spring] Questions Hi Ruediger, Thanks for the quick response. Please find my responses inline. On Thu, Jul 10, 2014 at 7:15 AM, <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/spring
