Hi Nobo, Inline for my comments.
On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) <[email protected]> wrote: > 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 is fine as a requirement/usecase and we should limit the scope to that, than specifying how to solve it. > > > That makes this approach quite different from using proxy LSP ping. > You are talking about solution or use case? :D > > > This certainly has some pros and cons but can be quite useful as one of > the OAMs (yes plural) used to monitor the network. > Certainly. But I am struggling between use case and solution outlined in the document. Pick one :D -sam > > > 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]> 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
