Subject: Re: [spring] Questions

From: <[email-masked]>
Date: Thu, 10 Jul 2014 16:15:35 +0200

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.

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.

       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.

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

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

        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.

        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.

         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.

         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.

         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.

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 10 Jul 2014 11:13:30 -0700

Hi Ruediger,

Thanks for the quick response. Please find my responses inline.

On Thu, Jul 10, 2014 at 7:15 AM, <[email-masked]> wrote:

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

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

> [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

> [RG] The PMS is able to set up packets which stay in data plane and
%sam - Execute you mean traverse? or perform something else?

>    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:
%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)

>    in data plane. Please point me to the text in proxy-ping offering this
%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

> [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

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

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

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

> [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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 10 Jul 2014 18:59:38 +0000

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:[email-masked]] On Behalf Of Sam Aldrin
Sent: Thursday, July 10, 2014 2:13 PM
To: [email-masked]
Cc: spring; draft-geib-spring-oam-usecase
Subject: Re: [spring] Questions

Hi Ruediger,

On Thu, Jul 10, 2014 at 7:15 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sam,

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.

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

       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

[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

        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>

         <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

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 10 Jul 2014 12:10:02 -0700

Hi Nobo,

Inline for my comments.

On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) <[email-masked]> wrote:

> 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-masked]] *On Behalf Of *Sam Aldrin
> *Sent:* Thursday, July 10, 2014 2:13 PM
> *To:* [email-masked]
> *Cc:* spring; draft-geib-spring-oam-usecase
> *Subject:* Re: [spring] Questions
>
>
>
> Hi Ruediger,
>
>
>
>  %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
>
>
>
>
>  %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.
>
>
>  %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
>  %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.
>
> 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.
>
>  %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.
>
> 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.
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 10 Jul 2014 19:46:17 +0000

Hi Sam,

I just wanted to point out the key described behavior, wasn’t saying anything about whether this document should be a use-case document or a solution document ☺

Thanks!

-Nobo

From: Sam Aldrin [mailto:[email-masked]]
Sent: Thursday, July 10, 2014 3:10 PM
To: Nobo Akiya (nobo)
Cc: [email-masked]; spring; draft-geib-spring-oam-usecase
Subject: Re: [spring] Questions

Hi Nobo,

Inline for my comments.

On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sam,

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.

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-masked]<mailto:[email-masked]>] On Behalf Of Sam Aldrin
Sent: Thursday, July 10, 2014 2:13 PM
To: [email-masked]<mailto:[email-masked]>
Cc: spring; draft-geib-spring-oam-usecase
Subject: Re: [spring] Questions

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 09:15:14 +0200

Hi Nobo, hi Sam

the use case is to enable monitoring of an MPLS domain without accessing the control plane. To do so, a PMS needs MPLS topology awareness, which it gets by Segment Routing. The draft to some extent explains how that is done, without going into too many details, I think.

Monitoring without control plane access is part of the use case, not part of a solution discussion (to say it differently: using the data plane for OAM purposes is not an option which may be removed). As many SR based OAM features can be used without OAM specific protocols or functions being added to Segment Routing, I think it’s perfectly ok to formulate the use case as is. The main requirement is: specify Segment Routing. Then one may add OAM boxes which apply SR features.

RFC4379 could also monitor LSPs, but it requires using the control plane and proxy-lsp-ping adds control plane based functionality to RFC4379. It is an approach resulting in similar features, but it is control plane based. This is a different use case.

If an operator needs to validate that a packet travels a certain path or trace the path a lost packet has taken, then RFC4379 functionality is needed. It’s a difference whether RFC4379 is applied only at off peak times or after a data plane only monitoring packet has been lost along one path or whether that has to be done constantly.

Regards,

Ruediger

Von: Nobo Akiya (nobo) [mailto:[email-masked]]
Gesendet: Donnerstag, 10. Juli 2014 21:46
An: Sam Aldrin
Cc: Geib, Rüdiger; spring; draft-geib-spring-oam-usecase
Betreff: RE: [spring] Questions

Hi Sam,

Thanks!

-Nobo

From: Sam Aldrin [mailto:[email-masked]]
Sent: Thursday, July 10, 2014 3:10 PM
To: Nobo Akiya (nobo)
Cc: [email-masked]<mailto:[email-masked]>; spring; draft-geib-spring-oam-usecase
Subject: Re: [spring] Questions

Hi Nobo,

Inline for my comments.

-sam

Thanks!

-Nobo

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 11 Jul 2014 08:24:29 -0700

Hi Rudiger,

As I acknowledged in my earlier emails, the question is not about valid use cases exist or not, rather it is about the document and what the text says. Document is not clear on just use cases only because it touches various solution aspects, which is unnecessary. For example, use cases should not care what RFC4379 can or cannot, that discussion should happen after the requirements which gets originated by these use cases.

Once you cleanup the document and remove solution specific parts, it should be ok. We could defer the discussion of what the existing solutions could and could not do, for solution document and continue discussions of those pieces, then.

cheers
-sam

On Jul 11, 2014, at 12:15 AM, <[email-masked]> <[email-masked]> wrote:

> I just wanted to point out the key described behavior, wasn’t saying anything about whether this document should be a use-case document or a solution document J
>  
> Thanks!
>  
> -Nobo
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 11 Jul 2014 15:49:51 +0000

Sam,

Just to be clear: a use-case document is not a set of abstract generic requirements and nothing else. Use case is not requirements to then think of a solution -- that would be a requirements document.

This document describes the specific case of how to use a specific technology (spring) to solve a particular problem. The Abstract is pretty clear on that:

Abstract

   This document describes features and a use case of a path monitoring
   system.  Segment based routing enables a scalable and simple method
   to monitor data plane liveliness of the complete set of paths
   belonging to a single domain.  [...]

This scenario cannot be decoupled from its actual use case.

I agree that additional text on showing how proxy-lsp-ping could support it can potentially be useful, but not with "remove all solutions". Further, maybe the use case can be generalized even more.

Thanks,

Carlos.

On Jul 11, 2014, at 11:24 AM, Sam Aldrin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Rudiger,

cheers
-sam

On Jul 11, 2014, at 12:15 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Nobo, hi Sam

Regards,

Ruediger

Hi Sam,

I just wanted to point out the key described behavior, wasn’t saying anything about whether this document should be a use-case document or a solution document :)

Thanks!

-Nobo

Hi Nobo,

Inline for my comments.

-sam

Thanks!

-Nobo

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 11 Jul 2014 09:07:40 -0700

Carlos,

> Just to be clear: a use-case document is not a set of abstract generic requirements and nothing else. Use case is not requirements to then think of a solution -- that would be a requirements docume…
Neither did I ask for requirements only nor to be abstract, rather to document to capture use cases, if that is what the authors intent for this document is.
> This scenario cannot be decoupled from its actual use case.
Well then the introduction says the following
<snip>
   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.
...
..
The proposed solution offers several benefits for network monitoring.
   A single centralized monitoring device is able to monitor the
   complete set of a domains forwarding paths.

<snip>

> I agree that additional text on showing how proxy-lsp-ping could support it can potentially be useful, but not with "remove all solutions". Further, maybe the use case can be generalized even more.

Again, it is up to you authors what to retain in the document or what to add.
We could review accordingly.
If there are solutions and proposals to existing solutions in this ID, then it will lead into solutions discussions, which is what is happening right now.

cheers
-sam
> 
> Thanks,
> 
> Carlos.
> 
> On Jul 11, 2014, at 11:24 AM, Sam Aldrin <[email-masked]> wrote:
> 
>> Hi Rudiger,
>> 
>> [email-masked]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 11 Jul 2014 16:29:18 +0000

Hi, Sam,

On Jul 11, 2014, at 12:07 PM, Sam Aldrin <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:

Sam,

Abstract

...
..

<snip>

Thanks for pointing these out. I think you are cherry-picking and extrapolating the word "solution" way further than intended, and adding meaning to it as if it supports requirements.

%s/The solution/The use case/
s/The proposed solution/The presented use case/

What I think would be more useful would be to channel the review cycles towards oam uses that get enabled by the spring architecture. That is,
* is this a simple remote (proxy?) realization/use for oam in spring networks?
* can this use case be generalized to the spring ipv6 dataplane? [I think so]
* can this use case be used with S-BFD?

Thanks,

Carlos.

cheers
-sam

Thanks,

Carlos.

Hi Rudiger,

cheers
-sam

Hi Nobo, hi Sam

Regards,

Ruediger

Hi Sam,

Thanks!

-Nobo

Hi Nobo,

Inline for my comments.

-sam

Thanks!

-Nobo

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 11 Jul 2014 10:25:03 -0700

Hi Carlos,

On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) <[email-masked]> wrote:

> Hi, Sam,
> 
> On Jul 11, 2014, at 12:07 PM, Sam Aldrin <[email-masked]> wrote:
> 
>> Carlos,
>> 

You are trivializing what I was eluding to in my earlier emails.
If indeed you are not talking about solution, do you think sections 4-7 talk about use cases?
When I read the document the way it is worded and understood was to PMS solution (sec #2) trying to solve problem in a specific. If you don't believe, do "%s/PMS/NMS/g" and see.

Don't misconstrue that I am saying there is no use case.

> * can this use case be used with S-BFD?
In addition, this document should add more details about the scenarios of IPv6 w.r.t SR, or add specific pointers for the same. Also consider the comments in my earlier emails. As far as S-BFD goes, refer to sec 3.4 of S-BFD use case document.

-sam

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 13 Jul 2014 07:59:30 +0000

Hi, Sam,

On Jul 11, 2014, at 6:25 PM, Sam Aldrin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Sam,

Carlos,

Sam,

Abstract

...
..

<snip>

I did not imply that you said there is no use case. My point is that the "solution" is part of the use case itself, and that a use case is not a set of requirements -- this use case document explains how the use case works (i.e., the case of the benefits for OAM of having Source Packet Routing in Networks). You were asking about removing solutions from the use case -- I am reacting to that. Otherwise, I might be misunderstanding your point.

In addition, this document should add more details about the scenarios of IPv6 w.r.t SR, or add specific pointers for the same.

Certainly these scenarios need to also be documented.

Also consider the comments in my earlier emails. As far as S-BFD goes, refer to sec 3.4 of S-BFD use case document.

Yes, this citations should be good.

Thanks,

Carlos.

-sam

Thanks,

Carlos.

cheers
-sam

Thanks,

Carlos.

Hi Rudiger,

cheers
-sam

Hi Nobo, hi Sam

Regards,

Ruediger

Hi Sam,

Thanks!

-Nobo

Hi Nobo,

Inline for my comments.

-sam

Thanks!

-Nobo

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

---

From: Sam Aldrin <[email-masked]>
Date: Sun, 13 Jul 2014 01:18:03 -0700

Hi Carlos,

comments inline.
On Jul 13, 2014, at 12:59 AM, Carlos Pignataro (cpignata) <[email-masked]> wrote:

> Hi, Sam,
> 
> On Jul 11, 2014, at 6:25 PM, Sam Aldrin <[email-masked]> wrote:
> 
>> Hi Carlos,
>> 
I am only providing comment, whether to remove or not is upto you, the authors.
If you want to keep solution, that is fine too, but that will only delay the progression of the document, because, we will be discussing which solution is better and which isn’t for a given use case.
I could see why some of the existing solutions could do some of the tasks, without the need of enhancement. As you could see from my earlier arguments, I was commenting on the solution parts, not for use case.
I prefer to see the use case be present in a simple and concise way and solution be deferred to solution document. Again, your call :D

To provide more reason for my argument, for ex: why should I care RFC4379 solve a specific use case or not? Use case is valid but it could be solved multiple ways. Similarly, I need not solve a use case with PMS, rather I could do with NMS. I do hope you see my point.

> Certainly these scenarios need to also be documented.
cool

thanks
-sam

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 13 Jul 2014 08:35:58 +0000

Hi, Sam,

Please find inline a quick follow-up.

On Jul 13, 2014, at 9:18 AM, Sam Aldrin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

comments inline.
On Jul 13, 2014, at 12:59 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Sam,

Hi Carlos,

Hi, Sam,

Carlos,

Sam,

Abstract

...
..

<snip>

I wanted to make sure I understood your point, because you always have insightful and contractive input and feedback.

My take: What you call "solution" in the paragraph above is actually part of the use case itself. There is no solution outside of and external to the use case.

A simple and concise way of presenting the context of the use case would make for a very short draft -- see the first two sentences of the Abstract:

   This document describes features and a use case of a path monitoring
   system.  Segment based routing enables a scalable and simple method
   to monitor data plane liveliness of the complete set of paths
   belonging to a single domain.

However the use case is describing how segment based routing enables this OAM method.

These are use cases that get enabled by Source Packet Routing in Networks. In the context of OAM, new ways of doing network-wide path monitoring are enabled. The point of the use case is how it can be done in spring networks that it cannot in non-spring ones.

thanks

Anytime.

Thanks,

Carlos.

-sam

Thanks,

Carlos.

-sam

Thanks,

Carlos.

cheers
-sam

Thanks,

Carlos.

Hi Rudiger,

cheers
-sam

Hi Nobo, hi Sam

Regards,

Ruediger

Hi Sam,

Thanks!

-Nobo

Hi Nobo,

Inline for my comments.

-sam

Thanks!

-Nobo

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

---

From: Qin Wu <[email-masked]>
Date: Mon, 14 Jul 2014 09:07:38 +0000

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:[email-masked]] 代表 Nobo Akiya (nobo)
发送时间: 2014年7月11日 3:00
收件人: Sam Aldrin; [email-masked]
抄送: spring; draft-geib-spring-oam-usecase
主题: Re: [spring] Questions

Hi Sam,

Thanks!

-Nobo

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 14 Jul 2014 12:39:02 +0000

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:[email-masked]]
Sent: Monday, July 14, 2014 5:08 AM
To: Nobo Akiya (nobo); Sam Aldrin; [email-masked]
Cc: spring; draft-geib-spring-oam-usecase
Subject: RE: [spring] Questions

Regards!
-Qin
发件人: spring [mailto:[email-masked]] 代表 Nobo Akiya (nobo)
发送时间: 2014年7月11日 3:00
收件人: Sam Aldrin; [email-masked]<mailto:[email-masked]>
抄送: spring; draft-geib-spring-oam-usecase
主题: Re: [spring] Questions

Hi Sam,

Thanks!

-Nobo

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 14:58:14 +0200

Hi Nobo,

thanks, fully correct. The use case describes an LSP monitoring method. To validate the LSP another tool must be used. An example of the latter is RFC4379, proxy lsp or whatever else. The use case text will be clarified in the next version (and the expression solution will be removed).

Regards,

Ruediger

Von: Nobo Akiya (nobo) [mailto:[email-masked]]
Gesendet: Montag, 14. Juli 2014 14:39
An: Qin Wu; Sam Aldrin; Geib, Rüdiger
Cc: spring; draft-geib-spring-oam-usecase
Betreff: RE: [spring] Questions

Hi Qin, et al,

Thanks!

-Nobo

To: Nobo Akiya (nobo); Sam Aldrin; [email-masked]<mailto:[email-masked]>

Regards!
-Qin

Hi Sam,

Thanks!

-Nobo

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 14 Jul 2014 08:17:32 -0700

> 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

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 14 Jul 2014 09:13:53 -0700

Hi Carlos,

Inline for my reply.
On Jul 13, 2014, at 1:35 AM, Carlos Pignataro (cpignata) <[email-masked]> wrote:

> On Jul 13, 2014, at 9:18 AM, Sam Aldrin <[email-masked]> wrote:
> 
>> Hi Carlos,
>> 
>> comments inline.
I understand what you say but the when I read the document, I see it otherwise. Here are few snippets.
Not cherry picking as you put it, I could copy whole draft if you want :D

- In Sec 3.1
Once the MPLS paths (Node SIDs) and the required IP address
   information has been detected, the LER i to LER j can be monitored by
   the PMS.  Monitoring doesn't require MPLS OAM functionality, it is
   purely based on forwarding.

When the text assert that MPLS OAM is not required, that is where I see as a problem as it is clearly comparing the the solution. Your intention here may be that (putting words in your mouth) it is one of the methods to do so, but I read the text differently.

- In Sec 3.1 again
Monitoring an MPLS domain by a PMS based on SR offers the option of
   monitoring complete MPLS domains with little effort and very
   excellent scalability.  Data plane failure detection by circulating
   monitoring packets can be executed at any time.  The PMS further
   executes MPLS OAM functions everywhere in the MPLS domain.  It does
   not require access to LSR/LER management interfaces to do so.  MPLS
   traceroutes as specified above should be executed only during off
   peak times (and then with limited parallel MPLS ping/trace load).

Here too, I see it applies more to a specific solution. I’d rather see the text eluding something like (may not be exact) “Liveness detection of the data plane in the SR could be performed between any segments initiated from non LSR/LER environments"

- Sec 7

While the PMS based use cases explained in Section 3 is sufficient to
   provide Continuity check between LER i and LER j, it may not help
   perform connectivity verification.  So in some cases like data plane
   programming corruption, it is possible that a transit node between
   LER i and LER j erroneously remove the top segment ID and forward to
   PMS based on bottom segment ID leading to falsified path liveliness
   to PMS.

I read the text (and subsequent text in the section) as describing how the connectivity verification solution by PMS should be performed.

From your emails I understand the intention and goal. Edits to the text and making it non-solution specific is what I feel is needed.

cheers
-sam

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 14 Jul 2014 09:25:20 -0700

Hi Nobo,

> This is why I previously mentioned that the technique is useful as one of the OAMs used to monitor the network.
Without going too much into it, the question is not about the need for a technique and this use case document should do that exactly.
But what I would like to see the scope/text not deliberate on the specifics of the solution, which I think was affirmed by you and others.

If you read the document as is, it proposes a solution(Introduction) and using that filter, I see the document more of a solution than just use case. 
I do hope we are in agreement, cleaning up the doc will remove the confusion.

We could take solution specific discussions to different ID’s.

-sam

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Jul 2014 02:46:23 +0000

发件人: spring [mailto:[email-masked]] 代表 Sam Aldrin
发送时间: 2014年7月14日 23:18
收件人: Qin Wu
抄送: Nobo Akiya (nobo); spring; draft-geib-spring-oam-usecase; [email-masked]
主题: Re: [spring] Questions

On Jul 14, 2014, at 2:07 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Wrong!

[Qin]: I am a little bit confused when you say no state is maintained in other network node.
Does Proxy-lsp-ping require the path to be setup before initiating proxy LSP ping message?
How does the initiator know the upstream neighbor's upstream neighbor?
Section 2 of  draft-ietf-mpls-proxy-lsp-ping-02 said:
“
The initiator requests Proxy information so that it can learn additional
information it needs to use to form a subsequent MPLS Proxy Ping
request.”
How does  proxy LSP have proxy information? Does it require path setup in advance?
Please correct me if I am wrong.

-sam

Regards!
-Qin

Hi Sam,

Thanks!

-Nobo

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Jul 2014 03:10:34 +0000

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.

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?

Regards!
-Qin
发件人: Nobo Akiya (nobo) [mailto:[email-masked]]
发送时间: 2014年7月14日 20:39
收件人: Qin Wu; Sam Aldrin; [email-masked]
抄送: spring; draft-geib-spring-oam-usecase
主题: RE: [spring] Questions

Hi Qin, et al,

Thanks!

-Nobo

Regards!
-Qin

Hi Sam,

Thanks!

-Nobo

Hi Ruediger,

Regards,

Ruediger

      Sam Aldrin wrote:

      <snip>

         6. In sec 3.1,
         <snip>

         <end snip>

cheers
-sam

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 14 Jul 2014 21:11:12 -0700

Qin,

I do not want to hijack this thread to discuss solution as this is about use case draft.
Discussion should happen at the time of solution draft or respective draft(read proxy lsp ping draft).
As you sent the questions anyway, find my brief replies inline.

-sam

> Does Proxy-lsp-ping require the path to be setup before initiating proxy LSP ping message?
Yes,
> How does the initiator know the upstream neighbor's upstream neighbor?
whoever implements a solution based on the need should know how to form a proxy request and where to get the info from.
For example: Info could be gotten from tree trace of the topology OR read from the IGP in the case of SR OR read from the dB of the topology collected via various means :D

> How does  proxy LSP have proxy information? Does it require path setup in advance?
There is no proxy LSP. Either case, the same answer as above applies.

-sam

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Jul 2014 04:24:46 +0000

[Qin]:a Typo, it should proxy LSR.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 15 Jul 2014 22:16:15 +0000

Hi Qin,

> -----Original Message-----
> Sent: Monday, July 14, 2014 11:11 PM
> Spring problem statement says the SPRING architecture will address use
> cases where removal of signaling and path state in

Yes, and additional states being required for OAM purpose should be minimized where possible, IMO.

> 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

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

> 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.
> 
> 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
> 
> 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
> 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.
> 
> 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
> 
> %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:
> 
> 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)
> 
> are describing is, how you use lsp ping rather than what lsp ping does. Again
> I am not talking about non-mpls topology.
> [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
> 
> 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.
> lsp selectors as defined in RFC4379, in this case it is local host dest ip addr,
> to identify each link member.
> - if the operator wants to make sure that data plane corresponds to control
> plane, RFC4739 functions should be applied.
> 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.
> [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
> 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
>

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 15 Jul 2014 22:25:30 +0000

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:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Tuesday, July 15, 2014 3:16 PM
To: Qin Wu; Sam Aldrin; [email-masked]
Cc: spring; draft-geib-spring-oam-usecase
Subject: Re: [spring] Questions

Hi Qin,

> 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?

Thanks!

-Nobo

> 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.
> 
> 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
> 
> 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.
> 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.
> 
> 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
> 
> - 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)
> 
> %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.
> 
> [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:
> 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)
> 
> %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.
> [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
> 
> 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.
> [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.
> or treetrace to get topology. I do not think IGP extensions being 
> proposed in SPRING export any of the info other than label stack.
> 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?
> 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.
> 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.
> validation by crafting packets with data available with treetrace and ping with multipath.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 16 Jul 2014 01:01:12 +0000

Hi Greg,

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2014 6:25 PM
> To: Nobo Akiya (nobo); Qin Wu; Sam Aldrin; [email-masked]
> 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

> 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
> with multipath.