Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03

"Srihari Raghavan (srihari)" <srihari@cisco.com> Tue, 07 February 2017 09:15 UTC

Return-Path: <srihari@cisco.com>
X-Original-To: lime@ietfa.amsl.com
Delivered-To: lime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C306D129560; Tue, 7 Feb 2017 01:15:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 re0t4mmDNVSe; Tue, 7 Feb 2017 01:15:04 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5671295A6; Tue, 7 Feb 2017 01:15:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30036; q=dns/txt; s=iport; t=1486458904; x=1487668504; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=psjDoSX0Zpfo0r85YUsmrxEc9RmHWpRtbnx6LCIhh5c=; b=fVzx4jWl0tM0+dGMYMkv2nakP7Hrwe79qzWYmLHiyTEl/tzC3yF5htL3 ZDmd1YBjM2x7bIgzi5BKkFkVanlS8cZ9AF3CiIwL/eejpkzNWcK54o3Cc CBoGQ2vYR9ZzQBsnsoQoGSVDY1bQuPU7GosS1zV0VFI3L15no6gwNZjd3 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ATAQA2j5lY/4oNJK1TChkBAQEBAQEBAQEBAQcBAQEBAYJvYmGBCQeNWZIPiAyNKoIMHwEMhXYCglw/GAECAQEBAQEBAWIohGkBAQEEAQFsCxACAQgRAQIBAiEHByEGCxQDBggBAQQBDQWJWwMVDrFnhzoNhAoBAQEBAQEBAQEBAQEBAQEBAQEBAQEdizuCUYFbSB6FJwWPPotxOAGGZ4cKhBmBe4UXiXCKL4hdAR84fk8VPIQLgjd1AYgRgQwBAQE
X-IronPort-AV: E=Sophos;i="5.33,345,1477958400"; d="scan'208,217";a="209243922"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Feb 2017 09:15:02 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v179F1eZ030564 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Feb 2017 09:15:02 GMT
Received: from xch-rtp-008.cisco.com (64.101.220.148) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Feb 2017 04:15:00 -0500
Received: from xch-rtp-008.cisco.com ([64.101.220.148]) by XCH-RTP-008.cisco.com ([64.101.220.148]) with mapi id 15.00.1210.000; Tue, 7 Feb 2017 04:15:00 -0500
From: "Srihari Raghavan (srihari)" <srihari@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Ron Bonica <rbonica@juniper.net>
Thread-Topic: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03
Thread-Index: AdJybpjwy6XJbjqnRfKoMW2LrCMAfwJqBU0AAVj+vIA=
Date: Tue, 07 Feb 2017 09:15:00 +0000
Message-ID: <D4BF87C6.3C1AC%srihari@cisco.com>
References: <BLUPR0501MB2051BD77E1AE017AF9C614CFAE7E0@BLUPR0501MB2051.namprd05.prod.outlook.com> <CA+RyBmWQcBC3nrCRfvgL6RRpXnubBe25LSsWViY8c8SoL4wLKg@mail.gmail.com>
In-Reply-To: <CA+RyBmWQcBC3nrCRfvgL6RRpXnubBe25LSsWViY8c8SoL4wLKg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.87.165]
Content-Type: multipart/alternative; boundary="_000_D4BF87C63C1ACsrihariciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/ejiwbIYSXCQspEgvIZqzzg5S2sc>
Cc: "draft-ietf-lime-yang-connectionless-oam.all@ietf.org" <draft-ietf-lime-yang-connectionless-oam.all@ietf.org>, "lime@ietf.org" <lime@ietf.org>
Subject: Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03
X-BeenThere: lime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." <lime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lime>, <mailto:lime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lime/>
List-Post: <mailto:lime@ietf.org>
List-Help: <mailto:lime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lime>, <mailto:lime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2017 09:15:06 -0000

Hi Greg

Thanks much for your comments and for your time.  Pl. find replies inline.

Thanks
Srihari

From: Lime <lime-bounces@ietf.org<mailto:lime-bounces@ietf.org>> on behalf of Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Tuesday, 31 January 2017 at 11:36 PM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: "draft-ietf-lime-yang-connectionless-oam.all@ietf.org<mailto:draft-ietf-lime-yang-connectionless-oam.all@ietf.org>" <draft-ietf-lime-yang-connectionless-oam.all@ietf.org<mailto:draft-ietf-lime-yang-connectionless-oam.all@ietf.org>>, "lime@ietf.org<mailto:lime@ietf.org>" <lime@ietf.org<mailto:lime@ietf.org>>
Subject: Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03

Dear Authors, LIME WG Chairs, et.al<http://et.al>,
please consider my comments as part of WG LC discussion.

  *

3.1<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.1>.  TP Address

     *   I think that this topic requires more discussion. In what case, which network technology developed at IETF MAC may identify test point? [Authors]: Please refer to VPLS technology described in RFC6136.
     *   FEC is the most common case among listed. In fact, FEC unlikely fits into this list if we understand it as group of IP packets which are forwarded in the same manner over the same path, and with the same forwarding treatment. In other words, we have the same destination, same next hop, egress interface and CoS marking (note that some of these parameters may be as wild card).  [Authors]: Note that FEC is special type of tp-address-type-value. The FEC defined here is used as test point addressing, not focus on forwarding treatment, maybe we could change the terminology into something else to avoid confusion.  Pl. see next bullet.
     *   IP Address, whether v4 or v6, does not sufficiently define the Test Point and must be associated with the parameter that defines forwarding treatment of a test packet addressed to the Test Point, e.g. DSCP for IP or TC for MPLS. True, often CoS parameter is set by default but that doesn't exclude it from the list of parameters that define the Test Point. [Authors]: The test point defined here is an abstract conception. It is a technology independent attribute. Therefore, we only defined test-point-location/address to distinguished different test point type.  Model user can extend the test point by adding other technology specific parameters. Not sure forwarding treatment should be part of test point location in this base model.  Perhaps, a generic name like ‘addressing-attribute’ or ‘addressing-type’ or ‘TP-attribute’ that can take on values like DSCP for IP or TC for MPLS and can replace the ‘FEC’ in the previous bullet.
     *   I don't know of a case when this is true "a pair of source, destination addresses, and interface (Useful for BFD)". Could you please elaborate, give an example?[Authors]: According to previous discussion, these need be removed. It will be fixed in next version.
     *   "System-id to represent the device or node" Like in Segment Routing? Example, reference would be helpful.  [Authors] System-id as written in the document refers to something that identifies the system in the network and hence could be ‘router-id’ similar to ISIS usage.  Pl. refer: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-05. We will add some explanations in next version.
  *

3.2<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.2>.  Tools

     *   "performance measurement" As I understand, model of performance measurement OAM is outside the scope of this document. [Authors]: Thanks, we will fix it.
     *   I think this section would be the proper place do discuss proactive and on-demand OAM tools, give examples of each and how they being used in network operations. [Authors]: Yes, we propose to do that in next version.
  *

3.3<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.3>.  OAM-layers

     *   "each layer has its own OAM protocols"
        *   s/protocols/protocol/
        *   I think that that is not necessarily the case, e.g. BFD may be used in IP/MPLS underlay and L3VPN overlay.[Authors]: Agree. Perhaps it can modified to “each layer may have its own OAM protocol”.
     *   "OAM-layers is referred to a list of upper layer, lower layer that are related to current test point. This allow users to easily navigate up and down to efficiently troubleshoot a connectivity issue at different layer."
        *   Something is missing in the first sentence.
        *   s/this allow/this allows/[Authors]: Will fix.
        *   Connectionless network does not include connection as element of its architecture and thus there's no mis-connection defect. Perhaps you were referring to loss of continuity defect here.[Authors]: The intention is to track down fault at the adjacent layer that is beyond connectionless nework. If this creates confusion, we can remove connection-oriented-location parameter.
     *   I don't agree with the proposed use of OAM level. If we consider OAM of a service that traverses multiple administrative domains, then Service OAM must be at the same level regardless of domain. Service OAM would be the outmost top level. Each operator may enable OAM test points in its respective segment so that each of segment would be at the same OAM level, e.g. Link OAM at the very bottom with Segment OAM between Service and Link OAM levels. [Authors]: The oam level can help to improve efficiency of fault localization. For example, the user may track down fault location by correlating faults at different levels and different locations and after checking the OAM levels, initiate ‘triggered’ or ‘follow-on’ OAM detection.  But as you mention, by default, a test point will be set in the same level.
  *

3.5<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.5>.  Test Point Locations

     *   The last sentence is hard to parse and it leaves impression of circular reference with the definition of Test Point Location Information definition in the previous section.
  *   "... data model is made generic enough to allow active, passive and hybrid OAMs to do the retrieval"
     *   This being mentioned in reference to Path Discovery Data and Continuity Check Data. I'd imagine that an OAM mechanism, would it be active, passive or hybrid, produces the data but the retrieval of data done using non-OAM protocol, e.g. RPC, gRPC or else. [Authors]: Thanks, we will fix it by re-wording it to say, retrieval by multiple methods.
  *

3.8<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.8>.  OAM data hierarchy

     *   I think that "oper" as name for the container that holds operational information is confusing. Could it be extended, more self-explanatory?  [Authors]: Thanks, we would like to make it more clearly. May be we can call it ‘cc-oper-data’…Thoughts?
     *   I there are more than two types of TP (IPv4 or IPv6), e.g. System-id, why container oper for continuity-check statistics holds only for IPv4 and IPv6 types of TP? [Authors]:Here we want to define the most common case of operation statistics, therefore, it holds only for IPv4 & IPv6. And extensions are possible by future designers.
     *   as-number-location may be part of tp-address, but as identifier of a Test Point? Could you please give an example.  [Authors]:They may be used by VPNv4/VPNv6 opaque encoding
     *   I believe that connection-oriented-location as part of tp-address grouping is not correct.  [Authors]: we will remove this parameter in the next version.
     *   As connectionless network does not use notion of connection, OAM in connectioless network does not include tools to conduct connectivity verification and to detect mis-connection defect. Hence there's no definition of in and out of mis-connection defect for connectionless networks.  [Authors]: Our understanding: Please refer to table 4 of RFC7276 In RFC7276,CV has broad meaning and which can be applied to both CO network and CL network.
     *   I don't agree with the list of values the 'tp-address-type-value' leaf may take. As noted earlier, MAC unlikely to be used as address of a test point in connectionless network and so FEC identifier.  [Authors]: Our understanding: As mentioned above under MAC and FEC discussion, different layer OAM has different addressing mechanism, FEC identifier can be regarded as a special location value which is applied to a portion of the network or network segment…maybe we can change 'tp-address-type-value' into 'tp-location-type-value’.  Thoughts?

Nits:

  *   cc - is missing from Terminology section
  *    FEC is missing from Terminology section
  *   [lime retrieval methods] appears as reference but has no real document it points to[Authors] Will fix in the next revision.

I don't support publication of this version.

Regards,
Greg

  *

On Thu, Jan 19, 2017 at 8:12 AM, Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote:
Folks,

This message begins a Working Group Last Call on draft-ietf-lime-yang-connectionless-oam-03. Please submit comments by February 3, 2017.

                                                                            Ron

_______________________________________________
Lime mailing list
Lime@ietf.org<mailto:Lime@ietf.org>
https://www.ietf.org/mailman/listinfo/lime