Subject: [OPSAWG] Strong Technology Dependency

From: Qin Wu <[email-masked]>
Date: Wed, 25 Jun 2014 08:05:41 +0000

Hi, Mohamed:
Thanks for details review to problem statement draft
http://tools.ietf.org/html/draft-ww-opsawg-multi-layer-oam-00
and update I sent to you.

Regarding strong technology dependency issue,
Section 4.2 gives an address scheme  example to explain why the existing OAM mechanism has strong
Technology as follows:
“

Addressing scheme is a good example for an issue

that has a high price for being non-generic.  Ping of IPv4 and IPv6

looks different in the addressing scheme as well in the ICMP

indication field, but they have the same OAM functionalities.
”
You asked to clarify the exact point of this paragraph.
I think what this paragraph said is
For IP ping, IPv4 Ping protocol [RFC792] and IPv6 ping protocol [RFC4443] use different IP technology but share the same OAM function.

But I agree with you address scheme is not a typical example for strong technology dependency.
I think the typical example is ICMP, LSP Ping and MPLS-TP OAM are using different network technology but share the same OAM
functionality, i.e., Path Discovery.  Another example is ICMP,BFD,LSP Ping and MPLS-TP OAM are using different network technology but share
the same functionality, i.e., continuity check.

The following figure shows common OAM functionalities shared by various existing OAM protocols.
   |--------+-----------+--------------+--------------+------------+
   |        |Continuity |  Connectivity|    Path      | Performance|
   |        |  Check    |  Verification|  Discovery   | Monitoring |
   +--------+-----------+--------------+--------------+------------+
   |        |           |              |              |            |
   | ICMP   |           |   Echo(Ping) |  Traceroute  |            |
   |        |           |              |              |            |
   +--------+-----------+--------------+--------------+------------+
   |        |           |              |              |            |
   | BFD    |  BFD      |   BFD Echo   |              |            |
   |        | Control   |              |              |            |
   +--------+-----------+--------------+--------------+------------+
   | LSP    |           |              |              | - Delay    |
   | Ping   |           |   Ping       |  Traceroute  | - Packet   |
   |        |           |              |              |    Loss    |
   +--------+-----------+--------------+--------------+------------+
   |        |           |              |              |            |
   | IPPM   |           |              |              |            |
   |        |           |              |              |            |
   |--------+-----------+--------------+--------------+------------+
   | MPLS-TP|           |              |              |            |
   | OAM    |  CC       |   CV         |  Traceroute  | -Delay     |
   |        |           |              |              | -Packet    |
   |        |           |              |              |   Loss     |
   +--------+-----------+--------------+--------------+------------+

Hope this clarifies.

Regards!
-Qin

发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2014年6月24日 22:13
收件人: Qin Wu
主题: RE: Unified oam BOF proposal request in IETF 90

Hi Qin,

Please find attached a first set of comments.

Cheers,
Med

---

From: Qin Wu <[email-masked]>
Date: Wed, 25 Jun 2014 08:25:56 +0000

Hi, again:
Regarding Issue of OAM information Gathering from Service Function described in section 4.6,
“
   When the service packets is steered through a set of service nodes
   distributed in the network, each service node work at different
   layers above layer 3 and may have several SFs collocated with itself.
   When OAM mechanism is applied, it is necessary to allow OAM packet
   exchanged between these service nodes or service function at
   different layers. when Service function involved in the SFC doesn't
   support OAM capability(e.g., SF is SFC-unaware service function),
   Service node should be responsible for monitor and diagnose the
   Service function and check service availability to these service
   function.  It is more desirable to allow service function register to
   service node.  Either service function report status to service node
   or service node perform live check to these service function.

   In addition, service functions usually don't have Layer 2-3 switching/
   routing capability and therefore are not aware of any OAM function at
   layer 2-3.  Also when there is no OAM functions at service layers at
   top of layer 3, it is hard to identify layer that can be used to
   gather OAM information when it comes to a fault situation or
   degradation of performance.  For example, when a data packet is
   transmitted from one service function to another service function and
   the data packet may be lost between two service functions or
   discarded by either of service function, assume two service functions
   are embedded in two different service nodes, how to detect the fault
   between them and how to isolate problem to that layer?
”
As you said, The above text can be presented as an example to illustrate a problem not a problem per section.
I agree it is too much specific to SFC case. I am expecting to cover overlay OAM case as well.

In the overlay OAM, When any Overlay Segment fails to deliver user traffic, there is a
need to provide a tool that would enable users to detect such
failures, and a mechanism to isolate faults.  It may also be
desirable to test the data path before mapping user traffic to the
Overlay Segment.

I will see how to abstract common issue from both SFC case and Overlay OAM case.
Yes, we really need a use case draft to discuss what these use case look like and provide high-level requirements
To support various use cases.

Regards!
-Qin
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
发送时间: 2014年6月24日 22:13
收件人: Qin Wu
主题: RE: Unified oam BOF proposal request in IETF 90

Hi Qin,

Cheers,
Med

---

From: Qin Wu <[email-masked]>
Date: Mon, 30 Jun 2014 07:39:05 +0000

Thanks for comments on the following proposed table or figure as follows:
Greg>MPLS-TP uses LSP ping or, though more rarely, ICMP as-is. In fact, MPLS-TP largely re-used all IP/MPLS OAM though adding some functionality, i.e. RDI, CV, and PCS.
Greg>Again, as in previous comment, MPLS-TP OAM does not present itself “different OAM technology”.

[Qin]: You are right, I realized both LSP Ping and MPLS-OAM use MPLS technology while ICMP uses IP technology. I will fix this in the update.

Greg>should add OWAMP and TWAMP for Performance Measurement in the following table

[Qin]: Agree.

Greg>Echo(Ping) in fact belongs continuity check.

[Qin]: Agree.

Greg>Echo(Ping) does not provide CV as IP is connectionless and has no definition of Misconnection defect.

[Qin]:Not sure about this. RFC7276 said LSP Ping is used for end-to-end
  Connectivity Verification between two LERs.
Therefore I think  IP Ping can also provide CV, what am I missing?

Greg>Actually can be used for BW, Delay and Loss measurement, though very rough.

[Qin]: Agree and will add this into the  following table.

Greg>Not, BFD and BFD Echo do not provide CV for the same reason as for ICMP – do definition of Misconnection defect. Besides, BFD Echo doesn’t work for multi-hop case but only for single hop.

[Qin]: Not sure about this. RFC7276 said SP Ping is used for end-to-end
  Connectivity Verification between two LERs.
Since BFD Echo is similar to LSP Ping, I think BFD Echo also can provide CV.

Greg>LSP Ping provides Continuity Check too

[Qin]: Agree.

Greg>All MPLS-TP OAM applicable to IP/MPLS as well

[Qin]: Agree.
Greg>MPLS-TP provides CC through use of BFD
Greg>MPLS-TP provides CV through use of BFD and extension  to provide Source ID.

[Qin]: Besides using BFD, is there any other way to provide CC or CV?

发件人: OPSAWG [mailto:[email-masked]] 代表 Qin Wu
发送时间: 2014年6月25日 16:06
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: [OPSAWG] Strong Technology Dependency

Hi, Mohamed:

Hope this clarifies.

Regards!
-Qin

Hi Qin,

Cheers,
Med

---

From: Qin Wu <[email-masked]>
Date: Mon, 30 Jun 2014 08:04:27 +0000

Hi, Greg:
Thanks for comments on SFC related cases in the problem statement draft.

http://tools.ietf.org/html/draft-ww-opsawg-multi-layer-oam-01
See my reply inline below.

Greg>Service may be in form of NF instantiated in a cloud/data center. I think that in such case there would not be physical node to point to.

[Qin]:Yes, service node can be either physical node or virtual node. Do you have any proposed change here?

Greg> For the purpose of SFC OAM location of SF is irrelevant. Location of SF is OAM information of the lower layer than SFC OAM.
[Qin]:Correct, for SFC OAM, SF location doesn’t matter, what matter is where OAM information is located and where OAM function is performed.
Any proposed change here?

---

From: Tom Taylor <[email-masked]>
Date: Mon, 30 Jun 2014 09:05:00 -0400

I think one problem here is over-use of the word "connectivity". Aren't 
you really testing for reachability?

Tom Taylor

On 30/06/2014 3:39 AM, Qin Wu wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 30 Jun 2014 22:33:12 +0000

Hi Qin,
thank you for kind consideration of my comments. Glad we’re agree on most so we can clip them and concentrate on few remaining.
Please find my notes in-line and tagged GIM>> below.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Monday, June 30, 2014 12:39 AM
To: [email-masked]; [email-masked]
Cc: Gregory Mirsky
Subject: RE: Strong Technology Dependency

[…]

[Qin]:Not sure about this. RFC7276 said LSP Ping is used for end-to-end
  Connectivity Verification between two LERs.
Therefore I think  IP Ping can also provide CV, what am I missing?
GIM>> I think of CV as proactive OAM mechanism that detects particular defect and has clear definition of defect entry and defect exit criteria. LSP Ping verifies consistency between control and data plane. That, IMO, is close to CV but without definition of defect state is not the CV.

[...]

[Qin]: Not sure about this. RFC7276 said SP Ping is used for end-to-end
  Connectivity Verification between two LERs.
Since BFD Echo is similar to LSP Ping, I think BFD Echo also can provide CV.
GIM>> Unlike LSP Ping BFD does not verify consistency of data plane vs. control plane. BFD could and may be used as CV if it would be accompanied with definition of Misconnection Defect, its Entry and Exit conditions and how the defect gets signaled, i.e. through Diag field. So far applicability of the code for Mis-connectivity defect, defined in RFC 6428, not been discussed in IP or IP/MPLS networks but only in MPLS-TP domains.

[…]

[Qin]: Besides using BFD, is there any other way to provide CC or CV?
GIM>> I think of CV as optional mode that may be realized with the help of CC mechanism. Thus, in addition to Loss of Continuity defect, there must be definition of Mis-connection defect. It could be BFD, CCM/ETH-CC or else (though not sure whether there’s anything “else”).

                Regards,
                                Greg

发件人: OPSAWG [mailto:[email-masked]] 代表 Qin Wu
发送时间: 2014年6月25日 16:06
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: [OPSAWG] Strong Technology Dependency

Hi, Mohamed:

Hope this clarifies.

Regards!
-Qin

Hi Qin,

Cheers,
Med

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 30 Jun 2014 22:51:26 +0000

Hi Tom,
I agree that agreeing on terminology is important, if not critical to in order to have productive discussion and to reach positive results.
I think that "reachability" is "continuity", i.e. availability of a path between two end-points.
"Connectivity" does include "continuity" but as well, IMO, it monitors for unwarranted OAM packets either sent by unexpected source of addressed to other destination. "Connectivity", IMO, requires presence of "connection" defined between two end-points.

	Regards,
		Greg

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: Monday, June 30, 2014 6:05 AM
To: Qin Wu; [email-masked]; [email-masked]
Cc: Gregory Mirsky
Subject: Re: [OPSAWG] Strong Technology Dependency

I think one problem here is over-use of the word "connectivity". Aren't you really testing for reachability?

Tom Taylor

On 30/06/2014 3:39 AM, Qin Wu wrote:
> Greg>should add OWAMP and TWAMP for Performance Measurement in the 
> Greg>following table
>
> [Qin]: Agree.
>
> Greg>MPLS-TP provides CC through use of BFD MPLS-TP provides CV 
> Greg>through use of BFD and extension  to provide Source ID.
>
> Regarding strong technology dependency issue, Section 4.2 gives an 
> address scheme  example to explain why the existing OAM mechanism has 
> strong Technology as follows:
> “
>
> I think the typical example is ICMP, LSP Ping and MPLS-TP OAM are 
> using different network technology but share the same OAM 
> functionality, i.e., Path Discovery.  Another example is ICMP,BFD,LSP Ping and MPLS-TP OAM are using different network technology but share the same functionality, i.e., continuity check.
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 1 Jul 2014 03:40:02 +0000

Hi, Greg:

发件人: Gregory Mirsky [mailto:[email-masked]]
发送时间: 2014年7月1日 6:33
收件人: Qin Wu; [email-masked]; [email-masked]
主题: RE: Strong Technology Dependency

Hi Qin,

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Monday, June 30, 2014 12:39 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Gregory Mirsky
Subject: RE: Strong Technology Dependency

[…]

[Qin]: Interesting point, maybe we can category CV into strict CV and loose CV. I think you are talking about strict CV.
Alternatively, we may need a clear definition of CV that can be applied to any technologies, i.e., technology independent terminology.

[...]

[Qin]: So your point is the current BFD only can integrated into MPLS-TP to provide CV, am I right?
What about RFC5885 “Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)”, can I understand it as BFD being integrated with PW to provide CV?

[…]

[Qin] Yes, CC and CV can be complementary. We need to generalize these terms and apply them to various technologies.

                Regards,
                                Greg

Hi, Mohamed:

Hope this clarifies.

Regards!
-Qin

Hi Qin,

Cheers,
Med