Hi Qin, > -----Original Message----- > From: Qin Wu [mailto:bill...@huawei.com] > Sent: Monday, July 14, 2014 11:11 PM > To: Nobo Akiya (nobo); Sam Aldrin; ruediger.g...@telekom.de > Cc: spring; draft-geib-spring-oam-usecase > Subject: RE: [spring] Questions > > Hi, Nobo: > I agree the aspects that are missing in draft-geib-spring-oam-usecase. > Spring problem statement says the SPRING architecture will address use > cases where removal of signaling and path state in > the core is a requirement.
Yes, and additional states being required for OAM purpose should be minimized where possible, IMO. > > Now you said each network node still has states related to various segment > types. > Are you saying Non-SR node in the SR domain should not maintain any path > state or segment routing related state but SR enabled node > In the SR domain MUST have segment routing related state? Let me know if > my understanding is correct? What I meant was that a node in an SR domain needs to maintain: - local segments and remote segment in its control plane. - local segments and subset of remote segments in its data plane. And the OAM must make sure those states are correct in relevant nodes in order to allow packet steering to function properly. Thanks! -Nobo > > Regards! > -Qin > 发件人: Nobo Akiya (nobo) [mailto:n...@cisco.com] > 发送时间: 2014年7月14日 20:39 > 收件人: Qin Wu; Sam Aldrin; ruediger.g...@telekom.de > 抄送: spring; draft-geib-spring-oam-usecase > 主题: RE: [spring] Questions > > Hi Qin, et al, > > Each network node will still have some states (i.e. node/adjacency/service > segments). > > I see the technique described draft-geib-spring-oam-usecase as a way to > monitor the network, but not a way to validate the segments. In particular > the following aspects cannot be validated by the technique described draft- > geib-spring-oam-usecase. > > 1. Using a segment or combination of segments result in a packet to reach an > expected network node. > 2. Using an adjacency segment results in a packet to traverse over an > expected adjacency. > 3. Using a service segment results in a packet to hit an expected service. > > This is why I previously mentioned that the technique is useful as one of the > OAMs used to monitor the network. > > In other words, we would still want things in addition to validate the states > on each network node so that, when ingresses steer packets using > combinations segments (that makes use of those states), then expected and > actual paths aligns. > > I intentionally didn’t answer your question on the usefulness of Proxy LSP > Ping n Segment Routing, but I wanted to highlight what are the additional > points we would want to cover from OAM perspective. > > Thanks! > > -Nobo > > From: Qin Wu [mailto:bill...@huawei.com] > Sent: Monday, July 14, 2014 5:08 AM > To: Nobo Akiya (nobo); Sam Aldrin; ruediger.g...@telekom.de > Cc: spring; draft-geib-spring-oam-usecase > Subject: RE: [spring] Questions > > 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. > 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
