Re: [Time] Strong Technology Dependency

Sam Aldrin <aldrin.ietf@gmail.com> Wed, 02 July 2014 02:53 UTC

Return-Path: <aldrin.ietf@gmail.com>
X-Original-To: time@ietfa.amsl.com
Delivered-To: time@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC621A01DD; Tue, 1 Jul 2014 19:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqS-U-pFssZa; Tue, 1 Jul 2014 19:53:51 -0700 (PDT)
Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519B11A01DC; Tue, 1 Jul 2014 19:53:51 -0700 (PDT)
Received: by mail-pd0-f182.google.com with SMTP id y13so11076670pdi.41 for <multiple recipients>; Tue, 01 Jul 2014 19:53:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=sivvHynq4UObQGZEbO5vdkDQYGfHQNThkwRsJt+GpbI=; b=nIiYeR+tOGk3AyUGlsZHTAYcfU9KUWuDzSbol5eeqidLJve0umPC6RK2okrKugQoE3 Dvu/PxWkFLsaGeuooA1QimizVxSj1mDyYxdfmUrN0zN/FSFY8E6kRdHEAovL0TB9Q6Pa NjRMpLhybc0XV903NjHh6PUrDJe1P+Ob7zLF129DFA85pLN+49Fl5tRVBJMw622AkUxf +m8ZN1oUS7C/MrRO7WRgYEWtBZ98orWCUjardjc+VAoq4B23eH6q/+8o3J0KgK0uQV49 ZM4lzBcQKdWzluchSqkwFjQTVc6Xyj/HDFG5MTWi3prKefJtugbyTamG9CoZJdmVW3+s Eykw==
X-Received: by 10.66.139.164 with SMTP id qz4mr702424pab.151.1404269630907; Tue, 01 Jul 2014 19:53:50 -0700 (PDT)
Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id ry10sm123599298pab.38.2014.07.01.19.53.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 19:53:50 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E8E5664D-BCA7-4641-8E56-9313CAF8CEDB"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Sam Aldrin <aldrin.ietf@gmail.com>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E55DB@eusaamb103.ericsson.se>
Date: Tue, 01 Jul 2014 19:53:46 -0700
Message-Id: <772B4CEA-8B89-4F65-A33C-74F755412073@gmail.com>
References: <B8F9A780D330094D99AF023C5877DABA845491A9@nkgeml501-mbs.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330016F2E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <B8F9A780D330094D99AF023C5877DABA84573094@nkgeml501-mbs.china.huawei.com> <787AE7BB302AE849A7480A190F8B933001D499@OPEXCLILM23.corporate.adroot.infra.ftgroup> <B8F9A780D330094D99AF023C5877DABA845756DA@nkgeml501-mbs.china.huawei.com> <B8F9A780D330094D99AF023C5877DABA8457B68F@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7E4426@eusaamb103.ericsson.se> <B8F9A780D330094D99AF023C5877DABA8457BCE4@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7E52E4@eusaamb103.ericsson.se> <B8F9A780D330094D99AF023C5877DABA8457C3FA@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7E55DB@eusaamb103.ericsson.se>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/time/lKgjmgyRbk9RVh4d01bib4HM0Nc
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "time@ietf.org" <time@ietf.org>, Qin Wu <bill.wu@huawei.com>
Subject: Re: [Time] Strong Technology Dependency
X-BeenThere: time@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Transport Independent OAM in Multi-Layer network Entity \(TIME\) discussion list." <time.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/time>, <mailto:time-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/time/>
List-Post: <mailto:time@ietf.org>
List-Help: <mailto:time-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/time>, <mailto:time-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jul 2014 02:53:57 -0000

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 <gregory.mirsky@ericsson.com> 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:bill.wu@huawei.com] 
> Sent: Tuesday, July 01, 2014 7:33 PM
> To: Gregory Mirsky; time@ietf.org; opsawg@ietf.org
> Subject: RE: Strong Technology Dependency
>  
> 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:gregory.mirsky@ericsson.com] 
> 发送时间: 2014年7月2日 7:32
> 收件人: Qin Wu; time@ietf.org; opsawg@ietf.org
> 主题: RE: Strong Technology Dependency
>  
> Hi Qin,
> more in-lininess with the GIM2>> tag in dramatic red.
>  
>                 Regards,
>                                 Greg
>  
> From: Qin Wu [mailto:bill.wu@huawei.com] 
> Sent: Monday, June 30, 2014 8:40 PM
> To: Gregory Mirsky; time@ietf.org; opsawg@ietf.org
> Subject: RE: Strong Technology Dependency
>  
> Hi, Greg:
>  
> 发件人: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] 
> 发送时间: 2014年7月1日 6:33
> 收件人: Qin Wu; time@ietf.org; opsawg@ietf.org
> 主题: 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:bill.wu@huawei.com] 
> Sent: Monday, June 30, 2014 12:39 AM
> To: time@ietf.org; opsawg@ietf.org
> 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:opsawg-bounces@ietf.org] 代表 Qin Wu
> 发送时间: 2014年6月25日 16:06
> 收件人: time@ietf.org; opsawg@ietf.org
> 抄送: mohamed.boucadair@orange.com
> 主题: [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
>  
> 发件人: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] 
> 发送时间: 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
> _______________________________________________
> Time mailing list
> Time@ietf.org
> https://www.ietf.org/mailman/listinfo/time