Subject: Re: [OPSAWG] Strong Technology Dependency

From: Gregory Mirsky <[email-masked]>
Date: Tue, 1 Jul 2014 23:32:07 +0000

Hi Qin,
more in-lininess with the GIM2>> tag in dramatic red.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Monday, June 30, 2014 8:40 PM
To: Gregory Mirsky; [email-masked]; [email-masked]
Subject: RE: Strong Technology Dependency

Hi, Greg:

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

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]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Gregory Mirsky
Subject: RE: Strong Technology Dependency

[…]

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?
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]: 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.

GIM2>> I think of them more from on-demand vs. proactive OAM tools POV. The latter is, IMO, defect detecting tool while the former is useful for troubleshooting, mostly.

[...]

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.
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]: 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?

GIM2>> Not only in context of MPLS-TP. In fact, BFD does ensures, as Huub illustrated, that the right colored wire is plugged in. But except for MPLS-TP mis-connectivity is not being treated as a defect. the missing part – definition of mis-connectivity defect entry and exit conditions in case of IP encapsulation of BFD control packet. Perhaps for RFCs 5881, 5883, 5884 definition given in RFC 6428 may be used as foundation but must be adopted to IP encapsulation. As for choice of terms, “connectivity verification” vs. “continuity check”,  in RFC 5885 it may be debatable whether it is CV, considering possible use of ICMP and/or LSP ping, or only CC.

[…]

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

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

                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:
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]> [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: Gregory Mirsky <[email-masked]>
Date: Wed, 2 Jul 2014 01:52:57 +0000

Hi Qin,
please find my notes in-line and tagged by GIM>>.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Monday, June 30, 2014 1:04 AM
To: [email-masked]; [email-masked]
Cc: Gregory Mirsky
Subject: RE: Issue of OAM information Information gathering Gathering from Service Function

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?
GIM>> I’d propose to use “Service Function” in place of “service node” as that seems to be accepted term for an element of an Service Function Chain.

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?

GIM>> Service Functions may be applied at different network layers, not only above Layer 3. (Interesting, if SFC may include SFs at different layers.)  I’d propose to edit the first sentence of the Section 3.6.1 to
The service packets are steered through a set of service functions distributed in the network that may be applied at different layers of the network protocol stack.

---

From: Qin Wu <[email-masked]>
Date: Wed, 2 Jul 2014 02:33:08 +0000

Good point.
So what you propose seems like we should integrate BFD with IP technology and accommodate the definitions (e.g., continuity defect, Misconnection Defect, defect entry , defect exit) used in RFC6428 which is earlier applied to MPLS-TP to IP encapsulation.
Am my understanding correct?

Regards!
-Qin
发件人: Gregory Mirsky [mailto:[email-masked]]
发送时间: 2014年7月2日 7:32
收件人: 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 8:40 PM
To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Strong Technology Dependency

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

[…]

[...]

[…]

                Regards,
                                Greg

Hi, Mohamed:

Hope this clarifies.

Regards!
-Qin

Hi Qin,

Cheers,
Med

---

From: Qin Wu <[email-masked]>
Date: Wed, 2 Jul 2014 03:09:00 +0000

Hi, Sam:
I think the open issue here is the definition of CC and CV in the RFC7276 is not consistent with what Greg see CC and CV(I potential agree with his observation,☺).
e.g., the definition of CC and CV doesn’t consider misconnection defect or defect entry and exit criteria?
Therefore when we talk about whether BFC support CC or CV or whether IP Ping or LSP ping support CC or CV,
The answer become fuzzy? Do we need to tweak RFC7276 or do we need to stick the definition of RFC7276?

Regards!
-Qin
发件人: Time [mailto:[email-masked]] 代表 Sam Aldrin
发送时间: 2014年7月2日 10:54
收件人: Gregory Mirsky
抄送: [email-masked]; [email-masked]; Qin Wu
主题: Re: [Time] Strong Technology Dependency

Greg and Qin,

Couldn’t follow the thread to its entirety due to various inline questions and responses.

Is the confusion due to lack of right term to define OAM function(s) OR the existing OAM functions defined are not sufficient enough?
I believe RFC7276 identified comprehensively. Do you think something missing?

-sam
On Jul 1, 2014, at 7:38 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Qin,
if proactive continuity check viewed as not sufficient and there’s a requirement to do proactive connectivity verification. But that, IMO, will move us into more narrow segment of use cases, as we’ve learned from MPLS-TP. On-demand OAM tools would not require new definitions and can be usd for troubleshooting as-is, IMO.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, July 01, 2014 7:33 PM
To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Strong Technology Dependency

Good point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

[…]

[...]

[…]

                Regards,
                                Greg

Hi, Mohamed:

Hope this clarifies.

Regards!
-Qin

Hi Qin,

Cheers,
Med
_______________________________________________
Time mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/time

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 1 Jul 2014 20:14:50 -0700

Hi Qin,

thanks for the reply
On Jul 1, 2014, at 8:09 PM, Qin Wu <[email-masked]> wrote:

> Hi, Sam:
> I think the open issue here is the definition of CC and CV in the RFC7276 is not consistent with what Greg see CC and CV(I potential agree with his observation,J).
Establishing definition is important before discussing what each of different tools could do.
If RFC7276 doesn’t define correctly, then right thing to do is get it fixed.
But if you want to define altogether a new term, then it is fine, but I am not a big fan of that.

cheers
-sam
> On Jul 1, 2014, at 7:38 PM, Gregory Mirsky <[email-masked]> wrote:
> 
> 
> Hi Qin,
> 收件人: [email-masked]; [email-masked]
> 抄送: [email-masked]
> 发件人: [email-masked] [mailto:[email-masked]] 
> 发送时间: 2014年6月24日 22:13
> 收件人: Qin Wu
> [email-masked]

---

From: Qin Wu <[email-masked]>
Date: Wed, 2 Jul 2014 03:29:30 +0000

Sam:
This issue is related to figure 1 we gave in the section 3.2 of draft-ww-opsawg-multi-layer-oam-01(http://tools.ietf.org/html/draft-ww-opsawg-multi-layer-oam-01).
We need to figure out whether the figure 1 needs to be updated given the definition of CC and CV.

Regards!
-Qin
发件人: Time [mailto:[email-masked]] 代表 Sam Aldrin
发送时间: 2014年7月2日 11:15
收件人: Qin Wu
抄送: Gregory Mirsky; [email-masked]; [email-masked]
主题: Re: [Time] Strong Technology Dependency

Hi Qin,

thanks for the reply
On Jul 1, 2014, at 8:09 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Sam:

cheers
-sam

Regards!
-Qin
发件人: Time [mailto:[email-masked]] 代表 Sam Aldrin
发送时间: 2014年7月2日 10:54
收件人: Gregory Mirsky
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Qin Wu
主题: Re: [Time] Strong Technology Dependency

Greg and Qin,

-sam

Hi Qin,

                Regards,
                                Greg

Good point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

[…]

[...]

[…]

                Regards,
                                Greg

Hi, Mohamed:

Hope this clarifies.

Regards!
-Qin

Hi Qin,

Cheers,
Med

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 1 Jul 2014 20:33:05 -0700

Hi Qin,

RFC 7276 Sec 5.2, Table 4 does the same. :D

-sam

---

From: Qin Wu <[email-masked]>
Date: Wed, 2 Jul 2014 03:35:44 +0000

Woo, I missed to read that. Thanks for pointing this out.

Regards!
-Qin
发送时间: 2014年7月2日 11:33

Hi Qin,

-sam
On Jul 1, 2014, at 8:29 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Sam:

Regards!
-Qin
发件人: Time [mailto:[email-masked]] 代表 Sam Aldrin
发送时间: 2014年7月2日 11:15
收件人: Qin Wu
抄送: Gregory Mirsky; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [Time] Strong Technology Dependency

Hi Qin,

thanks for the reply

Hi, Sam:

cheers
-sam

Regards!
-Qin

Greg and Qin,

-sam

Hi Qin,

                Regards,
                                Greg

Good point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

[…]

[...]

[…]

                Regards,
                                Greg

Hi, Mohamed:

Hope this clarifies.

Regards!
-Qin

Hi Qin,

Cheers,
Med

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 1 Jul 2014 22:46:29 -0700

Hi Greg,

response inline.
On Jul 1, 2014, at 10:31 PM, Gregory Mirsky <[email-masked]> wrote:

> Hi Sam,
> I don’t agree with all points of RFC 7276, in particular its use of Connectivity Verification for connectionless networks.
Well, if RFC7276 defined terms incorrectly, it should be fixed, rather than re-defining the meaning here. Else we will create confusion with multiple meanings and interpretations.

> I believe that in connectionless network only Continuity Check could be realized. Tools like ICMP and LSP ping verify not connection but correlation between control plane and data plane.
I don’t think you can equate LSP ping with ICMP. And I don’t agree that LSP ping only verifies CP to DP. For ex: RFC4379 response codes 4, 5, 9 etc do not correlate CP to DP, rather verify DP. Does that make it connection verification? As per RFC7276, answer is yes. 
> To use CV to characterize them, IMO, confuses discussion and, I believe, we had it sorted during MPLS-TP work.
At least I am not confused if I use the existing definition of RFC7276. :D

-sam
>  
>                 Regards,
>                                 Greg
>  
> From: Sam Aldrin [mailto:[email-masked]] 
> Sent: Tuesday, July 01, 2014 7:54 PM
> To: Gregory Mirsky
> Cc: Qin Wu; [email-masked]; [email-masked]
> Subject: Re: [Time] Strong Technology Dependency
>  
> Greg and Qin,
>

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 1 Jul 2014 23:06:15 -0700

Hi Greg,

That would be ideal. Thanks.

Sam

Sent from my iPad

> On Jul 1, 2014, at 11:02 PM, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Sam,
> I’ll look into whether filing Errata is the best path.
>  
>                 Regards,
>                                 Greg
>  
> Sent: Tuesday, July 01, 2014 10:46 PM
> To: Gregory Mirsky

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 2 Jul 2014 02:38:04 +0000

Hi Qin,

                Regards,
                                Greg

Good point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

[…]

[...]

[…]

                Regards,
                                Greg

Hi, Mohamed:

Hope this clarifies.

Regards!
-Qin

Hi Qin,

Cheers,
Med

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 2 Jul 2014 05:31:00 +0000

Hi Sam,
I don’t agree with all points of RFC 7276, in particular its use of Connectivity Verification for connectionless networks. I believe that in connectionless network only Continuity Check could be realized. Tools like ICMP and LSP ping verify not connection but correlation between control plane and data plane. To use CV to characterize them, IMO, confuses discussion and, I believe, we had it sorted during MPLS-TP work.

                Regards,
                                Greg

Greg and Qin,

-sam

Hi Qin,

                Regards,
                                Greg

Good point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

[…]

[...]

[…]

                Regards,
                                Greg

Hi, Mohamed:

Hope this clarifies.

Regards!
-Qin

Hi Qin,

Cheers,
Med

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 2 Jul 2014 06:02:00 +0000

Hi Sam,

                Regards,
                                Greg

Hi Greg,

response inline.
On Jul 1, 2014, at 10:31 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sam,

-sam

                Regards,
                                Greg

From: Sam Aldrin [mailto:[email-masked]]
Sent: Tuesday, July 01, 2014 7:54 PM
To: Gregory Mirsky
Cc: Qin Wu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Time] Strong Technology Dependency

Greg and Qin,

-sam

Hi Qin,

                Regards,
                                Greg

Good point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

[…]

[...]

[…]

                Regards,
                                Greg

Hi, Mohamed:

Hope this clarifies.

Regards!
-Qin

Hi Qin,

Cheers,
Med

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 1 Jul 2014 19:53:46 -0700

Greg and Qin,

-sam

---

From: Qin Wu <[email-masked]>
Date: Thu, 3 Jul 2014 07:49:30 +0000

Hi, Greg:
I think the relationship between service node and service function is service node can host service function, service function maintain affinity with service node.
Service node can be virtual or physical.
Therefore to avoid confusion, I propose the following change:
s/service node/service node(virtual or physical) hosting service function.

Regards!
-Qin
发件人: Gregory Mirsky [mailto:[email-masked]]
发送时间: 2014年7月2日 9:53
收件人: Qin Wu; [email-masked]; [email-masked]
主题: RE: Issue of OAM information Information gathering Gathering from Service Function

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 3 Jul 2014 07:59:42 +0000

Hi Qin,
like your proposal. Let’s run with it.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Thursday, July 03, 2014 12:50 AM
To: Gregory Mirsky; [email-masked]; [email-masked]
Subject: RE: Issue of OAM information Information gathering Gathering from Service Function

Hi, Greg:

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Hi, Greg: