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).
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
