Hi Greg, > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mir...@ericsson.com] > Sent: Tuesday, July 15, 2014 6:25 PM > To: Nobo Akiya (nobo); Qin Wu; Sam Aldrin; ruediger.g...@telekom.de > Cc: spring; draft-geib-spring-oam-usecase > Subject: RE: [spring] Questions > > Hi Nobo, et. al, > allow me to offer my $.02. > > " 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." > > I think that OAM must be able to detect defect, in this case inconsistency > between control/management plane and data plane, and localize it. > Ensuring that control/management plane is in sync, in stable state, with the > data plane, IMO is responsibility of O&M. (OAM and O&M being used > according to RFC 6291).
Fully agree that what you crisply described is a critical aspect that we need to achieve with the SPRING O&M. Thanks! -Nobo > > Regards, > Greg > > -----Original Message----- > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Tuesday, July 15, 2014 3:16 PM > To: Qin Wu; Sam Aldrin; ruediger.g...@telekom.de > Cc: spring; draft-geib-spring-oam-usecase > Subject: Re: [spring] Questions > > 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 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
