On Jul 14, 2014, at 2:07 AM, Qin Wu <bill...@huawei.com> wrote: > Very good point, since segment routing doesn’t require each network node in > the path to maintain state and only ingress node maintains the state while > Proxy-lsp-ping require each network node in the return path to maintain the > state.
Wrong! No state is maintained except in the initiator. -sam > Why apply Proxy-lsp-ping to spring OAM? > > Regards! > -Qin > 发件人: spring [mailto:spring-boun...@ietf.org] 代表 Nobo Akiya (nobo) > 发送时间: 2014年7月11日 3:00 > 收件人: Sam Aldrin; ruediger.g...@telekom.de > 抄送: spring; draft-geib-spring-oam-usecase > 主题: Re: [spring] Questions > > 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:spring-boun...@ietf.org] On Behalf Of Sam Aldrin > Sent: Thursday, July 10, 2014 2:13 PM > To: ruediger.g...@telekom.de > 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, <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
