From nobody Thu Oct 1 07:19:18 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64F31A6F67 for ; Thu, 1 Oct 2015 07:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 Vj3IieCDrIlY for ; Thu, 1 Oct 2015 07:19:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAAD1A6F57 for ; Thu, 1 Oct 2015 07:19:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 92E031E387; Thu, 1 Oct 2015 10:23:02 -0400 (EDT) Date: Thu, 1 Oct 2015 10:23:02 -0400 From: Jeffrey Haas To: lime@ietf.org Message-ID: <20151001142302.GA10279@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 14:19:17 -0000 As usual, I've been behind. I spent most of the last day reading through my backlog of email to the list and several of the published Internet-Drafts for the working group. Thanks also to Greg and Mahesh that tried to engage me, but caught me during that busy time. As I mentioned at the microphone at IETF-92 (I think), I have *strong* concerns about trying to wedge in CFM semantics into IETF IP and MPLS OAM. Having caught up on the current documents, that concern has not been allayed. Things I like about the current document is a move toward a uniform set of tests. These are covered in the RPCs. However, as I try to reconcile the CFM semantics which are appropriate to some media with what is possible to retrieve using the proposed IP/MPLS mechanisms, I think there's an outright mismatch on the things being reported. LIME is not chartered to invent new mechanisms, only to provide modeling layers toward those. This means that either the mechanisms need a far more specific output, or work needs to be taken to other groups to add in the missing statistics. The ability to probe up and down the layers is a good property of LIME, in my opinion. Where things get very ugly very fast is trying to uniformly apply CFM semantics to general IP or MPLS networks. For example, the idea of a given IP network being part of a maintenance domain is appealing from a CFM modeling standpoint. However, the existing level model will break apart very quickly once you start trying to model complex service providers. Some providers have a very simple "core" services layer and several "client" networks attached to that core. That would fit. However, when the roles overlap, especially in VPN scenarios, CFM semantics' need to avoid overlap becomes problematic. This gets even more complicated when the model tries to expand beyond a single service provider into inter-domain scenarios. I encourage those participants who are working within organizations like IEEE to produce a yang model of existing CFM. I think that will be a useful technology to complement IETF technologies. I also encourage the working group to go back to the white board and work from known IP and MPLS use cases back toward the underlying layers instead of the other way around. While I certainly agree that IEEE/ITU OAM is very mature, I don't believe it's a proper fit for our work. What I suspect is that if we start by trying to take the RPC models in terms of functionality and work from the IETF technologies, we'll likely overlap in the RPCs and a portion of the reporting from them to transitioning to underlying OAMs. Basically, we're likely to end up with two universes of modeling sharing common RPCs but leading toward differing models for representing a given layer. However, that's an opinion that's not supported from trying to do this work; I just strongly believe that trying to force IP networks into CFM semantics will lead to a bunch of angry IP service providers who want to know why they're being forced to provision CFM parameters in order to run the unified traceroute/ping/etc. -- Jeff From nobody Fri Oct 2 03:55:48 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE54F1B29E9 for ; Fri, 2 Oct 2015 03:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 1ffzbI9YhfQ7 for ; Fri, 2 Oct 2015 03:55:45 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958E31B29EA for ; Fri, 2 Oct 2015 03:55:43 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail41.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 02 Oct 2015 12:55:40 +0200 X-IronPort-AV: E=Sophos;i="5.17,622,1437429600"; d="scan'208";a="335602599" X-IPAS-Result: A0DIAQApYg5W/2ldhgpeHAEBAYNcbr1/AQ2BUx4KhXkCgXEUAQEBAQEBAYEKhCUBAQEDAQEBawsQAgFHBycLFBEBAQQOBQiIM8tQAQEBAQEBAQEBAQEBAQEBAQEBAQEUBJAbEQEgMQeDGIEUBY0/iD2IBoZnhDiCfI5qg28fAQGCWBiBVm+IOIFAAQEB Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 02 Oct 2015 12:55:30 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 2 Oct 2015 12:55:29 +0200 From: To: Date: Fri, 2 Oct 2015 12:55:28 +0200 Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AdD8VEIPskTWxJcJS9qSiVvK7KU+mQAq1BPg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D286BED0140@HE111648.emea1.cds.t-internal.com> References: <20151001142302.GA10279@pfrc.org> In-Reply-To: <20151001142302.GA10279@pfrc.org> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: lime@ietf.org Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 10:55:47 -0000 Hi Jeff, what is then your proposal for Lime: Not focussing on CFM semantics? Is your concern related to different definitions in IETF resp. IEEE etc. or= general? Could you give an example of the reporting missmatch you are concerned, ple= ase. Regards Roland -----Urspr=FCngliche Nachricht----- Von: Lime [mailto:lime-bounces@ietf.org] Im Auftrag von Jeffrey Haas Gesendet: Donnerstag, 1. Oktober 2015 16:23 An: lime@ietf.org Betreff: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? As usual, I've been behind. I spent most of the last day reading through m= y backlog of email to the list and several of the published Internet-Drafts= for the working group. Thanks also to Greg and Mahesh that tried to engag= e me, but caught me during that busy time. As I mentioned at the microphone at IETF-92 (I think), I have *strong* conc= erns about trying to wedge in CFM semantics into IETF IP and MPLS OAM. Having caught up on the current documents, that concern has not been allaye= d. Things I like about the current document is a move toward a uniform set of = tests. These are covered in the RPCs. However, as I try to reconcile the = CFM semantics which are appropriate to some media with what is possible to = retrieve using the proposed IP/MPLS mechanisms, I think there's an outright= mismatch on the things being reported. LIME is not chartered to invent new mechanisms, only to provide modeling la= yers toward those. This means that either the mechanisms need a far more s= pecific output, or work needs to be taken to other groups to add in the mis= sing statistics. The ability to probe up and down the layers is a good property of LIME, in = my opinion. Where things get very ugly very fast is trying to uniformly apply CFM seman= tics to general IP or MPLS networks. For example, the idea of a given IP n= etwork being part of a maintenance domain is appealing from a CFM modeling = standpoint. However, the existing level model will break apart very quickl= y once you start trying to model complex service providers. Some providers have a very simple "core" services layer and several "client= " networks attached to that core. That would fit. However, when the roles o= verlap, especially in VPN scenarios, CFM semantics' need to avoid overlap b= ecomes problematic. This gets even more complicated when the model tries to expand beyond a sin= gle service provider into inter-domain scenarios. I encourage those participants who are working within organizations like IE= EE to produce a yang model of existing CFM. I think that will be a useful = technology to complement IETF technologies. I also encourage the working group to go back to the white board and work f= rom known IP and MPLS use cases back toward the underlying layers instead o= f the other way around. While I certainly agree that IEEE/ITU OAM is very = mature, I don't believe it's a proper fit for our work. What I suspect is = that if we start by trying to take the RPC models in terms of functionality= and work from the IETF technologies, we'll likely overlap in the RPCs and = a portion of the reporting from them to transitioning to underlying OAMs. Basically, we're likely to end up with two universes of modeling sharing co= mmon RPCs but leading toward differing models for representing a given laye= r. However, that's an opinion that's not supported from trying to do this = work; I just strongly believe that trying to force IP networks into CFM sem= antics will lead to a bunch of angry IP service providers who want to know = why they're being forced to provision CFM parameters in order to run the un= ified traceroute/ping/etc. -- Jeff _______________________________________________ Lime mailing list Lime@ietf.org https://www.ietf.org/mailman/listinfo/lime From nobody Fri Oct 2 06:56:01 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4C61B2BA7 for ; Fri, 2 Oct 2015 06:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 2pdt_uBniU0G for ; Fri, 2 Oct 2015 06:55:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0138.outbound.protection.outlook.com [207.46.100.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5E11B2BA6 for ; Fri, 2 Oct 2015 06:55:56 -0700 (PDT) Received: from BLUPR05MB1985.namprd05.prod.outlook.com (10.162.224.27) by BLUPR05MB1987.namprd05.prod.outlook.com (10.162.224.29) with Microsoft SMTP Server (TLS) id 15.1.280.20; Fri, 2 Oct 2015 13:55:55 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) with mapi id 15.01.0280.017; Fri, 2 Oct 2015 13:55:55 +0000 From: Ronald Bonica To: Jeffrey Haas , "lime@ietf.org" Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AQHQ/FQqpeHZ21Z+bkCnVNM48ny2Yp5YOSyQ Date: Fri, 2 Oct 2015 13:55:55 +0000 Message-ID: References: <20151001142302.GA10279@pfrc.org> In-Reply-To: <20151001142302.GA10279@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BLUPR05MB1987; 5:wZ9DsTohYD3EgWYbieXsWvXHc4WTPGuwtt8p+4EqSz/KaumtCvCtQPEmVyo6iB6st5HPotRt72kHRRHY4if4fr84WaTGuawul5ZeVt3jO7Ff+E/pjmSOIVPaFqxBIhwcQpWwk2SS0n7szo04q43Dow==; 24:t5Jys4F0NV17K/aHmWcfZfEJe3waoae4x4covNHkt9gUr2pdBSge6N2MtS7PiocU8TVY/7ElcPIcP+UDF6Koo/XDlbgyqB+d/Bxsj4alqCk=; 20:VdP0pveVqMYWerfNLZZUdDxOvP82X4qONxvPF9xEQF0kNs3bWX7sbk4PcIF0WQLrgmOvIO8vSlGBIV1lyPy6BQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1987; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BLUPR05MB1987; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1987; x-forefront-prvs: 0717E25089 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(33656002)(106116001)(40100003)(92566002)(107886002)(5007970100001)(5004730100002)(77156002)(87936001)(5001960100002)(5002640100001)(64706001)(5003600100002)(76176999)(2950100001)(86362001)(46102003)(68736005)(62966003)(66066001)(102836002)(2900100001)(2501003)(77096005)(50986999)(54356999)(74316001)(81156007)(5001830100001)(106356001)(76576001)(105586002)(5001860100001)(101416001)(10400500002)(189998001)(5001770100001)(4001540100001)(97736004)(122556002)(99286002)(5008740100001)(11100500001)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1987; H:BLUPR05MB1985.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2015 13:55:55.0234 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1987 Archived-At: Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 13:56:00 -0000 Jeff, If this assertion is true, it is very concerning. Let's put it to the test. I invite the authors of draft-tissa-lime-yang-oam model to demonstrate how = the model can be applied to IP and MPLS in an inter-domain scenario. If thi= s can be done in email, that would be great. If the demonstration requires = a higher bandwidth channel, it can be presented in Yokohama. In either event, this exercise will demonstrate whether the conceptual fram= ework proposed in draft-tissa is sufficient. Depending on the result, the W= G will take appropriate action. Ron /chair hat on >=20 > Where things get very ugly very fast is trying to uniformly apply CFM > semantics to general IP or MPLS networks. =20 From nobody Fri Oct 2 08:33:09 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EF71B2C28 for ; Fri, 2 Oct 2015 08:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 HylLwzASugH6 for ; Fri, 2 Oct 2015 08:33:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0987C1B2C26 for ; Fri, 2 Oct 2015 08:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4388; q=dns/txt; s=iport; t=1443799986; x=1445009586; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hRo7gVu2sIx4ghAAkf9MR6OgU/0iAmQLsrCads2uOkg=; b=kcd53PxgqsqMH6es19DVMf+dZw/c2biH0j9iFhZYr9WQ+4Qd3XuDt6Au mXjFispE5E74iyuD3opzY+Egx1BuvVE1SDtJlCGIty4JqVBEzEaMwS1Kg PBSwg2KqyFjylRmAAsBGzZLhgeU645QoJX2JAKoN3kvaKhaLCdDjVLYsh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwAQCDog5W/4sNJK1egydUbga9egENgXEKhXkCgTU4FAEBAQEBAQGBCoQlAQEEAQEBNy0HGwIBCA4oECcLJQIEARKILg3LdQEBAQEBAQEBAQEBAQEBAQEBARYEhnOEfoQqEQFYhCwFjQWIdwGIBYURm2IBHwEBQoIWGIFUcYg4OoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,623,1437436800"; d="scan'208";a="33975274" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 02 Oct 2015 15:33:05 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t92FX49r024923 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2015 15:33:04 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 2 Oct 2015 10:33:04 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.000; Fri, 2 Oct 2015 10:33:04 -0500 From: "Deepak Kumar (dekumar)" To: Jeffrey Haas , "lime@ietf.org" Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AQHQ/FQrMB5ZOlNjo02sHj1+TbpUOJ5YNRQA Date: Fri, 2 Oct 2015 15:33:03 +0000 Message-ID: References: <20151001142302.GA10279@pfrc.org> In-Reply-To: <20151001142302.GA10279@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.79.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <52D3D75578E97C4B8A8F8C8631D90DE8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:33:08 -0000 Hi Jeffrey, I believe applicability document is trying to address the concern. We can work on adding section for inter-domain mpls/ip. MD Configuration Extension MD level configuration parameters are management information which are set by the LIME base model, as default values, and inherited by the MPLS OAM model. MD level configuration parameters provide context information for management systems to correlate faults with location information For example domain name can be set to area-ID in the MPLS OAM case. In addition, at the Maintenance Domain level, domain data node at root level can be augmented with technology type and sub-technology type. MD level configuration parameters MUST not be carried using MPLS OAM protocol(e.g., LSP Ping) since MPLS OAM protocol doesn't support transport of these management information. Thanks, Deepak On 10/1/15, 7:23 AM, "Lime on behalf of Jeffrey Haas" wrote: >As usual, I've been behind. I spent most of the last day reading through >my >backlog of email to the list and several of the published Internet-Drafts >for the working group. Thanks also to Greg and Mahesh that tried to >engage >me, but caught me during that busy time. > >As I mentioned at the microphone at IETF-92 (I think), I have *strong* >concerns about trying to wedge in CFM semantics into IETF IP and MPLS OAM. >Having caught up on the current documents, that concern has not been >allayed. > >Things I like about the current document is a move toward a uniform set of >tests. These are covered in the RPCs. However, as I try to reconcile the >CFM semantics which are appropriate to some media with what is possible to >retrieve using the proposed IP/MPLS mechanisms, I think there's an >outright >mismatch on the things being reported. > >LIME is not chartered to invent new mechanisms, only to provide modeling >layers toward those. This means that either the mechanisms need a far >more >specific output, or work needs to be taken to other groups to add in the >missing statistics. > >The ability to probe up and down the layers is a good property of LIME, in >my opinion. > >Where things get very ugly very fast is trying to uniformly apply CFM >semantics to general IP or MPLS networks. For example, the idea of a >given >IP network being part of a maintenance domain is appealing from a CFM >modeling standpoint. However, the existing level model will break apart >very quickly once you start trying to model complex service providers. > >Some providers have a very simple "core" services layer and several >"client" >networks attached to that core. That would fit. However, when the roles >overlap, especially in VPN scenarios, CFM semantics' need to avoid overlap >becomes problematic. > >This gets even more complicated when the model tries to expand beyond a >single service provider into inter-domain scenarios. > >I encourage those participants who are working within organizations like >IEEE to produce a yang model of existing CFM. I think that will be a >useful >technology to complement IETF technologies. > >I also encourage the working group to go back to the white board and work >from known IP and MPLS use cases back toward the underlying layers instead >of the other way around. While I certainly agree that IEEE/ITU OAM is >very >mature, I don't believe it's a proper fit for our work. What I suspect is >that if we start by trying to take the RPC models in terms of >functionality >and work from the IETF technologies, we'll likely overlap in the RPCs and >a >portion of the reporting from them to transitioning to underlying OAMs. > >Basically, we're likely to end up with two universes of modeling sharing >common RPCs but leading toward differing models for representing a given >layer. However, that's an opinion that's not supported from trying to do >this work; I just strongly believe that trying to force IP networks into >CFM >semantics will lead to a bunch of angry IP service providers who want to >know why they're being forced to provision CFM parameters in order to run >the unified traceroute/ping/etc. > >-- Jeff > >_______________________________________________ >Lime mailing list >Lime@ietf.org >https://www.ietf.org/mailman/listinfo/lime From nobody Fri Oct 2 08:34:44 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DE01B2C12 for ; Fri, 2 Oct 2015 08:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 0BSGCiJhVvPH for ; Fri, 2 Oct 2015 08:34:39 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4A41B2C17 for ; Fri, 2 Oct 2015 08:34:38 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-ed-560e446e65cf Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 61.21.32596.E644E065; Fri, 2 Oct 2015 10:46:38 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Fri, 2 Oct 2015 11:34:37 -0400 From: Gregory Mirsky To: Ronald Bonica , Jeffrey Haas , "lime@ietf.org" Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AQHQ/FQsQS9Qe30F6U2ishtni4XPM55YfoOA///WHGA= Date: Fri, 2 Oct 2015 15:34:36 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF112218E9C3B@eusaamb103.ericsson.se> References: <20151001142302.GA10279@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPlG6eC1+YwZ0rRhb7D75ltejYtp3J 4sB3BwdmjyVLfjJ5XG+6yu5xuXcrawBzFJdNSmpOZllqkb5dAlfGsekH2QouC1QsXnmbsYHx I08XIyeHhICJxLbem6wQtpjEhXvr2UBsIYGjjBKvV8V1MXIB2csYJU6/agFLsAkYSbzY2MMO YosIZEosedzOCGILC7hINC9sZYaIu0qs2fIUqsZK4v+8q2A2i4CKxKml98CW8Qr4SizYcJQR YkEDo0T778NgRZwCsRLPN/aDDWIEuuj7qTVMIDazgLjErSfzmSAuFZBYsuc8M4QtKvHy8T+o D5QkJi09xwpRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWM HKXFqWW56UYGmxiBEXJMgk13B+Oel5aHGAU4GJV4eBeU8IYJsSaWFVfmHmKU5mBREufdv+R+ qJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGMwWNF8decHiw9QZrHVkq/yvAh8fvtfKvWa6X 87LzhFdL6+qqpU7K3xF+SK/svs69yc5ZMh/1opWsP39b1Fg6P3Ky0oKHJ7wS5l/l66xaaacW b6XeuG/pX8Wn39c53Q1ffHNZayAX751X77neH95tX3b2FNt1s64rs/ZNvLZu3X+hi4XybSsN lViKMxINtZiLihMBCwWt4HECAAA= Archived-At: Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:34:43 -0000 Hi Ron, I believe that the draft-zhuang-lime-yang-oam-model-applicability is the gr= ound where the demonstration supposed to take place. I've reviewed and comm= ented in many details on the -00 version right after the meeting in Prague.= At the time of WG adoption call on the draft-tissa-lime-yang-oam-model I'v= e shared my comments with the WG community. As I understand the authors of = the applicability draft are updating the document. Perhaps we can have an u= pdate on the progress of their efforts and whether new version will be avai= lable for discussion in Yokohama. As of now, I'm of opinion that the draft-= tissa-lime-yang-oam-model presents OAM model of packet-switching connection= -oriented networks like Ethernet transport or MPLS-TP and does not present = adequate model of OAM for packet switching connectionless networks like IP = or IP/MPLS networks. Regards, Greg -----Original Message----- From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Friday, October 02, 2015 6:56 AM To: Jeffrey Haas; lime@ietf.org Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Jeff, If this assertion is true, it is very concerning. Let's put it to the test. I invite the authors of draft-tissa-lime-yang-oam model to demonstrate how = the model can be applied to IP and MPLS in an inter-domain scenario. If thi= s can be done in email, that would be great. If the demonstration requires = a higher bandwidth channel, it can be presented in Yokohama. In either event, this exercise will demonstrate whether the conceptual fram= ework proposed in draft-tissa is sufficient. Depending on the result, the W= G will take appropriate action. Ron /chair hat on >=20 > Where things get very ugly very fast is trying to uniformly apply CFM=20 > semantics to general IP or MPLS networks. _______________________________________________ Lime mailing list Lime@ietf.org https://www.ietf.org/mailman/listinfo/lime From nobody Fri Oct 2 08:50:16 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B2F1ACCF0 for ; Fri, 2 Oct 2015 08:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Bwc3pEzC-fjM for ; Fri, 2 Oct 2015 08:50:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BEF1A702A for ; Fri, 2 Oct 2015 08:50:06 -0700 (PDT) Received: from BLUPR05MB1986.namprd05.prod.outlook.com (10.162.224.28) by BLUPR05MB402.namprd05.prod.outlook.com (10.141.26.140) with Microsoft SMTP Server (TLS) id 15.1.280.20; Fri, 2 Oct 2015 15:49:47 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com (10.162.224.27) by BLUPR05MB1986.namprd05.prod.outlook.com (10.162.224.28) with Microsoft SMTP Server (TLS) id 15.1.280.20; Fri, 2 Oct 2015 15:49:46 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) with mapi id 15.01.0280.017; Fri, 2 Oct 2015 15:49:46 +0000 From: Ronald Bonica To: Gregory Mirsky , Jeffrey Haas , "lime@ietf.org" Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AQHQ/FQqpeHZ21Z+bkCnVNM48ny2Yp5YOSyQgAAd2wCAAAHEAA== Date: Fri, 2 Oct 2015 15:49:46 +0000 Message-ID: References: <20151001142302.GA10279@pfrc.org> <7347100B5761DC41A166AC17F22DF112218E9C3B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF112218E9C3B@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BLUPR05MB1986; 5:PzQp1/6yysFRhkq0IJjVRpxsDfp0ZRZXA/T2fcSIGB09NjTexX0gFiMWudo7IZCASumqmxkFZTJdryPmlYcpleojKS5lns5tDvEWTHHloFZUayFghkvJ0zMkUaRtWQc/yVDVYFiI4Ycco0UeiwqAwA==; 24:GaFbpMg6vayVBrtyc2IhWeC3Pon/jmETeAnlvq5sId7isU6tAYR/UrM/hF2JE7Il1SUzscpOSd2kKhbFNDWnjCbaBYy+jhw1IzQ0dq2aEBI=; 20:AcGJNcTSt5s97SZYfcemGozONdjpT7MmV9AzTHy5IM14w6jMcuXF2n319AhOdu8rl7CW63eK2rrYP5DRhNeveg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1986; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:BLUPR05MB1986; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1986; x-forefront-prvs: 0717E25089 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(13464003)(189002)(81156007)(2950100001)(97736004)(86362001)(5001770100001)(76576001)(4001540100001)(74316001)(106116001)(92566002)(68736005)(122556002)(99286002)(106356001)(105586002)(40100003)(77096005)(5001830100001)(2501003)(5001860100001)(102836002)(50986999)(66066001)(107886002)(33656002)(189998001)(64706001)(46102003)(19580405001)(19580395003)(5007970100001)(101416001)(5002640100001)(11100500001)(5004730100002)(87936001)(2900100001)(5001960100002)(62966003)(76176999)(10400500002)(15975445007)(77156002)(54356999)(5008740100001)(5003600100002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1986; H:BLUPR05MB1985.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2015 15:49:46.5403 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1986 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB402; 2:DHXqDV4Y4tKDrhT9d+54GVD2KNA0waNOKTZuyL/KC15C8XqPn1yW8JBqtbSvceB1IoWzKE+YVM1FkvMA5/o+c6cmtxSSjAaj0rVtqJbZjungPNjDzJC1XpB1Wadjub+wVyWlRZdaYs21ytFWUcKZYZHST1ACoMRKmNahXsMATKQ=; 23:fmJVqfZmVy93lm3xIwqTxBi+0HFPGxL32NOV3o5207cGFzHr+0afiyE+H6d53sjHPqrj9eBH3MM5tQhXqlrNl2Ckb7JMUnu5ZfJvHWtUipDBDR9jwMIgd02vAVIryBCv544p7mn6fg47RV8cNDQmMasHyWP76oIXFcVp3FiTlvF8W/dE1kfUonhPSDSTNfhM X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:50:14 -0000 Greg, This is true. The outcome of this exercise is relevant to both of the follo= wing drafts: - draft-zhuang-lime-yang-oam-model-applicability - the draft-tissa-lime-yang-oam-model If we find that the CFM framework is applicable to IP and MPLS, we will hav= e content for the applicability model and we will have validated the CFM as= sumptions of draft-tissa. However, if we find that the application of CFM concepts to IP and MPLS is = painful, we will have to change the direction of both drafts. = Ron > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Friday, October 02, 2015 11:35 AM > To: Ronald Bonica ; Jeffrey Haas ; > lime@ietf.org > Subject: RE: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? >=20 > Hi Ron, > I believe that the draft-zhuang-lime-yang-oam-model-applicability is the > ground where the demonstration supposed to take place. I've reviewed and > commented in many details on the -00 version right after the meeting in > Prague. At the time of WG adoption call on the draft-tissa-lime-yang-oam- > model I've shared my comments with the WG community. As I understand > the authors of the applicability draft are updating the document. Perhaps= we > can have an update on the progress of their efforts and whether new > version will be available for discussion in Yokohama. As of now, I'm of o= pinion > that the draft-tissa-lime-yang-oam-model presents OAM model of packet- > switching connection-oriented networks like Ethernet transport or MPLS-TP > and does not present adequate model of OAM for packet switching > connectionless networks like IP or IP/MPLS networks. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Ronald Bonica > Sent: Friday, October 02, 2015 6:56 AM > To: Jeffrey Haas; lime@ietf.org > Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? >=20 > Jeff, >=20 > If this assertion is true, it is very concerning. Let's put it to the tes= t. >=20 > I invite the authors of draft-tissa-lime-yang-oam model to demonstrate ho= w > the model can be applied to IP and MPLS in an inter-domain scenario. If t= his > can be done in email, that would be great. If the demonstration requires = a > higher bandwidth channel, it can be presented in Yokohama. >=20 > In either event, this exercise will demonstrate whether the conceptual > framework proposed in draft-tissa is sufficient. Depending on the result,= the > WG will take appropriate action. >=20 > Ron > /chair hat on >=20 >=20 > > > > Where things get very ugly very fast is trying to uniformly apply CFM > > semantics to general IP or MPLS networks. >=20 > _______________________________________________ > Lime mailing list > Lime@ietf.org > https://www.ietf.org/mailman/listinfo/lime From nobody Fri Oct 2 08:55:08 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6761A87AB for ; Fri, 2 Oct 2015 08:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 4DH-uLTp_ndT for ; Fri, 2 Oct 2015 08:55:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFCA1A8752 for ; Fri, 2 Oct 2015 08:55:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 87CE71E38B; Fri, 2 Oct 2015 11:58:55 -0400 (EDT) Date: Fri, 2 Oct 2015 11:58:55 -0400 From: Jeffrey Haas To: Roland.Schott@telekom.de Message-ID: <20151002155855.GI29696@pfrc.org> References: <20151001142302.GA10279@pfrc.org> <580BEA5E3B99744AB1F5BFF5E9A3C67D286BED0140@HE111648.emea1.cds.t-internal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D286BED0140@HE111648.emea1.cds.t-internal.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: lime@ietf.org Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:55:07 -0000 Roland, On Fri, Oct 02, 2015 at 12:55:28PM +0200, Roland.Schott@telekom.de wrote: > what is then your proposal for Lime: > > Not focussing on CFM semantics? > Is your concern related to different definitions in IETF resp. IEEE etc. or general? IETF OAM is very immature by comparison to IEEE/ITU. I'm fine with using semantics and perhaps terminology. Much of my concern is that since this is a data modeling exercise that we don't try to force IP and MPLS technologies (not MPLS-TP) to fit into the same configuration model one would do for CFM. To speak in a somewhat polite fashion, if you told most IP network operators that they would have to give every IP end-point CFM-style configurations to make LIME work, I think you'd find they were somewhat hostile to the idea. :-) CFM is great for places that it is already used. With respect to lower level layers that are implemented on CFM-style systems, we want to use them. The proposed data model covers this case fairly well as a service model. The IP/MPLS end of things is not covered, IMO. If I'm missing something that the authors believes shows that it is covered, an example showing an intra-domain traceroute would be helpful. Inter-domain traceroute is a good example to show as well. > Could you give an example of the reporting missmatch you are concerned, please. In path-discovery, grouping monitor-stats is used. This includes a min, average and max delay stat. This isn't something returned from many traceroute IP implementations. Perhaps it should be, but it's a bit different. -- Jeff From nobody Fri Oct 2 08:59:28 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64ACB1ACCF3 for ; Fri, 2 Oct 2015 08:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 2lAKh3jdmLeW for ; Fri, 2 Oct 2015 08:59:26 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9D97B1A7007 for ; Fri, 2 Oct 2015 08:59:26 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0631D1E38C; Fri, 2 Oct 2015 12:03:16 -0400 (EDT) Date: Fri, 2 Oct 2015 12:03:15 -0400 From: Jeffrey Haas To: "Deepak Kumar (dekumar)" Message-ID: <20151002160315.GJ29696@pfrc.org> References: <20151001142302.GA10279@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "lime@ietf.org" Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:59:27 -0000 Deepak, On Fri, Oct 02, 2015 at 03:33:03PM +0000, Deepak Kumar (dekumar) wrote: > I believe applicability document is trying to address the concern. > We can work on adding section for inter-domain mpls/ip. > [...] > For example domain name can be set to area-ID in the MPLS OAM case. In > addition, at the Maintenance Domain level, domain data node at root level > can be augmented with technology type and sub-technology type. > MD level configuration parameters MUST not be carried using MPLS OAM > protocol(e.g., LSP Ping) since MPLS OAM protocol doesn't support transport > of these > management information. I think that trying to force the semantic of MD-Level into IP protocols will likely be highly problematic for operators. Consider coordination efforts that would be required in an inter-domain fashion. That said, for IP layers, the semantic of "higher level" or "lower level" are still valid. IP may be on top of MPLS which might be on top of GRE, which might be on top of IP which might be, at a given node, on top of TDM. If we can discover the lower layers in IP, we still can drill-down. Once we have drilled down to a layer managed by CFM, the existing model would work well. My suggestion would be to work from this sort of use case in the future modeling work - and note the caveat about avoiding requiring IP/MPLS operators to configure CFM attributes at every node! I look forward to seeing such a model. -- Jeff From nobody Sat Oct 3 02:34:38 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C8C1ACE5D for ; Sat, 3 Oct 2015 02:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.952 X-Spam-Level: *** X-Spam-Status: No, score=3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no 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 5mtVKoYcqpKt for ; Sat, 3 Oct 2015 02:34:36 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120AD1ACE5B for ; Sat, 3 Oct 2015 02:34:36 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so131235449pac.2 for ; Sat, 03 Oct 2015 02:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; bh=JfEt+GwodNIzW3tVKYp3tb7wexpn5GZ423Cb4vghe1k=; b=L9eLB71nwiGGL3XNvCHA1oEiYm9f5x7m8qlqslgjUUvpNJsvr/g5C8yDGckGZ2A+n2 7woU6O9ipOWSJINIrMB2VvaflUsEloMm0nQfmfWeb9yPOmEN0Y1T17USrSXBlNAkxOb+ lhYcQByXl9ASGbLh14zRfSeni+RdLyy4NhyUVzqT9hLcYVgOddhZKuzoYewb/Uxks0sb rN4MR9W8511uI6vryH4A38Z5kp8qWksr5YTBFQaA5l8TPwYlHO0LDevU2pqQE6rtbU4d hCwMgdWf79DocZPcv4XzNPX7I/6Z5/jZ86bYmCr0WfiwwenC4EqGxyAruzvCc7YFIoAl OXkA== X-Received: by 10.66.142.202 with SMTP id ry10mr26230546pab.86.1443864875749; Sat, 03 Oct 2015 02:34:35 -0700 (PDT) Received: from [192.168.0.100] ([183.140.44.104]) by smtp.gmail.com with ESMTPSA id xm9sm16412822pbc.32.2015.10.03.02.34.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Oct 2015 02:34:34 -0700 (PDT) From: =?GB2312?Q?gmail=D3=CA=CF=E4?= Content-Type: multipart/alternative; boundary=Apple-Mail-A54ED298-D31E-403B-B0F6-2FCCA6E60DC6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Sat, 3 Oct 2015 17:34:29 +0800 To: Jeffrey Haas , lime@ietf.org, Roland Schott X-Mailer: iPhone Mail (12B440) Archived-At: Subject: [Lime] 2015-10-03 Re: CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 09:34:37 -0000 --Apple-Mail-A54ED298-D31E-403B-B0F6-2FCCA6E60DC6 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable The proposed data model covers this case fairly well as a service model. The= IP/MPLS end of things is not covered, IMO. If I'm missing something that th= e authors believes shows that it is covered, an example showing an intra-dom= ain traceroute would be helpful. Inter-domain traceroute is a good example t= o show as well.=20 =A3=DBQin=A3=DD=A3=BAAs we dicussed in the previous thread=A3=ACone example w= e gave is user A request a oam service from the management system by using l= ayer independent oam model defined by LIME=A3=ACe.g.=A3=ACtraceroute from sr= c B to dst D=A3=ACthe management system maps layer independent model into la= yer specific oam model based on oam tech used from B to D=A3=ACe.g.=A3=ACBFD= is used=A3=ACthen layer independent model is mapped to bfd model. layer ind= ependent model can provide 5 Level hierarchy if following cfm generized stru= ct=A3=ACif bfd model is extended from lime model=A3=ACbfd will be correspond= ing to lowest 3 levels struct=A3=ACthe highest levels will be set by the man= agement system or set as default value if operator doesnt like to support. a= lternatively=A3=ACif bfd doesnt want to follow comnon struct proposed by lim= e and want to use its own struct=A3=ACthen to provide consistent conf and re= porting=A3=ACwe need to rely on complicated mapping between two hetergeneous= structs. regarding interdomail case=A3=ACcharter doesn=A1=AFt put it in scope. > Could you give an example of the reporting missmatch you are concerned, p= lease. In path-discovery, grouping monitor-stats is used. This includes a min, ave= rage and max delay stat. This isn't something returned from many traceroute I= P implementations. Perhaps it should be, but it's a bit different.=20 =A3=DBQin=A3=DDsure=A3=ACwe can tweek base model to make change as u suggest= ed=A3=ACif u believe this is a serious issue. but not sure this has to do with cfm like struct=A3=ACin any case=A3=ACwe ma= ke the layer independent model more generic and extensible=A3=A1 -- Jeff =B7=A2=D7=D4=CE=D2=B5=C4 iPhone= --Apple-Mail-A54ED298-D31E-403B-B0F6-2FCCA6E60DC6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 
The proposed data model co=
vers this case fairly well as a service model.

The IP/MPLS end of things is not covered, IMO.  If I'm missing something
that the authors believes shows that it is covered, an example showing an
intra-domain traceroute would be helpful.  Inter-domain traceroute is a
good example to show as well. 
=EF=BC=BBQin=EF=BC=BD=EF=BC=9AAs we dicussed i=
n the previous thread=EF=BC=8Cone example we gave is user A request a oam se=
rvice from the management system by using layer independent oam model define=
d by LIME=EF=BC=8Ce.g.=EF=BC=8Ctraceroute from src B to dst D=EF=BC=8Cthe ma=
nagement system maps layer independent model into layer specific oam model b=
ased on oam tech used from B to D=EF=BC=8Ce.g.=EF=BC=8CBFD is used=EF=BC=8Ct=
hen layer independent model is mapped to bfd model. layer independent model c=
an provide 5 Level hierarchy if following cfm generized struct=EF=BC=8Cif bf=
d model is extended from lime model=EF=BC=8Cbfd will be corresponding to low=
est 3 levels struct=EF=BC=8Cthe highest levels will be set by the management=
 system or set as default value if operator doesnt like to support. alternat=
ively=EF=BC=8Cif bfd doesnt want to follow comnon struct proposed by lime an=
d want to use its own struct=EF=BC=8Cthen to provide consistent conf and rep=
orting=EF=BC=8Cwe need to rely on complicated mapping between two hetergeneo=
us structs.
regarding interdomail case=EF=BC=8Ccharter doesn=E2=80=99t put it in s=
cope.
 > Could you give an examp=
le of the reporting missmatch you are concerned, please.
= 
 In path-discovery, grouping monitor-stats is used.  T=
his includes a min,
average and max delay stat.  This isn't something returned from many
traceroute IP implementations.  Perhaps it should be, but it's a bit
different. 
=EF=BC=BBQin=EF=BC=BDsure=EF=BC=8Cwe can tweek base model to mak=
e change as u suggested=EF=BC=8Cif u believe this is a serious issue.=

but not sur=
e this has to do with cfm like struct=EF=BC=8Cin any case=EF=BC=8Cwe make th=
e layer independent model more generic and extensible=EF=BC=81=

 -- Jeff


=E5=8F=91=E8=87=AA=E6=88=91=E7=9A=84 iPhone<= /body>= --Apple-Mail-A54ED298-D31E-403B-B0F6-2FCCA6E60DC6-- From nobody Mon Oct 5 07:11:54 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1BC1ACE13 for ; Mon, 5 Oct 2015 07:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 LedP_lOs1c_h for ; Mon, 5 Oct 2015 07:11:51 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D3EC01ACE1B for ; Mon, 5 Oct 2015 07:11:51 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E00C71E38D; Mon, 5 Oct 2015 10:15:43 -0400 (EDT) Date: Mon, 5 Oct 2015 10:15:43 -0400 From: Jeffrey Haas To: =?utf-8?B?Z21haWzpgq7nrrE=?= Message-ID: <20151005141543.GB18260@pfrc.org> References: <20151001142302.GA10279@pfrc.org> <20151002160315.GJ29696@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "lime@ietf.org" , "Deepak Kumar \(dekumar\)" Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 14:11:53 -0000 Qin, On Sat, Oct 03, 2015 at 12:54:13PM +0800, gmail邮箱 wrote: > > I think that trying to force the semantic of MD-Level into IP protocols will > > likely be highly problematic for operators. > ［Qin］MD level parameters don’t need to be imposed to IP protocol，it is sent from the manage plane and terminated at the test points。Charter clearly said base model MUST NOT change IP protocol. Please consider that the current published yang model seems to suggest that such concepts are needed at the IP level. This is why I'm asking for a demonstration of how the model is intended to apply to IP and MPLS. If the intent is to add to the published yang model, that has not been clear from my reading of the mailing list archives. > > Consider coordination efforts > > that would be required in an inter-domain fashion. > > > ［Qin］LIME charter said the scope is restricted to single administrative domain，do we intend to change to tackle inter—domain case？ That is obviously for the chairs to comment upon. Given my background in BGP and how this mechanism is likely to be applicable at some point, I have to ask the long-term question, even if the short-term proposal is intended to be more constrained. > ［Qin］The goal of lime WG，I think， is to identify common model structure for various OAM tech at different layer. Just like http://tools.ietf.org/wg/netmod/draft-ietf-netmod-routing-cfg/ did to provide common struct for various routing tech > do u aggree with this？or u believe we should find different structure for oam at different layer？ I agree that there should be common layers. I believe that the RPCs that are currently specified have some promise to apply between the layers. I do not see how the current proposal intends to be generic to IP and MPLS since it seems to be CFM-model specific. > if it is the former，do you have better structure than CFM like struct？Modeling oam from protocol perspective is not able to come up with common oam struct. Modeling oam from fault manange and perform management perspective，u probobaly get similar struct like cfm struct. > if u have better struct，we are happy to hear！ I don't currently have a better proposal - only strong concerns about the impact of trying to impose CFM like mechanisms on IP and MPLS. I'm also doing this because I think the lime work is useful and would rather see it succeed. > > My suggestion would be to work from this sort of use case in the future > > modeling work - and note the caveat about avoiding requiring IP/MPLS > > operators to configure CFM attributes at every node! > > > ［Qin］every node？This is not our proposal。The manage plane could rely on plan info or topo info built from somewhere else to decide which testpoints need to configure，in simple IP OAM case，only src and dst testpoints need to be configure. How would you know ahead of time what nodes would need provisioning for CFM attributes? Altering parameters during troubleshooting is not how most operators want to plan their networks. -- Jeff From nobody Thu Oct 8 03:19:38 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38941ACEEE for ; Thu, 8 Oct 2015 03:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AHE7Yp1INajN for ; Thu, 8 Oct 2015 03:19:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC721ACD97 for ; Thu, 8 Oct 2015 03:19:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYN28682; Thu, 08 Oct 2015 10:19:32 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 8 Oct 2015 11:19:06 +0100 Received: from NKGEML503-MBX.china.huawei.com ([169.254.5.146]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Thu, 8 Oct 2015 18:18:59 +0800 From: "Zhuangyan (Yan)" To: Gregory Mirsky , Ronald Bonica , Jeffrey Haas , "lime@ietf.org" Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AQHQ/FRaP0Y+RA/EiUann4CCWQIDsZ5XtViAgAAbkgCACZuO4A== Date: Thu, 8 Oct 2015 10:18:58 +0000 Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785937CB94F@nkgeml503-mbx.china.huawei.com> References: <20151001142302.GA10279@pfrc.org> <7347100B5761DC41A166AC17F22DF112218E9C3B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF112218E9C3B@eusaamb103.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.170.230] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Tom Taylor Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 10:19:37 -0000 SGkgR3JlZywgUm9uLCBKZWZmIGFuZCBhbGwsDQoNClNvcnJ5IGZvciBrZWVwaW5nIHlvdSB3YWl0 aW5nLg0KDQpUaGUgbmV3IHZlcnNpb24gb2YgdGhlIExJTUUgYXBwbGljYWJpbGl0eSBkcmFmdCBo YXMgYmVlbiBwdWJsaXNoZWQgYXMgZm9sbG93czoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC16aHVhbmctbGltZS15YW5nLW9hbS1tb2RlbC1hcHBsaWNhYmlsaXR5LTAxIA0KVGhl IGRpZmYgaXM6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemh1YW5n LWxpbWUteWFuZy1vYW0tbW9kZWwtYXBwbGljYWJpbGl0eS0wMSANCg0KUGxlYXNlIGxldCB1cyBr bm93IGlmIGl0IGNhbiBhZGRyZXNzIHlvdXIgY29uY2Vybi4gQXMgdXN1YWwsIGNvbW1lbnRzIGFu ZCBzdWdnZXN0aW9ucyBhcmUgdmVyeSBhcHByZWNpYXRlZC4NCg0KUmVnYXJkcyENCg0KWWFuIGFu ZCBUb20gKG9uIGJlaGFsZiBvZiBhdXRob3JzKQ0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8 /sjLOiBMaW1lIFttYWlsdG86bGltZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEdyZWdvcnkgTWly c2t5DQq3osvNyrG85DogMjAxNcTqMTDUwjLI1SAyMzozNQ0KytW8/sjLOiBSb25hbGQgQm9uaWNh OyBKZWZmcmV5IEhhYXM7IGxpbWVAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbTGltZV0gQ0ZNIHNlbWFu dGljcywgSVAgYW5kIE1QTFMgT0FNIC0gaG93IHRvIHByb2NlZWQ/DQoNCkhpIFJvbiwNCkkgYmVs aWV2ZSB0aGF0IHRoZSBkcmFmdC16aHVhbmctbGltZS15YW5nLW9hbS1tb2RlbC1hcHBsaWNhYmls aXR5IGlzIHRoZSBncm91bmQgd2hlcmUgdGhlIGRlbW9uc3RyYXRpb24gc3VwcG9zZWQgdG8gdGFr ZSBwbGFjZS4gSSd2ZSByZXZpZXdlZCBhbmQgY29tbWVudGVkIGluIG1hbnkgZGV0YWlscyBvbiB0 aGUgLTAwIHZlcnNpb24gcmlnaHQgYWZ0ZXIgdGhlIG1lZXRpbmcgaW4gUHJhZ3VlLiBBdCB0aGUg dGltZSBvZiBXRyBhZG9wdGlvbiBjYWxsIG9uIHRoZSBkcmFmdC10aXNzYS1saW1lLXlhbmctb2Ft LW1vZGVsIEkndmUgc2hhcmVkIG15IGNvbW1lbnRzIHdpdGggdGhlIFdHIGNvbW11bml0eS4gQXMg SSB1bmRlcnN0YW5kIHRoZSBhdXRob3JzIG9mIHRoZSBhcHBsaWNhYmlsaXR5IGRyYWZ0IGFyZSB1 cGRhdGluZyB0aGUgZG9jdW1lbnQuIFBlcmhhcHMgd2UgY2FuIGhhdmUgYW4gdXBkYXRlIG9uIHRo ZSBwcm9ncmVzcyBvZiB0aGVpciBlZmZvcnRzIGFuZCB3aGV0aGVyIG5ldyB2ZXJzaW9uIHdpbGwg YmUgYXZhaWxhYmxlIGZvciBkaXNjdXNzaW9uIGluIFlva29oYW1hLiBBcyBvZiBub3csIEknbSBv ZiBvcGluaW9uIHRoYXQgdGhlIGRyYWZ0LXRpc3NhLWxpbWUteWFuZy1vYW0tbW9kZWwgcHJlc2Vu dHMgT0FNIG1vZGVsIG9mIHBhY2tldC1zd2l0Y2hpbmcgY29ubmVjdGlvbi1vcmllbnRlZCBuZXR3 b3JrcyBsaWtlIEV0aGVybmV0IHRyYW5zcG9ydCBvciBNUExTLVRQIGFuZCBkb2VzIG5vdCBwcmVz ZW50IGFkZXF1YXRlIG1vZGVsIG9mIE9BTSBmb3IgcGFja2V0IHN3aXRjaGluZyBjb25uZWN0aW9u bGVzcyBuZXR3b3JrcyBsaWtlIElQIG9yIElQL01QTFMgbmV0d29ya3MuDQoNCglSZWdhcmRzLA0K CQlHcmVnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMaW1lIFttYWlsdG86 bGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9uYWxkIEJvbmljYQ0KU2VudDog RnJpZGF5LCBPY3RvYmVyIDAyLCAyMDE1IDY6NTYgQU0NClRvOiBKZWZmcmV5IEhhYXM7IGxpbWVA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTGltZV0gQ0ZNIHNlbWFudGljcywgSVAgYW5kIE1QTFMg T0FNIC0gaG93IHRvIHByb2NlZWQ/DQoNCkplZmYsDQoNCklmIHRoaXMgYXNzZXJ0aW9uIGlzIHRy dWUsIGl0IGlzIHZlcnkgY29uY2VybmluZy4gTGV0J3MgcHV0IGl0IHRvIHRoZSB0ZXN0Lg0KDQpJ IGludml0ZSB0aGUgYXV0aG9ycyBvZiBkcmFmdC10aXNzYS1saW1lLXlhbmctb2FtIG1vZGVsIHRv IGRlbW9uc3RyYXRlIGhvdyB0aGUgbW9kZWwgY2FuIGJlIGFwcGxpZWQgdG8gSVAgYW5kIE1QTFMg aW4gYW4gaW50ZXItZG9tYWluIHNjZW5hcmlvLiBJZiB0aGlzIGNhbiBiZSBkb25lIGluIGVtYWls LCB0aGF0IHdvdWxkIGJlIGdyZWF0LiBJZiB0aGUgZGVtb25zdHJhdGlvbiByZXF1aXJlcyBhIGhp Z2hlciBiYW5kd2lkdGggY2hhbm5lbCwgaXQgY2FuIGJlIHByZXNlbnRlZCBpbiBZb2tvaGFtYS4N Cg0KSW4gZWl0aGVyIGV2ZW50LCB0aGlzIGV4ZXJjaXNlIHdpbGwgZGVtb25zdHJhdGUgd2hldGhl ciB0aGUgY29uY2VwdHVhbCBmcmFtZXdvcmsgcHJvcG9zZWQgaW4gZHJhZnQtdGlzc2EgaXMgc3Vm ZmljaWVudC4gRGVwZW5kaW5nIG9uIHRoZSByZXN1bHQsIHRoZSBXRyB3aWxsIHRha2UgYXBwcm9w cmlhdGUgYWN0aW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBSb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgL2NoYWlyIGhhdCBvbg0KDQoNCj4gDQo+IFdoZXJl IHRoaW5ncyBnZXQgdmVyeSB1Z2x5IHZlcnkgZmFzdCBpcyB0cnlpbmcgdG8gdW5pZm9ybWx5IGFw cGx5IENGTSANCj4gc2VtYW50aWNzIHRvIGdlbmVyYWwgSVAgb3IgTVBMUyBuZXR3b3Jrcy4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkxpbWUgbWFp bGluZyBsaXN0DQpMaW1lQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkxpbWUgbWFpbGluZyBsaXN0DQpMaW1lQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbWUNCg== From nobody Thu Oct 8 04:01:33 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC241B2B53 for ; Thu, 8 Oct 2015 04:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rKUVjUGvQPms for ; Thu, 8 Oct 2015 04:01:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258E61B2B4F for ; Thu, 8 Oct 2015 04:01:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCG34679; Thu, 08 Oct 2015 11:01:27 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 8 Oct 2015 12:01:26 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Thu, 8 Oct 2015 19:01:21 +0800 From: Qin Wu To: Jeffrey Haas Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AQHQ/FRZBcBgaxq3CEyPhhOApdTEkp5X0HuAgAAIcICAANdogIADwYuAgAT038A= Date: Thu, 8 Oct 2015 11:01:21 +0000 Message-ID: References: <20151001142302.GA10279@pfrc.org> <20151002160315.GJ29696@pfrc.org> <20151005141543.GB18260@pfrc.org> In-Reply-To: <20151005141543.GB18260@pfrc.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "lime@ietf.org" , "Deepak Kumar \(dekumar\)" Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 11:01:32 -0000 SGksIEplZmY6DQpTb3JyeSBmb3IgbGF0ZSByZXBseSwgSSBoYXZlIGp1c3QgY29tZSBiYWNrIGZy b20gdmFjYXRpb24uDQpQbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGlubGluZSBiZWxvdy4NCg0KLVFp bg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBMaW1lIFttYWlsdG86bGltZS1i b3VuY2VzQGlldGYub3JnXSDku6PooaggSmVmZnJleSBIYWFzDQrlj5HpgIHml7bpl7Q6IDIwMTXl ubQxMOaciDXml6UgMjI6MTYNCuaUtuS7tuS6ujogZ21haWzpgq7nrrENCuaKhOmAgTogbGltZUBp ZXRmLm9yZzsgRGVlcGFrIEt1bWFyIChkZWt1bWFyKQ0K5Li76aKYOiBSZTogW0xpbWVdIENGTSBz ZW1hbnRpY3MsIElQIGFuZCBNUExTIE9BTSAtIGhvdyB0byBwcm9jZWVkPw0KDQpRaW4sDQoNCk9u IFNhdCwgT2N0IDAzLCAyMDE1IGF0IDEyOjU0OjEzUE0gKzA4MDAsIGdtYWls6YKu566xIHdyb3Rl Og0KPiA+IEkgdGhpbmsgdGhhdCB0cnlpbmcgdG8gZm9yY2UgdGhlIHNlbWFudGljIG9mIE1ELUxl dmVsIGludG8gSVAgDQo+ID4gcHJvdG9jb2xzIHdpbGwgbGlrZWx5IGJlIGhpZ2hseSBwcm9ibGVt YXRpYyBmb3Igb3BlcmF0b3JzLg0KPiDvvLtRaW7vvL1NRCBsZXZlbCBwYXJhbWV0ZXJzIGRvbuKA mXQgbmVlZCB0byBiZSBpbXBvc2VkIHRvIElQIHByb3RvY29s77yMaXQgaXMgc2VudCBmcm9tIHRo ZSBtYW5hZ2UgcGxhbmUgYW5kIHRlcm1pbmF0ZWQgYXQgdGhlIHRlc3QgcG9pbnRz44CCQ2hhcnRl ciBjbGVhcmx5IHNhaWQgYmFzZSBtb2RlbCBNVVNUIE5PVCBjaGFuZ2UgSVAgcHJvdG9jb2wuDQoN ClBsZWFzZSBjb25zaWRlciB0aGF0IHRoZSBjdXJyZW50IHB1Ymxpc2hlZCB5YW5nIG1vZGVsIHNl ZW1zIHRvIHN1Z2dlc3QgdGhhdCBzdWNoIGNvbmNlcHRzIGFyZSBuZWVkZWQgYXQgdGhlIElQIGxl dmVsLiAgVGhpcyBpcyB3aHkgSSdtIGFza2luZyBmb3IgYSBkZW1vbnN0cmF0aW9uIG9mIGhvdyB0 aGUgbW9kZWwgaXMgaW50ZW5kZWQgdG8gYXBwbHkgdG8gSVAgYW5kIE1QTFMuDQoNCklmIHRoZSBp bnRlbnQgaXMgdG8gYWRkIHRvIHRoZSBwdWJsaXNoZWQgeWFuZyBtb2RlbCwgdGhhdCBoYXMgbm90 IGJlZW4gY2xlYXIgZnJvbSBteSByZWFkaW5nIG9mIHRoZSBtYWlsaW5nIGxpc3QgYXJjaGl2ZXMu DQoNCltRaW5dOiBJIGFtIGFmcmFpZCB5b3UgbWlzdW5kZXJzdGFuZCB3aGF0IEkgc2FpZCBhYm92 ZS4NCkkgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIGhhdmUgTUQgbGV2ZWwgcGFyYW1ldGVyIGluIHRo ZSBtb2RlbCBzdHJ1Y3R1cmUsIHNpbmNlIE1EIGxldmVsIHBhcmFtZXRlciBzdGFuZHMgZm9yIGZh dWx0IGxvY2F0aW9uIGluZm9ybWF0aW9uLCBoYXZpbmcgTUQgbGV2ZWwgcGFyYW1ldGVycyB0b2dl dGhlciBjYW4gaGVscCB1cyBiZXR0ZXIgYW5kIHF1aWNrbHkgbG9jYXRlIGZhdWx0IG9yIGxvY2Fs aXplIGZhdWx0IGluIHRoZSBzcGVjaWZpYyBkb21haW4uDQoNClRvIGFwcGx5IE1EIGxldmVsIHBh cmFtZXRlciB0byBJUCBhbmQgTVBMUywgdGhlIG1hbmFnZW1lbnQgc3lzdGVtIHdpbGwgc2V0IE1E IGxldmVsIHBhcmFtZXRlciBpbiB0aGUgYmFzZSBtb2RlbCBhbmQgc2VuZCBNRCBsZXZlbCBwYXJh bWV0ZXIgdG8gdGhlIHNvdXJjZSB0ZXN0IHBvaW50LCB0aGVyZWZvcmUgc291cmNlIHRlc3Rwb2lu dCBkb2Vzbid0IG5lZWQgdG8gc2V0IE1EIGxldmVsIHBhcmFtZXRlciBieSBpdHNlbGYsIHdoZW4g dGVzdHBvaW50IGdldCBmYXVsdCBvciB0ZXN0IHJlc3VsdHMgYnkgcnVubmluZyBPQU0gY29tbWFu ZChlLmcuLCBQaW5nLCB0cmFjZXJvdXRlKSwgdGhlc2UgdGVzdCByZXN1bHRzIHdpbGwgc2VuZCBi YWNrIHRvZ2V0aGVyIHdpdGggTUQgbGV2ZWwgcGFyYW1ldGVycyB0byB0aGUgbWFuYWdlbWVudCBz eXN0ZW0gdXNpbmcgYmFzZSBtb2RlbC4gVGhlcmVmb3JlIHRlc3QgcG9pbnQgbWF5IG5lZWQgdG8g a2VlcCBNRCBsZXZlbCBwYXJhbWV0ZXIgc2VudCBieSB0aGUgbWFuYWdlbWVudCBzeXN0ZW0gYmVm b3JlIGl0IGdldHMgdGVzdCByZXN1bHRzIGJhY2suIFRoZSBtYW5hZ2VtZW50IHN5c3RlbSBkb2Vz bid0IG5lZWQgdG8gbWFpbnRhaW4gTUQgbGV2ZWwgaW5mb3JtYXRpb24gaW4gdGhpcyBjYXNlLg0K DQpBbHRlcm5hdGl2ZWx5LCB0aGUgbWFuYWdlbWVudCBzeXN0ZW0gY2FuIG1haW50YWluIGFzc29j aWF0aW9uIGJldHdlZW4gTUQgbGV2ZWwgaW5mb3JtYXRpb24gYW5kIHRlc3QgcG9pbnQgaWRlbnRp dHksIGluIHRoaXMgY2FzZSwgdGhlIG1hbmFnZW1lbnQgc3lzdGVtIGRvZXNuJ3QgbmVlZCB0byBz ZW5kIE1EIGxldmVsIHBhcmFtZXRlcnMgdG8gdGhlIHNvdXJjZSB0ZXN0IHBvaW50LCB3aGVuIHRl c3Rwb2ludCBnZXQgZmF1bHQgb3IgdGVzdCByZXN1bHRzIGJhY2sgYW5kIHNlbmQgdGhlbSB0byB0 aGUgbWFuYWdlbWVudCBzeXN0ZW0sIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSBuZWVkcyB0byBsb29r IHVwIE1EIGxldmVsIHBhcmFtZXRlcnMgZnJvbSBkYXRhYmFzZSBiYXNlZCBvbiB0ZXN0cG9pbnQg aWRlbnRpdHkgYW5kIHJlcHJlc2VudCBNRCBwYXJhbWV0ZXJzIGFuZCB0ZXN0IHJlc3VsdHMgdXNp bmcgbW9kZWwgc3RydWN0dXJlIHByb3Bvc2VkIGluIHRoZSBiYXNlIG1vZGVsLg0KDQo+ID4gIENv bnNpZGVyIGNvb3JkaW5hdGlvbiBlZmZvcnRzDQo+ID4gdGhhdCB3b3VsZCBiZSByZXF1aXJlZCBp biBhbiBpbnRlci1kb21haW4gZmFzaGlvbi4NCj4gDQo+ID4g77y7UWlu77y9TElNRSBjaGFydGVy IHNhaWQgdGhlIHNjb3BlIGlzIHJlc3RyaWN0ZWQgdG8gc2luZ2xlIA0KPiA+IGFkbWluaXN0cmF0 aXZlIGRvbWFpbu+8jGRvIHdlIGludGVuZCB0byBjaGFuZ2UgdG8gdGFja2xlIGludGVy4oCUZG9t YWluIA0KPiA+IGNhc2XvvJ8NCg0KVGhhdCBpcyBvYnZpb3VzbHkgZm9yIHRoZSBjaGFpcnMgdG8g Y29tbWVudCB1cG9uLiAgR2l2ZW4gbXkgYmFja2dyb3VuZCBpbiBCR1AgYW5kIGhvdyB0aGlzIG1l Y2hhbmlzbSBpcyBsaWtlbHkgdG8gYmUgYXBwbGljYWJsZSBhdCBzb21lIHBvaW50LCBJIGhhdmUg dG8gYXNrIHRoZSBsb25nLXRlcm0gcXVlc3Rpb24sIGV2ZW4gaWYgdGhlIHNob3J0LXRlcm0gcHJv cG9zYWwgaXMgaW50ZW5kZWQgdG8gYmUgbW9yZSBjb25zdHJhaW5lZC4NCg0KPiDvvLtRaW7vvL1U aGUgZ29hbCBvZiBsaW1lIFdH77yMSSB0aGlua++8jCBpcyB0byBpZGVudGlmeSBjb21tb24gbW9k ZWwgDQo+IHN0cnVjdHVyZSBmb3IgdmFyaW91cyBPQU0gdGVjaCBhdCBkaWZmZXJlbnQgbGF5ZXIu IEp1c3QgbGlrZSANCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldG1vZC9kcmFmdC1pZXRm LW5ldG1vZC1yb3V0aW5nLWNmZy8gZGlkIHRvIA0KPiBwcm92aWRlIGNvbW1vbiBzdHJ1Y3QgZm9y IHZhcmlvdXMgcm91dGluZyB0ZWNoIGRvIHUgYWdncmVlIHdpdGggDQo+IHRoaXPvvJ9vciB1IGJl bGlldmUgd2Ugc2hvdWxkIGZpbmQgZGlmZmVyZW50IHN0cnVjdHVyZSBmb3Igb2FtIGF0IA0KPiBk aWZmZXJlbnQgbGF5ZXLvvJ8NCg0KSSBhZ3JlZSB0aGF0IHRoZXJlIHNob3VsZCBiZSBjb21tb24g bGF5ZXJzLiAgSSBiZWxpZXZlIHRoYXQgdGhlIFJQQ3MgdGhhdCBhcmUgY3VycmVudGx5IHNwZWNp ZmllZCBoYXZlIHNvbWUgcHJvbWlzZSB0byBhcHBseSBiZXR3ZWVuIHRoZSBsYXllcnMuICBJIGRv IG5vdCBzZWUgaG93IHRoZSBjdXJyZW50IHByb3Bvc2FsIGludGVuZHMgdG8gYmUgZ2VuZXJpYyB0 byBJUCBhbmQgTVBMUyBzaW5jZSBpdCBzZWVtcyB0byBiZSBDRk0tbW9kZWwgc3BlY2lmaWMuDQoN CltRaW5dOiBUbyBtb2RlbCBPQU0gZnJvbSBkaWZmZXJlbnQgT0FNIHByb3RvY29sIHBlcnNwZWN0 aXZlLCB5b3UgZW5kIHVwIHdpdGggbW9kZWxpbmcgT0FNIGluIGRpZmZlcmVudCB3YXkgc2luY2Ug d2UgdXNlIGVhY2ggT0FNIHByb3RvY29sIGFzIHJvb3Qgbm9kZSBpbiB0aGUgbW9kZWwgc3RydWN0 dXJlLg0KVG8gbW9kZWwgT0FNIGZyb20gZmF1bHQgbWFuYWdlbWVudCBwZXJzcGVjdGl2ZSBhbmQg cGVyZm9ybWFuY2UgbWFuYWdlbWVudCBwZXJzcGVjdGl2ZSwgeW91IGNhbiBtb2RlbCBPQU0gaW4g dGhlIHNhbWUgd2F5LCBzaW5jZSBmcm9tIHRoZXNlIHR3byBwZXJzcGVjdGl2ZXMsIHdlIHdpbGwg bm90IGNhcmUgYWJvdXQgd2hhdCBPQU0gdGVjaG5vbG9neSBpcyB1c2VkLCB3aGF0IE9BTSB0b29s IGlzIHVzZWQsIHdlIHdpbGwgb25seSBiZSBpbnRlcmVzdGVkIGluIHdoZXJlIHdlIGNhbiBsb2Nh dGUgdGhlIGZhdWx0KGNvcnJlc3BvbmRpbmcgdG8gTUQvTUEgbGV2ZWwgcGFyYW1ldGVyKSwgd2hl cmUgYXJlIHRoZXNlIHRlc3Rwb2ludHMgKE1FUC9NSVAgSWRlbnRpdHkpLCB3aGF0IGtpbmQgb2Yg Y29udGV4dCBpbmZvcm1hdGlvbiBpcyBhc3NvY2lhdGVkIHdpdGggdGVzdHBvaW50IChNRVAgbGV2 ZWwgcGFyYW1ldGVycyksIHdoYXQga2luZCBvZiBPQU0gY29tbWFuZCBkbyB3ZSBoYXZlKGNvcnJl c3BvbmRpbmcgdG8gdmFyaW91cyBycGNzKT8gd2Ugd2lsbCBjb3JyZWxhdGUgZmF1bHRzLCBkZWZl Y3RzIGFuZCBuZXR3b3JrIGZhaWx1cmUgaW5mb3JtYXRpb24gd2l0aCBmYXVsdCBsb2NhdGlvbiBp bmZvcm1hdGlvbiwgDQpDRk0gbGlrZSB0ZW1wbGF0ZSBkaWQgcHJvdmlkZSBzdWNoIGNvbmNlcHQu IFNvIHdoYXQgd2UgYXJlIGRvaW5nIGluIHRoZSBiYXNlIG1vZGVsIGlzIHRvIGFkb3B0IENGTSB0 ZW1wbGF0ZSBjb25jZXB0IGFuZCBtYWtlIGl0IGdlbmVyaWMgZW5vdWdoIHRvIGFwcGx5IHRvIGFs bCB0aGUgb3RoZXIgT0FNIHRlY2hub2xvZ3kNCkFuZCBleHRlbmQgaXQgdG8gdGVjaG5vbG9neSBp bmRlcGVuZGVudCBmcmFtZXdvcmsuIFBsZWFzZSBzZWUgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBz ZWN0aW9uIDQgaW4gZHJhZnQtdGlzc2EtbGltZS15YW5nLW9hbS1tb2RlbC0wNg0KIg0KICAgSW4g dGhpcyBkb2N1bWVudCB3ZSBhZG9wdCB0aGUgY29uY2VwdHMgb2YgdGhlIFtJRUVFODAyLjFRXSBD Rk0gbW9kZWwNCiAgIGFuZCBzdHJ1Y3R1cmUgaXQgc3VjaCB0aGF0IGl0IGNhbiBiZSBhZGFwdGVk IHRvIGRpZmZlcmVudA0KICAgdGVjaG5vbG9naWVzLg0KIg0KDQpJIHRoaW5rIElQIGFuZCBNUExT IGFsc28gbmVlZCB0byBjYXJlIGFib3V0IHdoZXJlIGFyZSB0aGVzZSB0ZXN0cG9pbnRzLCB3aGF0 IGtpbmQgb2YgY29udGV4dCBpbmZvcm1hdGlvbiBpcyBhc3NvY2lhdGVkIHdpdGggdGVzdHBvaW50 LCB3aGF0IGtpbmQgb2YgT0FNIGNvbW1hbmQgZG8gd2UgaGF2ZT8NCldoeSB5b3UgdGhpbmsgSVAg YW5kIE1QTFMgT0FNIGRvZXNuJ3QgZml0IGludG8gc3VjaCBmcmFtZXdvcmsuDQoNCj4gaWYgaXQg aXMgdGhlIGZvcm1lcu+8jGRvIHlvdSBoYXZlIGJldHRlciBzdHJ1Y3R1cmUgdGhhbiBDRk0gbGlr ZSBzdHJ1Y3TvvJ9Nb2RlbGluZyBvYW0gZnJvbSBwcm90b2NvbCBwZXJzcGVjdGl2ZSBpcyBub3Qg YWJsZSB0byBjb21lIHVwIHdpdGggY29tbW9uIG9hbSBzdHJ1Y3QuIE1vZGVsaW5nIG9hbSBmcm9t IGZhdWx0IG1hbmFuZ2UgYW5kIHBlcmZvcm0gbWFuYWdlbWVudCBwZXJzcGVjdGl2Ze+8jHUgcHJv Ym9iYWx5IGdldCBzaW1pbGFyIHN0cnVjdCBsaWtlIGNmbSBzdHJ1Y3QuDQo+IGlmIHUgaGF2ZSBi ZXR0ZXIgc3RydWN077yMd2UgYXJlIGhhcHB5IHRvIGhlYXLvvIENCg0KSSBkb24ndCBjdXJyZW50 bHkgaGF2ZSBhIGJldHRlciBwcm9wb3NhbCAtIG9ubHkgc3Ryb25nIGNvbmNlcm5zIGFib3V0IHRo ZSBpbXBhY3Qgb2YgdHJ5aW5nIHRvIGltcG9zZSBDRk0gbGlrZSBtZWNoYW5pc21zIG9uIElQIGFu ZCBNUExTLiANCg0KIEknbSBhbHNvIGRvaW5nIHRoaXMgYmVjYXVzZSBJIHRoaW5rIHRoZSBsaW1l IHdvcmsgaXMgdXNlZnVsIGFuZCB3b3VsZCByYXRoZXIgc2VlIGl0IHN1Y2NlZWQuDQoNCltRaW5d OiBUaGFua3MsIEkgdGhpbmsgdGhhdCdzIGFsc28gb3VyIGdvYWwuDQoNCj4gPiBNeSBzdWdnZXN0 aW9uIHdvdWxkIGJlIHRvIHdvcmsgZnJvbSB0aGlzIHNvcnQgb2YgdXNlIGNhc2UgaW4gdGhlIA0K PiA+IGZ1dHVyZSBtb2RlbGluZyB3b3JrIC0gIGFuZCBub3RlIHRoZSBjYXZlYXQgYWJvdXQgYXZv aWRpbmcgcmVxdWlyaW5nIA0KPiA+IElQL01QTFMgb3BlcmF0b3JzIHRvIGNvbmZpZ3VyZSBDRk0g YXR0cmlidXRlcyBhdCBldmVyeSBub2RlIQ0KPiA+IA0KPiDvvLtRaW7vvL1ldmVyeSBub2Rl77yf VGhpcyBpcyBub3Qgb3VyIHByb3Bvc2Fs44CCVGhlIG1hbmFnZSBwbGFuZSBjb3VsZCByZWx5IG9u IHBsYW4gaW5mbyBvciB0b3BvIGluZm8gYnVpbHQgZnJvbSBzb21ld2hlcmUgZWxzZSB0byBkZWNp ZGUgd2hpY2ggdGVzdHBvaW50cyBuZWVkIHRvIGNvbmZpZ3VyZe+8jGluIHNpbXBsZSBJUCBPQU0g Y2FzZe+8jG9ubHkgc3JjIGFuZCBkc3QgdGVzdHBvaW50cyBuZWVkIHRvIGJlIGNvbmZpZ3VyZS4N Cg0KSG93IHdvdWxkIHlvdSBrbm93IGFoZWFkIG9mIHRpbWUgd2hhdCBub2RlcyB3b3VsZCBuZWVk IHByb3Zpc2lvbmluZyBmb3IgQ0ZNIGF0dHJpYnV0ZXM/IA0KDQpbUWluXTogVGhlIG1hbmFnZW1l bnQgc3lzdGVtIHNob3VsZCBrbm93IHRoaXMsIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSB3aWxsIHJl Y2VpdmUgc2VydmljZSByZXF1ZXN0IGZyb20gdGhlIGN1c3RvbWVyIHdobyBjb21wbGFpbnMgYWJv dXQgbmV0d29yayBjaHVybi4NClRoZSBzZXJ2aWNlIHVzZXIgbWF5IHJlcG9ydCBjb2Fyc2UgbG9j YXRpb24gb3IgZG9uJ3QgcmVwb3J0IGFueSBsb2NhdGlvbiBpbmZvcm1hdGlvbiB0byB0aGUgbWFu YWdlbWVudCBzeXN0ZW0sIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSB3aWxsIGNob29zZSB0ZXN0IHBv aW50cyBhbmQgc2V0IGFzc29jaWF0ZWQgTUQgbGV2ZWwgcGFyYW1ldGVycyBiYXNlZCBvbiB0aGUg Y29hcnNlIGxvY2F0aW9uIGluZm9ybWF0aW9uIGdpdmVuIGJ5IGN1c3RvbWVyIG9yIHVzZXIgcHJv ZmlsZSBjb3JyZXNwb25kaW5nIHRvIHRoZSBjdXN0b21lciAodXNlciBwcm9maWxlIG1heSBpbmRp Y2F0ZSBjb2Fyc2UgbG9jYXRpb24gaW5mb3JtYXRpb24pLg0KIEFsdGVyaW5nIHBhcmFtZXRlcnMg ZHVyaW5nIHRyb3VibGVzaG9vdGluZyBpcyBub3QgaG93IG1vc3Qgb3BlcmF0b3JzIHdhbnQgdG8g cGxhbiB0aGVpciBuZXR3b3Jrcy4NCg0KW1Fpbl06IFlvdSBhcmUgcmlnaHQsIGJ1dCB0aGUgbWFu YWdlbWVudCBzeXN0ZW0gY2FuIHR1bmUgcGFyYW1ldGVyIGFuZCBwZXJmb3JtIGEgc2Vjb25kIHRy b3VibGVzaG9vdGluZyB3aGVuIGl0IGNvbXBsZXRlIHRoZSBmaXJzdCB0cm91Ymxlc2hvb3Rpbmcg aWYgdGhlIG1hbmFnZW1lbnQgd2FudCB0byBmdXJ0aGVyIGdldCBmaW5lIGdyYWluZWQgZmF1bHQg YW5kIGxvY2F0aW9uIGluZm9ybWF0aW9uLiBUaGlzIGlzIGFib3V0IHRyb3VibGVzaG9vdGluZyBh dXRvbWF0aW9uLg0KDQotLSBKZWZmDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpMaW1lIG1haWxpbmcgbGlzdA0KTGltZUBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saW1lDQo= From nobody Thu Oct 15 09:51:45 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4121A9085 for ; Thu, 15 Oct 2015 09:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 wWy5pRCf5mJK for ; Thu, 15 Oct 2015 09:51:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C867B1B2CD9 for ; Thu, 15 Oct 2015 09:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4034; q=dns/txt; s=iport; t=1444927902; x=1446137502; h=from:to:subject:date:message-id:mime-version; bh=UCRO11A1br6GJci3V1Spz+o2nNiaOipWoMFDBgzNARM=; b=c9if43w5ONbTb4ZdHmKdoQR2NosaIQ1HvQYY8SMkYwIqUBJn+d4C2P93 UHePdeorY/0QdOzAt/H0nqv7JHfEBmd+fNnOVyAaafkK3uInyPrC3MvAf /6Yvcr6m1hqO6R2VE8zAtI9y1ONj9FHHAIRUeQhJhB6RAdWFvf406wprC w=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C4AgDy2B9W/5FdJa1egyZUdLkWhCEOgVkhhXuBNzgUAQEBAQEBAX8LhC0dBmgBDAE9AjQnBCGIIA2gIo9xkzwBAQEBAQEEAQEBAQEBAQEBARQEhnaCEId3gnQxgRQFklaDRQGCTYFhaogCgViEOpV8AR8BQ4QDhVKBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,686,1437436800"; d="asc'?scan'208,217";a="37992138" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP; 15 Oct 2015 16:51:41 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t9FGpfuw030889 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Oct 2015 16:51:41 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 11:51:26 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 11:51:26 -0500 From: "Carlos Pignataro (cpignata)" To: "lime@ietf.org" Thread-Topic: IETF94 - LIME - Call for Presentations Thread-Index: AQHRB2m735LWhTNSa0uOzeUgjbyXog== Date: Thu, 15 Oct 2015 16:51:26 +0000 Message-ID: <0C77A9AD-6DE4-48CA-8E08-9149B80FF783@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.62] Content-Type: multipart/signed; boundary="Apple-Mail=_9558EB8C-3CCB-4707-834B-8C874DA13AFE"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [Lime] IETF94 - LIME - Call for Presentations X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:51:44 -0000 --Apple-Mail=_9558EB8C-3CCB-4707-834B-8C874DA13AFE Content-Type: multipart/alternative; boundary="Apple-Mail=_B89ADA2F-93BE-4B5B-B339-A57D52BE23FA" --Apple-Mail=_B89ADA2F-93BE-4B5B-B339-A57D52BE23FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, LIME, We are planning the agenda for the LIME meeting during IETF94. The main = topic for us as a working group during IETF94 is the Applicability of = the LIME model to various technologies. In addition to reaching out to authors of key relevant document for = presentation slots, we want to open up in the list a call for = presentations. If you are interested in presenting during the LIME meeting, please = reply with the topic, document, presenter, and requested duration. * Title: * Doc: * Presenter: * Duration: As we continue to organize the agenda, we will be keeping a copy at = https://tools.ietf.org/wg/lime/trac/wiki/ietf94-agenda = Thanks! =E2=80=94 Carlos & Ron. --Apple-Mail=_B89ADA2F-93BE-4B5B-B339-A57D52BE23FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, LIME,

We are planning the agenda for the LIME = meeting during IETF94. The main topic for us as a working group during = IETF94 is the Applicability of the LIME model to various = technologies.

In= addition to reaching out to authors of key relevant document for = presentation slots, we want to open up in the list a call for = presentations.

If you are interested in presenting during the LIME meeting, = please reply with the topic, document, presenter, and requested = duration.

* = Title: 
 * Doc: 
 * Presenter:
 * = Duration:

As = we continue to organize the agenda, we will be keeping a copy at https://tools.ietf.org/wg/lime/trac/wiki/ietf94-agenda = ;

Thanks!

=E2=80=94 Carlos & Ron.
= --Apple-Mail=_B89ADA2F-93BE-4B5B-B339-A57D52BE23FA-- --Apple-Mail=_9558EB8C-3CCB-4707-834B-8C874DA13AFE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWH9mcAAoJEIXgpQGOZny9N48P/jya5NSIJf/hVselEkKjFOAh T+hVc9E46NDt72JBPXa7exY9kXNoys5RlJvaJhYXhN8HUkwCDI8EacEZEhspa6vL dPHIayuUR+M7I0x7Igqld8IL54Zr6vGDGF1CVTVA2dGKa4CisF1yewjhNH0BQqxg oVX55WicDnlDvv1eqe2/1Oi0FHqmaA373VF7ybBSzandXkYkTWJTO3VzreIYY7FN +Ny6vFeX9IbWVbxPv6Omue1lixd19wywwWdTbCKN9qBVNamgi5ogOhciX9Wvw8aS 5bIqET7sgjfUCUMzTkOlHmt545VhCemJ1/evBwad7UbGXF+bZQg/Od/xM98KlTq3 9Dqy8diIvAmTvzpEBC5yD3AwLVoUFPv8MG5T51LP2RfTUEYMrXjl7kef/89PAu6F avji8RetEHdK9FhlZS80OAgJnDX/K3EdmS3MQgoZ8diJY6IOtRLUOQJ4WWgTTtR+ uwhnJK/qzUw7RAp/LOjO9bnN3N/d7vWEnGHZAbUKcTUekTa5ff0ZB6JOFlh490eP n5xt/GsYSWGPFYQLb2BWSfwU+o8yar1g9pxpPte2nq+oah3EgsN/zGzb2TbNIl8g trKSm0ep83QsPvBz9acVGjjmd2jVAXkaW1pW+fC14SyVGG2ZRIvtnRGsJKaMmecu Sd3FPLNrk142l7CSOwJ5 =/6iL -----END PGP SIGNATURE----- --Apple-Mail=_9558EB8C-3CCB-4707-834B-8C874DA13AFE-- From nobody Mon Oct 19 08:03:02 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AE01A930A for ; Mon, 19 Oct 2015 08:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Gd7f5JwZ5v3d for ; Mon, 19 Oct 2015 08:02:58 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E231ABC0F for ; Mon, 19 Oct 2015 08:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9702; q=dns/txt; s=iport; t=1445266978; x=1446476578; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IMu1Z/QpYJ3LLvc6U7tl/tSPqntGHBH3YlvkPWJZKWU=; b=BhvP0w/Xc8XGJNl0Xuvn/gZbKsttJzWXNYToAYqfRUGkE+5JXp0QAH2k Y2XLiTjsorXIWkSi/XVVp6Vg1ygdOd3QZErQgenXHL9Ac/ATo4LYeSnZU S3tfeia/nQfb93Ooa2gE1SVqxlZXFFjVsdaOCVJDa6P+bwqWJyxNlMPXF 8=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8AgBJBSVW/5hdJa1egzZUbwa+CQ6BWhcBCYV9AoE5OBQBAQEBAQEBgQqELQEBAQMBAQEBIEsLBQsCAQgOCioCAicLJQIEDgUOiBoIDQOwaJJbAQEBAQEBAQEBAQEBAQEBAQEBAQEBDwUEhneCEIJuhCoRAU0EB4JpMYEUBZJag0kBgk2BYWqIBIFYhDySFYNuAR8BQ4QDcoQnOoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,702,1437436800"; d="asc'?scan'208,217";a="42048581" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 19 Oct 2015 15:02:57 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9JF2vUw025192 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 15:02:57 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 10:02:39 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 10:02:39 -0500 From: "Carlos Pignataro (cpignata)" To: Jeffrey Haas Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AQHQ/FQrRXVaASWlC0m5mG3k63rioZ5YTBgAgABUyICAGrjGAA== Date: Mon, 19 Oct 2015 15:02:39 +0000 Message-ID: References: <20151001142302.GA10279@pfrc.org> <580BEA5E3B99744AB1F5BFF5E9A3C67D286BED0140@HE111648.emea1.cds.t-internal.com> <20151002155855.GI29696@pfrc.org> In-Reply-To: <20151002155855.GI29696@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.54.140] Content-Type: multipart/signed; boundary="Apple-Mail=_DCB15AFE-DD0B-4333-8BD3-0882F565CD86"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "Roland.Schott@telekom.de" , "lime@ietf.org" Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 15:03:00 -0000 --Apple-Mail=_DCB15AFE-DD0B-4333-8BD3-0882F565CD86 Content-Type: multipart/alternative; boundary="Apple-Mail=_BD475369-D987-4E55-8539-DAF30F0D5D33" --Apple-Mail=_BD475369-D987-4E55-8539-DAF30F0D5D33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Pigging backing on this email to share a couple of thoughts. Thanks Jeff for kicking it off! > On Oct 2, 2015, at 11:58 AM, Jeffrey Haas wrote: >=20 > Roland, >=20 > On Fri, Oct 02, 2015 at 12:55:28PM +0200, Roland.Schott@telekom.de = wrote: >> what is then your proposal for Lime: >>=20 >> Not focussing on CFM semantics? >> Is your concern related to different definitions in IETF resp. IEEE = etc. or general? >=20 > IETF OAM is very immature by comparison to IEEE/ITU. I'm fine with = using > semantics and perhaps terminology. >=20 > Much of my concern is that since this is a data modeling exercise that = we > don't try to force IP and MPLS technologies (not MPLS-TP) to fit into = the > same configuration model one would do for CFM. >=20 > To speak in a somewhat polite fashion, if you told most IP network = operators > that they would have to give every IP end-point CFM-style = configurations to > make LIME work, I think you'd find they were somewhat hostile to the = idea. > :-) >=20 > CFM is great for places that it is already used. With respect to = lower > level layers that are implemented on CFM-style systems, we want to use = them. > The proposed data model covers this case fairly well as a service = model. >=20 > The IP/MPLS end of things is not covered, IMO. If I'm missing = something > that the authors believes shows that it is covered, an example showing = an > intra-domain traceroute would be helpful. Inter-domain traceroute is = a > good example to show as well. >=20 I agree a single domain traceroute would be a good example to show. = Regarding inter-domain, I=E2=80=99d suggest let;s get intra-domain = agreed first, as per our charter: "The initial scope is restricted to a single administrative domain and = may be extended for inter-domain scenarios in future as and when a need = rises." Qin, you answered Jeff=E2=80=99s question in prose on this email: = https://mailarchive.ietf.org/arch/msg/lime/vViD6g8kfDvRur6Cgh8UfeCou58 = . Perhaps you and your co-authors could expand on that example and = describe it during IETF94? A quick demonstration of the model would = anchor this conversation into more specifics and probably drive it more = usefully. Showing how exactly it work. Thanks for that! >> Could you give an example of the reporting missmatch you are = concerned, please. >=20 > In path-discovery, grouping monitor-stats is used. This includes a = min, > average and max delay stat. This isn't something returned from many > traceroute IP implementations. Perhaps it should be, but it's a bit > different. This is useful. Are you aware of other potential mismatch reporting and = issues? Thanks! =E2=80=94 Carlos. >=20 > -- Jeff >=20 > _______________________________________________ > Lime mailing list > Lime@ietf.org > https://www.ietf.org/mailman/listinfo/lime --Apple-Mail=_BD475369-D987-4E55-8539-DAF30F0D5D33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Pigging backing on this email to share a couple of = thoughts.

Thanks = Jeff for kicking it off! 

On = Oct 2, 2015, at 11:58 AM, Jeffrey Haas <jhaas@pfrc.org> = wrote:

Roland,

On Fri, Oct 02, 2015 at = 12:55:28PM +0200, Roland.Schott@telekom.de wrote:
what is then your proposal for Lime:

Not focussing on CFM semantics?
Is= your concern related to different definitions in IETF resp. IEEE etc. = or general?

IETF OAM is very = immature by comparison to IEEE/ITU.  I'm fine with using
semantics and perhaps terminology.

Much of my concern is that since this is a data modeling = exercise that we
don't try to force IP and MPLS = technologies (not MPLS-TP) to fit into the
same = configuration model one would do for CFM.

To = speak in a somewhat polite fashion, if you told most IP network = operators
that they would have to give every IP end-point = CFM-style configurations to
make LIME work, I think you'd = find they were somewhat hostile to the idea.
:-)

CFM is great for places that it is already = used.  With respect to lower
level layers that are = implemented on CFM-style systems, we want to use them.
The = proposed data model covers this case fairly well as a service model.

The IP/MPLS end of things is not covered, IMO. =  If I'm missing something
that the authors believes = shows that it is covered, an example showing an
intra-domain= traceroute would be helpful.  Inter-domain traceroute is a
good example to show as well.


I = agree a single domain traceroute would be a good example to show. = Regarding inter-domain, I=E2=80=99d suggest let;s get intra-domain = agreed first, as per our charter:

"The initial scope is = restricted to a single administrative domain and may be extended for inter-domain scenarios in future as and when a need rises."

Qin, = you answered Jeff=E2=80=99s question in prose on this email: https://mailarchive.ietf.org/arch/msg/lime/vViD6g8kfDvRur6Cgh8U= feCou58. 

Perhaps you and = your co-authors could expand on that example and describe it during = IETF94? A quick demonstration of the model would anchor this = conversation into more specifics and probably drive it more usefully. = Showing how exactly it work. Thanks for that!

Could you give an = example of the reporting missmatch you are concerned, please.

In path-discovery, grouping = monitor-stats is used.  This includes a min,
average = and max delay stat.  This isn't something returned from many
traceroute IP implementations.  Perhaps it should be, = but it's a bit
different.

This = is useful. Are you aware of other potential mismatch reporting and = issues?

Thanks!

=E2=80=94 Carlos.


--= Jeff

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

= --Apple-Mail=_BD475369-D987-4E55-8539-DAF30F0D5D33-- --Apple-Mail=_DCB15AFE-DD0B-4333-8BD3-0882F565CD86 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWJQYkAAoJEIXgpQGOZny97AAQAIj/r3erQ1aEKWDKs2nLFYbv KmFiTIRZlOvwd0zVeBp53IlynJMYIcM7eqmoLKMbIVdLBqOuUzlhcpeMvUruKWo3 dGUwx6Bj69Bs2kK9AlDNzrxL4zuPY4gEKghyaey/qY39TrrpYhEJse/G41j8L/4D qaPJu3jtDYEQEbKkUgtWiPtmpgKss9cRVX4KXB519K/B0bhPB4tvbrfaGv6DmuXM TNE+o+wtuOPgtkrY6ehYzkhIBdikg7Bu23u5QPy73s+UEolnnM65mstqtxvRHvCZ ZvZnYcsTW/KCuLr8Xh8wt0NxDVl3mamrFGEa1gAAu3JrnSjewLy+vIAwjePsubns D/NcQSN+AoAyvnzozscG7wsifveXBD0JaYVdvdfm8q/lKWHvJHseFYWN9nD9uvyC 0Ddb1WkPN9GaVbH1ii+8V6rOziUCVdLDDOjmhh7YaJL2oSz9xt+QKJvN+Oh4hVtN IrtVCM7DbwgCaSQTdZs+Jms5N7dQL+Y/iwx2trpI30BCctgVYZJa+NM635OEFpf7 +hRPkVp0OB+9oMheX0H44rjF5SD01PpMZWjOHSbeMRpUFdr5jJLMjEXFea2M22qv Qcs/1dJ1THWcrFWHUrs8yVbDwZLmPwmEfG7nBF3fpFiZuRZ9s8tRiT+0nNErg5CA K9gdrhZux/XN9/LmzOgY =SDMh -----END PGP SIGNATURE----- --Apple-Mail=_DCB15AFE-DD0B-4333-8BD3-0882F565CD86-- From nobody Mon Oct 19 13:49:46 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A9D1ACDAA for ; Mon, 19 Oct 2015 13:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 fix_1s0Fgh8o for ; Mon, 19 Oct 2015 13:49:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7471ACDAE for ; Mon, 19 Oct 2015 13:49:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 446661E4E7; Mon, 19 Oct 2015 16:53:39 -0400 (EDT) Date: Mon, 19 Oct 2015 16:53:39 -0400 From: Jeffrey Haas To: "Carlos Pignataro (cpignata)" Message-ID: <20151019205339.GN15569@pfrc.org> References: <20151001142302.GA10279@pfrc.org> <580BEA5E3B99744AB1F5BFF5E9A3C67D286BED0140@HE111648.emea1.cds.t-internal.com> <20151002155855.GI29696@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Roland.Schott@telekom.de" , "lime@ietf.org" Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:49:25 -0000 Carlos, Thanks for drawing my attention back to this mail. My apologies to Qin for not responding earlier. On Mon, Oct 19, 2015 at 03:02:39PM +0000, Carlos Pignataro (cpignata) wrote: > I agree a single domain traceroute would be a good example to show. Regarding inter-domain, I’d suggest let;s get intra-domain agreed first, as per our charter: > "The initial scope is restricted to a single administrative domain and may be extended for inter-domain scenarios in future as and when a need rises." > > Qin, you answered Jeff’s question in prose on this email: https://mailarchive.ietf.org/arch/msg/lime/vViD6g8kfDvRur6Cgh8UfeCou58 . > > Perhaps you and your co-authors could expand on that example and describe it during IETF94? A quick demonstration of the model would anchor this conversation into more specifics and probably drive it more usefully. Showing how exactly it work. Thanks for that! I would find such a presentation very useful. Qin's mail seemed to convey that in the context of IP technologies, the fields in the yang model are simply "keys of convenience" - they do not correspond to underlying OAM technologies. While this seemed to be the likely idea, in some cases they will correspond to real OAM keys (e.g. MD for IEEE technologies) and in others, are just keys of convenience. An example will show how these two world-views relate to each other, and provide discussion points for considerations of keeping the namespaces for such keys potentially disjoint. > >> Could you give an example of the reporting missmatch you are concerned, please. > > > > In path-discovery, grouping monitor-stats is used. This includes a min, > > average and max delay stat. This isn't something returned from many > > traceroute IP implementations. Perhaps it should be, but it's a bit > > different. > > This is useful. Are you aware of other potential mismatch reporting and issues? I didn't do such a thorough audit, but I would suggest such an audit happen as part of taking this work forward. Right now I'm concerned with the higher level issues. :-) -- Jeff From nobody Mon Oct 19 20:42:31 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8179B1A00CD for ; Mon, 19 Oct 2015 20:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Rz9ekMvp74bL for ; Mon, 19 Oct 2015 20:42:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE2A1A00CA for ; Mon, 19 Oct 2015 20:42:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCT56909; Tue, 20 Oct 2015 03:42:24 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 20 Oct 2015 04:42:23 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0235.001; Tue, 20 Oct 2015 11:42:17 +0800 From: Qin Wu To: Jeffrey Haas , "Carlos Pignataro (cpignata)" Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AQHQ/FRZBcBgaxq3CEyPhhOApdTEkp5Xgu0AgABUyICAGqfqgIAAYhGAgADsEjA= Date: Tue, 20 Oct 2015 03:42:17 +0000 Message-ID: References: <20151001142302.GA10279@pfrc.org> <580BEA5E3B99744AB1F5BFF5E9A3C67D286BED0140@HE111648.emea1.cds.t-internal.com> <20151002155855.GI29696@pfrc.org> <20151019205339.GN15569@pfrc.org> In-Reply-To: <20151019205339.GN15569@pfrc.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.178] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Roland.Schott@telekom.de" , "lime@ietf.org" Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 03:42:30 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBMaW1lIFttYWlsdG86bGltZS1ib3Vu Y2VzQGlldGYub3JnXSDku6PooaggSmVmZnJleSBIYWFzDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQx MOaciDIw5pelIDQ6NTQNCuaUtuS7tuS6ujogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQrm ioTpgIE6IFJvbGFuZC5TY2hvdHRAdGVsZWtvbS5kZTsgbGltZUBpZXRmLm9yZw0K5Li76aKYOiBS ZTogW0xpbWVdIENGTSBzZW1hbnRpY3MsIElQIGFuZCBNUExTIE9BTSAtIGhvdyB0byBwcm9jZWVk Pw0KDQpDYXJsb3MsDQoNClRoYW5rcyBmb3IgZHJhd2luZyBteSBhdHRlbnRpb24gYmFjayB0byB0 aGlzIG1haWwuICBNeSBhcG9sb2dpZXMgdG8gUWluIGZvciBub3QgcmVzcG9uZGluZyBlYXJsaWVy Lg0KDQpPbiBNb24sIE9jdCAxOSwgMjAxNSBhdCAwMzowMjozOVBNICswMDAwLCBDYXJsb3MgUGln bmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQo+IEkgYWdyZWUgYSBzaW5nbGUgZG9tYWluIHRyYWNl cm91dGUgd291bGQgYmUgYSBnb29kIGV4YW1wbGUgdG8gc2hvdy4gUmVnYXJkaW5nIGludGVyLWRv bWFpbiwgSeKAmWQgc3VnZ2VzdCBsZXQ7cyBnZXQgaW50cmEtZG9tYWluIGFncmVlZCBmaXJzdCwg YXMgcGVyIG91ciBjaGFydGVyOg0KPiAiVGhlIGluaXRpYWwgc2NvcGUgaXMgcmVzdHJpY3RlZCB0 byBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4gYW5kIG1heSBiZSBleHRlbmRlZCBmb3Ig aW50ZXItZG9tYWluIHNjZW5hcmlvcyBpbiBmdXR1cmUgYXMgYW5kIHdoZW4gYSBuZWVkIHJpc2Vz LiINCj4gDQo+IFFpbiwgeW91IGFuc3dlcmVkIEplZmbigJlzIHF1ZXN0aW9uIGluIHByb3NlIG9u IHRoaXMgZW1haWw6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbGltZS92 VmlENmc4a2ZEdlJ1cjZDZ2g4VWZlQ291NTggPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvbGltZS92VmlENmc4a2ZEdlJ1cjZDZ2g4VWZlQ291NTg+Lg0KPiANCj4gUGVyaGFw cyB5b3UgYW5kIHlvdXIgY28tYXV0aG9ycyBjb3VsZCBleHBhbmQgb24gdGhhdCBleGFtcGxlIGFu ZCBkZXNjcmliZSBpdCBkdXJpbmcgSUVURjk0PyBBIHF1aWNrIGRlbW9uc3RyYXRpb24gb2YgdGhl IG1vZGVsIHdvdWxkIGFuY2hvciB0aGlzIGNvbnZlcnNhdGlvbiBpbnRvIG1vcmUgc3BlY2lmaWNz IGFuZCBwcm9iYWJseSBkcml2ZSBpdCBtb3JlIHVzZWZ1bGx5LiBTaG93aW5nIGhvdyBleGFjdGx5 IGl0IHdvcmsuIFRoYW5rcyBmb3IgdGhhdCENCg0KSSB3b3VsZCBmaW5kIHN1Y2ggYSBwcmVzZW50 YXRpb24gdmVyeSB1c2VmdWwuDQoNClFpbidzIG1haWwgc2VlbWVkIHRvIGNvbnZleSB0aGF0IGlu IHRoZSBjb250ZXh0IG9mIElQIHRlY2hub2xvZ2llcywgdGhlIGZpZWxkcyBpbiB0aGUgeWFuZyBt b2RlbCBhcmUgc2ltcGx5ICJrZXlzIG9mIGNvbnZlbmllbmNlIiAtIHRoZXkgZG8gbm90IGNvcnJl c3BvbmQgdG8gdW5kZXJseWluZyBPQU0gdGVjaG5vbG9naWVzLiAgDQoNCltRaW5dOiBKdXN0IHRv IGNsYXJpZnksIEkgYW0gbm90IGluZGljYXRpbmcgdGhhdC4gSWYgd2UgcHV0IGFsbCBPQU0gdGVj aG5vbG9naWVzIHVuZGVyIG9ubHkgb25lIHVtYnJlbGxhLCBJIHRoaW5rIHRoZSBmaWVsZHMgaW4g dGhlIFlBTkcgbW9kZWwsIGVzcGVjaWFsbHkgbGlzdCBrZXksIHNob3VsZCBjb3JyZXNwb25kIHRv IHRoZSB1bmRlcmx5aW5nIHRlY2hub2xvZ2llcy4NCg0KV2hpbGUgdGhpcyBzZWVtZWQgdG8gYmUg dGhlIGxpa2VseSBpZGVhLCBpbiBzb21lIGNhc2VzIHRoZXkgd2lsbCBjb3JyZXNwb25kIHRvIHJl YWwgT0FNIGtleXMgKGUuZy4gTUQgZm9yIElFRUUgdGVjaG5vbG9naWVzKSBhbmQgaW4gb3RoZXJz LCBhcmUganVzdCBrZXlzIG9mIGNvbnZlbmllbmNlLiAgQW4gZXhhbXBsZSB3aWxsIHNob3cgaG93 IHRoZXNlIHR3byB3b3JsZC12aWV3cyByZWxhdGUgdG8gZWFjaCBvdGhlciwgYW5kIHByb3ZpZGUg ZGlzY3Vzc2lvbiBwb2ludHMgZm9yIGNvbnNpZGVyYXRpb25zIG9mIGtlZXBpbmcgdGhlIG5hbWVz cGFjZXMgZm9yIHN1Y2gga2V5cyBwb3RlbnRpYWxseSBkaXNqb2ludC4NCg0KW1Fpbl06IE1EIHNo b3VsZCBoYXZlIG1lYW5pbmcgZm9yIGFsbCB0aGUgY2FzZXMsIGluIEJGRCBjYXNlLCBpdCBjb3Jy ZXNwb25kcyB0byBhcmVhLWlkLg0KSWYgQkZEIGFuZCBMSU1FIG1vZGVsIGhhdmUgdHdvIGRpZmZl cmVudCBtb2RlbCBzdHJ1Y3R1cmVzLCBNYXBwaW5nIGJldHdlZW4gdHdvIGhldGVyb2dlbmVvdXMg bW9kZWwgc3RydWN0dXJlIGJlY29tZSBhIGNoYWxsZW5naW5nIGpvYi4gSW4gbXkgb3Bpbmlvbiwg d2Ugc2hvdWxkIG5vdCB0YWtlIHRoaXMgd2F5Lg0KDQpIb3dldmVyIGlmIHdlIHRha2UgTElNRSBh cyBhcHBsaWNhdGlvbiBvZiBCRkQsIHRoZW4gYm90aCBCRkQgYW5kIExJTUUgY2FuIGJlIGRldmVs b3BlZCBhcyBiYXNlIG1vZGVscywNCkFzIGEgY2xpZW50IG9mIEJGRCwgdGhlIExJTUUgYmFzZSBt b2RlbCB1c2VzIHRoZSBzZXJ2aWNlcyBwcm92aWRlZCBieSBCRkQgb3IgZ3JvdXBpbmcgZGVmaW5l ZCBpbiBCRkQgbW9kZWwoaS5lLiwgQkZEIGNhbiBrZWVwIGl0cyBvd24gbW9kZWwgc3RydWN0dXJl KS4gVGhlIExJTUUgQkZEIFlBTkcgbW9kZWwgYXVnbWVudHMgdGhlIGJhc2UgTElNRSBtb2R1bGUg dG8gc3VwcG9ydCBCRkQgYW5kIHByb3ZpZGUgY29uc2lzdGVudCByZXBvcnRpbmcgLGNvbmZpZ3Vy YXRpb24gYW5kIHJlcHJlc2VudGF0aW9uIGFuZCBpcyBkZWZpbmVkDQphcyBhIHNlcGFyYXRlIG1v ZHVsZS4gDQpJbiB0aGlzIHdheSwgd2UgY2FuIGhhdmUgY29tbW9uIExJTUUgbW9kZWwgc3RydWN0 dXJlIGZvciBhbGwgdGhlIE9BTSB0ZWNobm9sb2dpZXMsIEkgdGhpbmsgdGVjaG5vbG9naWVzIHNw ZWNpZmljIG1vZGVsIHNob3VsZCBzaGFyZSB0aGUgc2FtZSBuYW1lc3BhY2UgYXMgdGhlIGJhc2Ug bW9kZWwsIHRoZSBuYW1lc3BhY2VzIHNob3VsZCBub3QgYmUgZGlzam9pbnRlZC4gDQoNCkhlcmUg aXMgdGhlIGV4YW1wbGUgb24gaG93IHR3byB3b3JkLXZpZXdzIGFyZSByZWxhdGVkIHRvIGVhY2gg b3RoZXIuDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXdhbmcteWFuZy1iZmQtb2Ft LTA0LnR4dA0KDQpBbHNvIHlvdSBjYW4gc2VlIHRoZSBzaW1pbGFyIGV4YW1wbGUgaW4gdGhlIHNl Y3Rpb24gNCBvZiBkcmFmdC1pZXRmLW9zcGYteWFuZy0wMy4NCg0KPiA+PiBDb3VsZCB5b3UgZ2l2 ZSBhbiBleGFtcGxlIG9mIHRoZSByZXBvcnRpbmcgbWlzc21hdGNoIHlvdSBhcmUgY29uY2VybmVk LCBwbGVhc2UuDQo+ID4gDQo+ID4gSW4gcGF0aC1kaXNjb3ZlcnksIGdyb3VwaW5nIG1vbml0b3It c3RhdHMgaXMgdXNlZC4gIFRoaXMgaW5jbHVkZXMgYSANCj4gPiBtaW4sIGF2ZXJhZ2UgYW5kIG1h eCBkZWxheSBzdGF0LiAgVGhpcyBpc24ndCBzb21ldGhpbmcgcmV0dXJuZWQgZnJvbSANCj4gPiBt YW55IHRyYWNlcm91dGUgSVAgaW1wbGVtZW50YXRpb25zLiAgUGVyaGFwcyBpdCBzaG91bGQgYmUs IGJ1dCBpdCdzIA0KPiA+IGEgYml0IGRpZmZlcmVudC4NCj4gDQo+IFRoaXMgaXMgdXNlZnVsLiBB cmUgeW91IGF3YXJlIG9mIG90aGVyIHBvdGVudGlhbCBtaXNtYXRjaCByZXBvcnRpbmcgYW5kIGlz c3Vlcz8NCg0KSSBkaWRuJ3QgZG8gc3VjaCBhIHRob3JvdWdoIGF1ZGl0LCBidXQgSSB3b3VsZCBz dWdnZXN0IHN1Y2ggYW4gYXVkaXQgaGFwcGVuIGFzIHBhcnQgb2YgdGFraW5nIHRoaXMgd29yayBm b3J3YXJkLiAgUmlnaHQgbm93IEknbSBjb25jZXJuZWQgd2l0aCB0aGUgaGlnaGVyIGxldmVsIGlz c3Vlcy4gOi0pDQoNCi0tIEplZmYNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkxpbWUgbWFpbGluZyBsaXN0DQpMaW1lQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbWUNCg== From nobody Tue Oct 20 06:04:12 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107631A0064 for ; Tue, 20 Oct 2015 06:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 6i04fpjlWkqn for ; Tue, 20 Oct 2015 06:04:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA7D1A036C for ; Tue, 20 Oct 2015 06:04:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 541661E4E9; Tue, 20 Oct 2015 09:08:21 -0400 (EDT) Date: Tue, 20 Oct 2015 09:08:21 -0400 From: Jeffrey Haas To: Qin Wu Message-ID: <20151020130821.GB12629@pfrc.org> References: <20151001142302.GA10279@pfrc.org> <580BEA5E3B99744AB1F5BFF5E9A3C67D286BED0140@HE111648.emea1.cds.t-internal.com> <20151002155855.GI29696@pfrc.org> <20151019205339.GN15569@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "lime@ietf.org" , "Roland.Schott@telekom.de" Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 13:04:12 -0000 Qin, On Tue, Oct 20, 2015 at 03:42:17AM +0000, Qin Wu wrote: > Qin's mail seemed to convey that in the context of IP technologies, the fields in the yang model are simply "keys of convenience" - they do not correspond to underlying OAM technologies. > > [Qin]: Just to clarify, I am not indicating that. If we put all OAM technologies under only one umbrella, I think the fields in the YANG model, especially list key, should correspond to the underlying technologies. > > While this seemed to be the likely idea, in some cases they will correspond to real OAM keys (e.g. MD for IEEE technologies) and in others, are just keys of convenience. An example will show how these two world-views relate to each other, and provide discussion points for considerations of keeping the namespaces for such keys potentially disjoint. > > [Qin]: MD should have meaning for all the cases, in BFD case, it corresponds to area-id. There is no such thing as an area-id in the context of BFD. Did you mean something else? > If BFD and LIME model have two different model structures, Mapping between two heterogeneous model structure become a challenging job. In my opinion, we should not take this way. I agree that the mapping is challenging. At the moment, I find a homogenous use to be unclear and need the clarification examples to continue commenting. It's also important to note that I'm not really asking after BFD, although that's a long term goal. A simple ping or traceroute example is a good start. > > However if we take LIME as application of BFD, then both BFD and LIME can be developed as base models, > As a client of BFD, the LIME base model uses the services provided by BFD or grouping defined in BFD model(i.e., BFD can keep its own model structure). The LIME BFD YANG model augments the base LIME module to support BFD and provide consistent reporting ,configuration and representation and is defined > as a separate module. > In this way, we can have common LIME model structure for all the OAM technologies, I think technologies specific model should share the same namespace as the base model, the namespaces should not be disjointed. > > Here is the example on how two word-views are related to each other. > https://tools.ietf.org/id/draft-wang-yang-bfd-oam-04.txt Thanks for the -04 update. I see that the authors have now moved to using the BFD defined groupings for the model. This addresses one of my (and the BFD yang authors') big concerns. -- Jeff From nobody Tue Oct 20 13:53:01 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AE71B2C21 for ; Tue, 20 Oct 2015 13:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 tg0TXZcmUSv4 for ; Tue, 20 Oct 2015 13:52:59 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505BD1B2BF7 for ; Tue, 20 Oct 2015 13:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2677; q=dns/txt; s=iport; t=1445374030; x=1446583630; h=from:to:subject:date:message-id:mime-version; bh=GXuDOK8HGm75SJKwZocJELBglx0dcIg4NPmMaHcSZn8=; b=ikQs8yWACR14Uja//aWgPgmk62iqlTSJqql7xzxAxyg9cu80y32hvQgH amcOK6d9F1jJI4eabE+FdICEZX4QFH673YEc+KucxhiB2ZJywLL94fVly jzrG6b/veiYpQlTL93aot1aInBGGZbRH1aeRlSfWbD39TKZhBUnbWRNWk I=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C0AgAbpyZW/5pdJa1dgzZUdbl/hCEOgVohhX2BQzgUAQEBAQEBAX8LhCQQgQsBCwF0JwQhiCINoGijEQEBAQEBAQQBAQEBAQEBAQEBEAUEhneCEId3gyWBFAWSWoNKAYJNgWGIcIFYhD+HM45WAR8BQ4QDhVOBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,708,1437436800"; d="asc'?scan'208,217";a="199423929" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 20 Oct 2015 20:47:09 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t9KKl8vj026443 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 20 Oct 2015 20:47:08 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 20 Oct 2015 15:46:49 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Tue, 20 Oct 2015 15:46:49 -0500 From: "Carlos Pignataro (cpignata)" To: "lime@ietf.org" Thread-Topic: LIME Agenda 1.0 Thread-Index: AQHRC3hx2Z5+FaW/G0u3jbrs7bHg4w== Date: Tue, 20 Oct 2015 20:46:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.56] Content-Type: multipart/signed; boundary="Apple-Mail=_60452098-DF7D-450E-A5AD-AD7B39B926E5"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [Lime] LIME Agenda 1.0 X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 20:53:00 -0000 --Apple-Mail=_60452098-DF7D-450E-A5AD-AD7B39B926E5 Content-Type: multipart/alternative; boundary="Apple-Mail=_9B14D3DF-35C6-41F4-AEFD-E4BB80538491" --Apple-Mail=_9B14D3DF-35C6-41F4-AEFD-E4BB80538491 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, We published the first version of our agenda for IETF 94. You can find = it at https://www.ietf.org/proceedings/94/agenda/agenda-94-lime = Please review and comment. Thanks! Carlos & Ron, LIME co-chairs. --Apple-Mail=_9B14D3DF-35C6-41F4-AEFD-E4BB80538491 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi,

We published the first version of our agenda for IETF 94. You can find it at https://www.ietf.org/proceedings/94/agenda/agenda-94-lime

Please review and comment.

Thanks!

Carlos & Ron, LIME co-chairs.
--Apple-Mail=_9B14D3DF-35C6-41F4-AEFD-E4BB80538491-- --Apple-Mail=_60452098-DF7D-450E-A5AD-AD7B39B926E5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWJqhLAAoJEIXgpQGOZny9fbYP/1pRB6TnhM5fXqg6bri5wm9K q+XRZqVdR4UK3XO4cEI1kx6gsAOLd2mkORtQrMkarkoECry4BR5yJTcOJrjmpSXz CfmhLtfNSdk6mEtkM5347LIl5UqnN7ViCO/VNdXILO1BId5jVZq2XGA5DI5Vyylh bJaq2ONPd8Ct25owLSKBZgCR902ldrlx1sjksHqIo+Z7bekZ39EzLIad+nm0FCpY IEDBUNUuIaI3QEwheYjB3Ivac+6DxuHR2RO8Bj6mQpni5aGN7arVDDLkk7vVbVAw koO9eiJ0kPkQTLk53Y51ZNn0t96KFOtExgQRX3bUxd+DaSyHlwK9/vEo6pxFP6FJ J162xQ9YiymHeEFHeNhdzL/E8Q8ohvfTRmxlrHKfeO5vbg++QBHKtiE+mkh/DWfz EEG75r2X95Dw8BaXvtTRXoX1BkS1eGnode9ZSvHbhLTmiSBizG4YACBpan9AuPJE Lg/Dh7vhDU2OcF0ROS2SsBPl9t6P/bsK9toEvszxJDo7hTdqhnWf56l2EpdiP6NB U9JGQtGpBFHfdxj/litZN+tsHVLeeNRFmovbDb+C+pvPshBnpC6A+X0ut76Ns/ug AKjWim117KMjrSaYGWCDQJxFr5iv/EpcPE3lEGoxSzLb3lb8MPBehcFsYk58CPJF ka/QqQQCT3Fw4orEgNVq =LnQP -----END PGP SIGNATURE----- --Apple-Mail=_60452098-DF7D-450E-A5AD-AD7B39B926E5-- From nobody Tue Oct 20 19:35:00 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDCD1B2D3A for ; Tue, 20 Oct 2015 19:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YVGHKNg8qLIR for ; Tue, 20 Oct 2015 19:34:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEEC1B2D34 for ; Tue, 20 Oct 2015 19:34:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZB27159; Wed, 21 Oct 2015 02:34:53 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 21 Oct 2015 03:34:51 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Wed, 21 Oct 2015 10:34:44 +0800 From: Qin Wu To: Jeffrey Haas Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AQHQ/FRZBcBgaxq3CEyPhhOApdTEkp5Xgu0AgABUyICAGqfqgIAAYhGAgADsEjCAACRCgIABVWQA Date: Wed, 21 Oct 2015 02:34:43 +0000 Message-ID: References: <20151001142302.GA10279@pfrc.org> <580BEA5E3B99744AB1F5BFF5E9A3C67D286BED0140@HE111648.emea1.cds.t-internal.com> <20151002155855.GI29696@pfrc.org> <20151019205339.GN15569@pfrc.org> <20151020130821.GB12629@pfrc.org> In-Reply-To: <20151020130821.GB12629@pfrc.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.178] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "lime@ietf.org" , "Roland.Schott@telekom.de" Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 02:34:58 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IEplZmZyZXkgSGFhcyBbbWFpbHRvOmpoYWFzQHBm cmMub3JnXSANCreiy83KsbzkOiAyMDE1xOoxMNTCMjDI1SAyMTowOA0KytW8/sjLOiBRaW4gV3UN CrOty806IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTsgUm9sYW5kLlNjaG90dEB0ZWxla29t LmRlOyBsaW1lQGlldGYub3JnDQrW98ziOiBSZTogW0xpbWVdIENGTSBzZW1hbnRpY3MsIElQIGFu ZCBNUExTIE9BTSAtIGhvdyB0byBwcm9jZWVkPw0KDQpRaW4sDQoNCk9uIFR1ZSwgT2N0IDIwLCAy MDE1IGF0IDAzOjQyOjE3QU0gKzAwMDAsIFFpbiBXdSB3cm90ZToNCj4gUWluJ3MgbWFpbCBzZWVt ZWQgdG8gY29udmV5IHRoYXQgaW4gdGhlIGNvbnRleHQgb2YgSVAgdGVjaG5vbG9naWVzLCB0aGUg ZmllbGRzIGluIHRoZSB5YW5nIG1vZGVsIGFyZSBzaW1wbHkgImtleXMgb2YgY29udmVuaWVuY2Ui IC0gdGhleSBkbyBub3QgY29ycmVzcG9uZCB0byB1bmRlcmx5aW5nIE9BTSB0ZWNobm9sb2dpZXMu ICANCj4gDQo+IFtRaW5dOiBKdXN0IHRvIGNsYXJpZnksIEkgYW0gbm90IGluZGljYXRpbmcgdGhh dC4gSWYgd2UgcHV0IGFsbCBPQU0gdGVjaG5vbG9naWVzIHVuZGVyIG9ubHkgb25lIHVtYnJlbGxh LCBJIHRoaW5rIHRoZSBmaWVsZHMgaW4gdGhlIFlBTkcgbW9kZWwsIGVzcGVjaWFsbHkgbGlzdCBr ZXksIHNob3VsZCBjb3JyZXNwb25kIHRvIHRoZSB1bmRlcmx5aW5nIHRlY2hub2xvZ2llcy4NCj4g DQo+IFdoaWxlIHRoaXMgc2VlbWVkIHRvIGJlIHRoZSBsaWtlbHkgaWRlYSwgaW4gc29tZSBjYXNl cyB0aGV5IHdpbGwgY29ycmVzcG9uZCB0byByZWFsIE9BTSBrZXlzIChlLmcuIE1EIGZvciBJRUVF IHRlY2hub2xvZ2llcykgYW5kIGluIG90aGVycywgYXJlIGp1c3Qga2V5cyBvZiBjb252ZW5pZW5j ZS4gIEFuIGV4YW1wbGUgd2lsbCBzaG93IGhvdyB0aGVzZSB0d28gd29ybGQtdmlld3MgcmVsYXRl IHRvIGVhY2ggb3RoZXIsIGFuZCBwcm92aWRlIGRpc2N1c3Npb24gcG9pbnRzIGZvciBjb25zaWRl cmF0aW9ucyBvZiBrZWVwaW5nIHRoZSBuYW1lc3BhY2VzIGZvciBzdWNoIGtleXMgcG90ZW50aWFs bHkgZGlzam9pbnQuDQo+IA0KPiBbUWluXTogTUQgc2hvdWxkIGhhdmUgbWVhbmluZyBmb3IgYWxs IHRoZSBjYXNlcywgaW4gQkZEIGNhc2UsIGl0IGNvcnJlc3BvbmRzIHRvIGFyZWEtaWQuDQoNClRo ZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgYW4gYXJlYS1pZCBpbiB0aGUgY29udGV4dCBvZiBCRkQu ICBEaWQgeW91IG1lYW4gc29tZXRoaW5nIGVsc2U/DQoNCltRaW5dOiBTZWUgdGhlIE1vZHVsZSBl eGFtcGxlLWJmZC1yb3V0aW5nLWFwcCBpbiB0aGUgc2VjdGlvbiAyLjUuMiBvZiBkcmFmdC1pZXRm LWJmZC15YW5nLTAwLCBhcmVhLWlkIGlzIHBhcnQgb2YgZXhhbXBsZS1iZmQtcm91dGluZy1hcHAu DQoNCj4gSWYgQkZEIGFuZCBMSU1FIG1vZGVsIGhhdmUgdHdvIGRpZmZlcmVudCBtb2RlbCBzdHJ1 Y3R1cmVzLCBNYXBwaW5nIGJldHdlZW4gdHdvIGhldGVyb2dlbmVvdXMgbW9kZWwgc3RydWN0dXJl IGJlY29tZSBhIGNoYWxsZW5naW5nIGpvYi4gSW4gbXkgb3Bpbmlvbiwgd2Ugc2hvdWxkIG5vdCB0 YWtlIHRoaXMgd2F5Lg0KDQpJIGFncmVlIHRoYXQgdGhlIG1hcHBpbmcgaXMgY2hhbGxlbmdpbmcu ICBBdCB0aGUgbW9tZW50LCBJIGZpbmQgYSBob21vZ2Vub3VzIHVzZSB0byBiZSB1bmNsZWFyIGFu ZCBuZWVkIHRoZSBjbGFyaWZpY2F0aW9uIGV4YW1wbGVzIHRvIGNvbnRpbnVlIGNvbW1lbnRpbmcu DQoNCkl0J3MgYWxzbyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IEknbSBub3QgcmVhbGx5IGFza2lu ZyBhZnRlciBCRkQsIGFsdGhvdWdoIHRoYXQncyBhIGxvbmcgdGVybSBnb2FsLiAgQSBzaW1wbGUg cGluZyBvciB0cmFjZXJvdXRlIGV4YW1wbGUgaXMgYSBnb29kIHN0YXJ0Lg0KDQpbUWluXTogU2Vl IHNlY3Rpb24gNS4xIG9mIGRyYWZ0LXpodWFuZy1saW1lLXlhbmctb2FtLW1vZGVsLWFwcGxpY2Fi aWxpdHktMDEsIGl0IGRpZCBnaXZlIGFuIGV4YW1wbGUgZm9yIElQIE9BTSwNCkluIHRoaXMgZXhh bXBsZSwgd2UgY2FuIHNldCB0ZWNobm9sb2d5IHR5cGUgdW5kZXIgZGF0YSBub2RlICJkb21haW4i IHRvIGVpdGhlciBJUHY0IG9yIElQdjYsIElQdjQgbWVhbnMgcGluZyBhbmQgdHJhY2Vyb3V0ZSBm b3IgSVB2NCB0ZWNobm9sb2d5LCBJUHY2IG1lYW5zIHBpbmcgYW5kIHRyYWNlcm91dGUgZm9yIElQ djYuDQogICBtb2R1bGU6IGlldGYtZ2VuLW9hbQ0KICAgICAgKy0tcncgZG9tYWlucw0KICAgICAg ICAgKy0tcncgZG9tYWluKiBbdGVjaG5vbG9neSBNRC1uYW1lLXN0cmluZ10NCiAgICAgICAgICAg ICstLXJ3IHRlY2hub2xvZ3kgICAgICAgIGlkZW50aXR5cmVmICAvLyBzZXQgdG8gSVB2NCBvciBJ UHY2LCAgICAgICAgICAgIA0KICAgICAgICAgICAgKy0tcncgTUQtbmFtZS1zdHJpbmcgICAgTUQt bmFtZS1zdHJpbmcgLy8gc2V0IGJ5IHRoZSBtYW5hZ2VtZW50IHN5c3RlbSANCiAgICAgICAgICAg ICAgICstLXJ3IE1Bcw0KICAgICAgICAgICAgICAgICAgKy0tcncgTUEqIFtNQS1uYW1lLXN0cmlu Z10NCiAgICAgICAgICAgICAgICAgICAgICstLXJ3IE1BLW5hbWUtc3RyaW5nICAgICAgIE1BLW5h bWUtc3RyaW5nIC8vIHNldCBieSB0aGUgbWFuYWdlbWVudCBzeXN0ZW0NCk1EIGlzIHNldCBieSB0 aGUgbWFuYWdlbWVudCBzeXN0ZW0sIGZvciBleGFtcGxlLCBhcyAiTUQxIiBpbiB0aGUgTElNRSBi YXNlIG1vZGVsDQpNQS1uYW1lLXN0cmluZyBpcyBhbHNvIHNldCBieSB0aGUgbWFuYWdlbWVudCBz eXN0ZW0sIGZvciBleGFtcGxlLCBhcyAiTUQxLU1BMSIgaW4gdGhlIExJTUUgYmFzZSBtb2RlbCwg TUEtbmFtZS1zdHJpbmcgY2FuIGJlIHVzZWQgdG8gc3RhbmQgZm9yIHBpbmcgYW5kIHRyYWNlcm91 dGUgZnJvbSBkaWZmZXJlbnQgdGVuYW50IG9yIGN1c3RvbWVyLCBvciBkaXN0aW5ndWlzaCBkaWZm ZXJlbnQgdGVzdHMgdGhhdCBpcyB1c2VkIHRvIHBpbnBvaW50IHRoZSB0eXBlIG9mIGZhdWx0IGFu ZCBpdHMgbG9jYXRpb24uDQoNCklmIHRoZSB0ZXN0cG9pbnQgaW4gdGhlIGRhdGEgcGxhbmUgZG9l c24ndCB3YW50IHRvIHJlY2VpdmUgTUQgYW5kIE1BIGxldmVsIHBhcmFtZXRlcnMsIHRoZSBtYW5h Z2VtZW50IHN5c3RlbSBjYW4gY2hvb3NlIG5vdCB0byBzZW5kIE1EIGFuZCBNQSBsZXZlbCBwYXJh bWV0ZXIgdG8gdGhlIHRlc3QgcG9pbnRzLCB0aGF0IG1lYW5zIHRoZSBtYW5hZ2VtZW50IHN5c3Rl bSBhbmQgdGVzdCBwb2ludCBoYXMgZGlmZmVyZW50IG1vZGVsIHN0cnVjdHVyZXMsIG9uZSBpcyBj b21wbGV0ZSBtb2RlbCBzdHJ1Y3R1cmUgd2l0aCBNRCBhbmQgTUEgbGV2ZWwgcGFyYW1ldGVycywg b25lIGlzIHNpbXBsaWZpZWQgbW9kZWwgc3RydWN0dXJlIHdpdGhvdXQgTUQgYW5kIE1BIGxldmVs IHBhcmFtZXRlcnMsIHdoZW4gdGVzdCBwb2ludCBzZW5kIGJhY2sgdGVzdCByZXN1bHRzIHVzaW5n IHNpbXBsaWZpZWQgbW9kZWwgc3RydWN0dXJlLCB0aGUgbWFuYWdlbWVudCBzeXN0ZW0gbmVlZCB0 byBwdXQgTUQgYW5kIE1BIHBhcmFtZXRlcnMgYmFjayBhbmQgcmVwcmVzZW50IHRoZW0gdXNpbmcg Y29tcGxldGUgbW9kZWwgc3RydWN0dXJlLiBJdCBhZGRzIGEgbG90IG9mIGNvbXBsZXhpdHkgc2lu Y2UgdGhlIG1hbmFnZW1lbnQgc3lzdGVtIG5lZWQgdG8gZmlndXJlIG91dCB3aGljaCB0ZXN0IHJl c3VsdHMgYmVsb25nIHRvIHdoaWNoIE1EIG9yIE1BLiBJbiBzb21lIGNhc2VzLCBpdCBpcyBub3Qg cG9zc2libGUgaWYgdGhlIG1hbmFnZW1lbnQgc3lzdGVtIHNlbmQgbXVsdGlwbGUgcnBjcyBmb3Ig cGluZyB0byB0aGUgdGVzdCBwb2ludCwgaG93IHRoZSBtYW5hZ2VtZW50IHN5c3RlbSB0ZWxsICB3 aGljaCBwaW5nIHJwYyBpcyBmb3IgTUQxLCB3aGljaCBwaW5nIHJwYyBpcyBmb3IgTUQyPw0KDQpI b3dldmVyIGlmIHRoZSB0ZXN0cG9pbnQgaW4gdGhlIGRhdGEgcGxhbmUgY2FuIHJlY2VpdmUgTUQg YW5kIE1BIGxldmVsIHBhcmFtZXRlcnMsIHRoZSBNRCBhbmQgTUEgcGFyYW1ldGVyIE1VU1Qgbm90 IGluamVjdGVkIGludG8gcGluZyBvciB0cmFjZXJvdXRlIGluaXRpYXRlZCBieSB0aGUgdGVzdHBv aW50IHNpbmNlIHBpbmcgYW5kIHRyYWNlcm91dGUgZG9lc24ndCBzdXBwb3J0IG9yIHVuZGVyc3Rh bmQgTUQgYW5kIE1BIHBhcmFtZXRlcnMuICB0aGVyZWZvcmUgdGhlIHRlc3QgcG9pbnQgbmVlZCB0 byBrZWVwIE1EIGFuZCBNQSBwYXJhbWV0ZXIuIFdoZW4gcGluZyBhbmQgdHJhY2Vyb3V0ZSB0YXNr cyBjb21wbGV0ZSBhbmQgdGVzdCByZXN1bHRzIGNvbWUgYmFjaywgdGhlIHRlc3Rwb2ludCByZXBy ZXNlbnQgdGVzdCByZXN1bHRzIHRvZ2V0aGVyIHdpdGggTUQgYW5kIE1BIHBhcmFtZXRlciB1c2lu ZyBMSU1FIGJhc2UgbW9kZWwgc3RydWN0dXJlLCBhbmQgc2VuZCBiYWNrIHRvIHRoZSBtYW5hZ2Vt ZW50IHN5c3RlbS4NCg0KSG9wZSB0aGlzIGNsYXJpZmllcy4NCg0KPiBIb3dldmVyIGlmIHdlIHRh a2UgTElNRSBhcyBhcHBsaWNhdGlvbiBvZiBCRkQsIHRoZW4gYm90aCBCRkQgYW5kIExJTUUgDQo+ IGNhbiBiZSBkZXZlbG9wZWQgYXMgYmFzZSBtb2RlbHMsIEFzIGEgY2xpZW50IG9mIEJGRCwgdGhl IExJTUUgYmFzZSANCj4gbW9kZWwgdXNlcyB0aGUgc2VydmljZXMgcHJvdmlkZWQgYnkgQkZEIG9y IGdyb3VwaW5nIGRlZmluZWQgaW4gQkZEIG1vZGVsKGkuZS4sIEJGRCBjYW4ga2VlcCBpdHMgb3du IG1vZGVsIHN0cnVjdHVyZSkuIFRoZSBMSU1FIEJGRCBZQU5HIG1vZGVsIGF1Z21lbnRzIHRoZSBi YXNlIExJTUUgbW9kdWxlIHRvIHN1cHBvcnQgQkZEIGFuZCBwcm92aWRlIGNvbnNpc3RlbnQgcmVw b3J0aW5nICxjb25maWd1cmF0aW9uIGFuZCByZXByZXNlbnRhdGlvbiBhbmQgaXMgZGVmaW5lZCBh cyBhIHNlcGFyYXRlIG1vZHVsZS4NCj4gSW4gdGhpcyB3YXksIHdlIGNhbiBoYXZlIGNvbW1vbiBM SU1FIG1vZGVsIHN0cnVjdHVyZSBmb3IgYWxsIHRoZSBPQU0gdGVjaG5vbG9naWVzLCBJIHRoaW5r IHRlY2hub2xvZ2llcyBzcGVjaWZpYyBtb2RlbCBzaG91bGQgc2hhcmUgdGhlIHNhbWUgbmFtZXNw YWNlIGFzIHRoZSBiYXNlIG1vZGVsLCB0aGUgbmFtZXNwYWNlcyBzaG91bGQgbm90IGJlIGRpc2pv aW50ZWQuIA0KPiANCj4gSGVyZSBpcyB0aGUgZXhhbXBsZSBvbiBob3cgdHdvIHdvcmQtdmlld3Mg YXJlIHJlbGF0ZWQgdG8gZWFjaCBvdGhlci4NCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC13YW5nLXlhbmctYmZkLW9hbS0wNC50eHQNCg0KVGhhbmtzIGZvciB0aGUgLTA0IHVwZGF0 ZS4gSSBzZWUgdGhhdCB0aGUgYXV0aG9ycyBoYXZlIG5vdyBtb3ZlZCB0byB1c2luZyB0aGUgQkZE IGRlZmluZWQgZ3JvdXBpbmdzIGZvciB0aGUgbW9kZWwuICBUaGlzIGFkZHJlc3NlcyBvbmUgb2Yg bXkgKGFuZCB0aGUgQkZEIHlhbmcgYXV0aG9ycycpIGJpZyBjb25jZXJucy4NCg0KW1Fpbl06IFll cywgaGFwcHkgdG8gc2VlIHRoYXQgd2UgYXJlIGNvbnZlcmdpbmcuDQoNCi0tIEplZmYNCg== From nobody Tue Oct 20 22:10:48 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D8A1B2B21 for ; Tue, 20 Oct 2015 22:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.412 X-Spam-Level: X-Spam-Status: No, score=-101.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 D6eCkg2ZkCF6 for ; Tue, 20 Oct 2015 22:10:43 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7831B2B16 for ; Tue, 20 Oct 2015 22:10:43 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-57-5626bdbd4f85 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F1.D8.32596.DBDB6265; Wed, 21 Oct 2015 00:18:38 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Wed, 21 Oct 2015 01:10:41 -0400 From: Gregory Mirsky To: Qin Wu , Jeffrey Haas Thread-Topic: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? Thread-Index: AQHQ/FQsQS9Qe30F6U2ishtni4XPM55YTBgAgABUyICAGqfqgIAAYhGAgAByLICAAJ4ogIAA4UyA///nJQA= Date: Wed, 21 Oct 2015 05:10:41 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1122190CD67@eusaamb103.ericsson.se> References: <20151001142302.GA10279@pfrc.org> <580BEA5E3B99744AB1F5BFF5E9A3C67D286BED0140@HE111648.emea1.cds.t-internal.com> <20151002155855.GI29696@pfrc.org> <20151019205339.GN15569@pfrc.org> <20151020130821.GB12629@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPuO6+vWphBiv/CVk8nruA1eLTux0s FvsPvmW16Ni2ncli6ZtFLA6sHlN+b2T1aDnyltVjyZKfTB6Xe7eyerS9VAhgjeKySUnNySxL LdK3S+DK2H1wO1PBDJeK788vsjUw7nDqYuTkkBAwkfg0fTIbhC0mceHeejBbSOAoo8SfDqku Ri4gezmjxLttixlBEmwCRhIvNvawg9giAnYSj36eZAaxmQUmMErs2ycLYgsLuEg0L2xlhqhx lViz5SlQPQeQnSRxb5siSJhFQFXizvFmVhCbV8BXYtKj2ywQu7YyS6x8cQesl1MgTOLKlBlg exmBjvt+ag0TxC5xiVtP5jNBHC0gsWTPeWYIW1Ti5eN/rBC2ksTH3/PZIeq1JOY1/IbqVZSY 0v2QHWKxoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKKkaO0OLUsN93IYBMjML6OSbDp7mDc 89LyEKMAB6MSD+8DD7UwIdbEsuLK3EOM0hwsSuK8+5fcDxUSSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAaNjJ4Kd1Xf76TK0vgd2T12WZFqU7287c/J61QSJcZcmtJ+7yzIpVWxtVMy7UyAcd 8ewyCpy9l53thFcuU7E0+9aqJV82fb9uHmbtG2S0Tri4Kswss/R2rOOqqsVux4RVtGvSJt8P efoq4s+XikQL86Q1plIrbyQx3wvl0zrk48biJCK/3UeJpTgj0VCLuag4EQB5nnMkkAIAAA== Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "lime@ietf.org" , "Roland.Schott@telekom.de" Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 05:10:47 -0000 SGkgUWluLA0KcmVnYXJkaW5nIHRoZSBhcmVhLWlkIGluIHRoZSAnbW9kdWxlOiBleGFtcGxlLWJm ZC1yb3V0aW5nLWFwcCcgaW4gdGhlIGRyYWZ0LWlldGYtYmZkLXlhbmcuDQpZb3UgY2FuIG5vdGlj ZSB0aGF0IHRoZSBhcmVhLWlkIGlzIG91dHNpZGUgb2YgQkZEIGNvbmZpZ3VyYXRpb24gYW5kIGNo YXJhY3Rlcml6ZXMgcm91dGluZyBkb21haW4sIG5vdCBCRkQuIEJGRCwgYXMgcGVyIFJGQyA1ODgw LCBpcyBub3QgY29uY2VybmVkIHdpdGggQVMgb3IgVlJGLiBBbmQsIGFzIG9uZSBvZiBjby1hdXRo b3JzLCBjYW4gaW5mb3JtIHRoZSBjb21tdW5pdHkgdGhhdCB3ZSdyZSBjb25zaWRlcmluZyBjaGFu Z2VzIHRvIHRoZSBCRkQgWUFORyBtb2RlbCB0aGF0IHdpbGwgaW1wYWN0IHRoZSBleGFtcGxlIGlu IHF1ZXN0aW9uLg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogTGltZSBbbWFpbHRvOmxpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFFpbiBXdQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyMCwgMjAxNSA3OjM1IFBNDQpUbzog SmVmZnJleSBIYWFzDQpDYzogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpOyBsaW1lQGlldGYu b3JnOyBSb2xhbmQuU2Nob3R0QHRlbGVrb20uZGUNClN1YmplY3Q6IFJlOiBbTGltZV0gQ0ZNIHNl bWFudGljcywgSVAgYW5kIE1QTFMgT0FNIC0gaG93IHRvIHByb2NlZWQ/DQoNCi0tLS0t08q8/tSt vP4tLS0tLQ0Kt6K8/sjLOiBKZWZmcmV5IEhhYXMgW21haWx0bzpqaGFhc0BwZnJjLm9yZ10NCrei y83KsbzkOiAyMDE1xOoxMNTCMjDI1SAyMTowOA0KytW8/sjLOiBRaW4gV3UNCrOty806IENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKTsgUm9sYW5kLlNjaG90dEB0ZWxla29tLmRlOyBsaW1lQGll dGYub3JnDQrW98ziOiBSZTogW0xpbWVdIENGTSBzZW1hbnRpY3MsIElQIGFuZCBNUExTIE9BTSAt IGhvdyB0byBwcm9jZWVkPw0KDQpRaW4sDQoNCk9uIFR1ZSwgT2N0IDIwLCAyMDE1IGF0IDAzOjQy OjE3QU0gKzAwMDAsIFFpbiBXdSB3cm90ZToNCj4gUWluJ3MgbWFpbCBzZWVtZWQgdG8gY29udmV5 IHRoYXQgaW4gdGhlIGNvbnRleHQgb2YgSVAgdGVjaG5vbG9naWVzLCB0aGUgZmllbGRzIGluIHRo ZSB5YW5nIG1vZGVsIGFyZSBzaW1wbHkgImtleXMgb2YgY29udmVuaWVuY2UiIC0gdGhleSBkbyBu b3QgY29ycmVzcG9uZCB0byB1bmRlcmx5aW5nIE9BTSB0ZWNobm9sb2dpZXMuICANCj4gDQo+IFtR aW5dOiBKdXN0IHRvIGNsYXJpZnksIEkgYW0gbm90IGluZGljYXRpbmcgdGhhdC4gSWYgd2UgcHV0 IGFsbCBPQU0gdGVjaG5vbG9naWVzIHVuZGVyIG9ubHkgb25lIHVtYnJlbGxhLCBJIHRoaW5rIHRo ZSBmaWVsZHMgaW4gdGhlIFlBTkcgbW9kZWwsIGVzcGVjaWFsbHkgbGlzdCBrZXksIHNob3VsZCBj b3JyZXNwb25kIHRvIHRoZSB1bmRlcmx5aW5nIHRlY2hub2xvZ2llcy4NCj4gDQo+IFdoaWxlIHRo aXMgc2VlbWVkIHRvIGJlIHRoZSBsaWtlbHkgaWRlYSwgaW4gc29tZSBjYXNlcyB0aGV5IHdpbGwg Y29ycmVzcG9uZCB0byByZWFsIE9BTSBrZXlzIChlLmcuIE1EIGZvciBJRUVFIHRlY2hub2xvZ2ll cykgYW5kIGluIG90aGVycywgYXJlIGp1c3Qga2V5cyBvZiBjb252ZW5pZW5jZS4gIEFuIGV4YW1w bGUgd2lsbCBzaG93IGhvdyB0aGVzZSB0d28gd29ybGQtdmlld3MgcmVsYXRlIHRvIGVhY2ggb3Ro ZXIsIGFuZCBwcm92aWRlIGRpc2N1c3Npb24gcG9pbnRzIGZvciBjb25zaWRlcmF0aW9ucyBvZiBr ZWVwaW5nIHRoZSBuYW1lc3BhY2VzIGZvciBzdWNoIGtleXMgcG90ZW50aWFsbHkgZGlzam9pbnQu DQo+IA0KPiBbUWluXTogTUQgc2hvdWxkIGhhdmUgbWVhbmluZyBmb3IgYWxsIHRoZSBjYXNlcywg aW4gQkZEIGNhc2UsIGl0IGNvcnJlc3BvbmRzIHRvIGFyZWEtaWQuDQoNClRoZXJlIGlzIG5vIHN1 Y2ggdGhpbmcgYXMgYW4gYXJlYS1pZCBpbiB0aGUgY29udGV4dCBvZiBCRkQuICBEaWQgeW91IG1l YW4gc29tZXRoaW5nIGVsc2U/DQoNCltRaW5dOiBTZWUgdGhlIE1vZHVsZSBleGFtcGxlLWJmZC1y b3V0aW5nLWFwcCBpbiB0aGUgc2VjdGlvbiAyLjUuMiBvZiBkcmFmdC1pZXRmLWJmZC15YW5nLTAw LCBhcmVhLWlkIGlzIHBhcnQgb2YgZXhhbXBsZS1iZmQtcm91dGluZy1hcHAuDQoNCj4gSWYgQkZE IGFuZCBMSU1FIG1vZGVsIGhhdmUgdHdvIGRpZmZlcmVudCBtb2RlbCBzdHJ1Y3R1cmVzLCBNYXBw aW5nIGJldHdlZW4gdHdvIGhldGVyb2dlbmVvdXMgbW9kZWwgc3RydWN0dXJlIGJlY29tZSBhIGNo YWxsZW5naW5nIGpvYi4gSW4gbXkgb3Bpbmlvbiwgd2Ugc2hvdWxkIG5vdCB0YWtlIHRoaXMgd2F5 Lg0KDQpJIGFncmVlIHRoYXQgdGhlIG1hcHBpbmcgaXMgY2hhbGxlbmdpbmcuICBBdCB0aGUgbW9t ZW50LCBJIGZpbmQgYSBob21vZ2Vub3VzIHVzZSB0byBiZSB1bmNsZWFyIGFuZCBuZWVkIHRoZSBj bGFyaWZpY2F0aW9uIGV4YW1wbGVzIHRvIGNvbnRpbnVlIGNvbW1lbnRpbmcuDQoNCkl0J3MgYWxz byBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IEknbSBub3QgcmVhbGx5IGFza2luZyBhZnRlciBCRkQs IGFsdGhvdWdoIHRoYXQncyBhIGxvbmcgdGVybSBnb2FsLiAgQSBzaW1wbGUgcGluZyBvciB0cmFj ZXJvdXRlIGV4YW1wbGUgaXMgYSBnb29kIHN0YXJ0Lg0KDQpbUWluXTogU2VlIHNlY3Rpb24gNS4x IG9mIGRyYWZ0LXpodWFuZy1saW1lLXlhbmctb2FtLW1vZGVsLWFwcGxpY2FiaWxpdHktMDEsIGl0 IGRpZCBnaXZlIGFuIGV4YW1wbGUgZm9yIElQIE9BTSwgSW4gdGhpcyBleGFtcGxlLCB3ZSBjYW4g c2V0IHRlY2hub2xvZ3kgdHlwZSB1bmRlciBkYXRhIG5vZGUgImRvbWFpbiIgdG8gZWl0aGVyIElQ djQgb3IgSVB2NiwgSVB2NCBtZWFucyBwaW5nIGFuZCB0cmFjZXJvdXRlIGZvciBJUHY0IHRlY2hu b2xvZ3ksIElQdjYgbWVhbnMgcGluZyBhbmQgdHJhY2Vyb3V0ZSBmb3IgSVB2Ni4NCiAgIG1vZHVs ZTogaWV0Zi1nZW4tb2FtDQogICAgICArLS1ydyBkb21haW5zDQogICAgICAgICArLS1ydyBkb21h aW4qIFt0ZWNobm9sb2d5IE1ELW5hbWUtc3RyaW5nXQ0KICAgICAgICAgICAgKy0tcncgdGVjaG5v bG9neSAgICAgICAgaWRlbnRpdHlyZWYgIC8vIHNldCB0byBJUHY0IG9yIElQdjYsICAgICAgICAg ICAgDQogICAgICAgICAgICArLS1ydyBNRC1uYW1lLXN0cmluZyAgICBNRC1uYW1lLXN0cmluZyAv LyBzZXQgYnkgdGhlIG1hbmFnZW1lbnQgc3lzdGVtIA0KICAgICAgICAgICAgICAgKy0tcncgTUFz DQogICAgICAgICAgICAgICAgICArLS1ydyBNQSogW01BLW5hbWUtc3RyaW5nXQ0KICAgICAgICAg ICAgICAgICAgICAgKy0tcncgTUEtbmFtZS1zdHJpbmcgICAgICAgTUEtbmFtZS1zdHJpbmcgLy8g c2V0IGJ5IHRoZSBtYW5hZ2VtZW50IHN5c3RlbQ0KTUQgaXMgc2V0IGJ5IHRoZSBtYW5hZ2VtZW50 IHN5c3RlbSwgZm9yIGV4YW1wbGUsIGFzICJNRDEiIGluIHRoZSBMSU1FIGJhc2UgbW9kZWwgTUEt bmFtZS1zdHJpbmcgaXMgYWxzbyBzZXQgYnkgdGhlIG1hbmFnZW1lbnQgc3lzdGVtLCBmb3IgZXhh bXBsZSwgYXMgIk1EMS1NQTEiIGluIHRoZSBMSU1FIGJhc2UgbW9kZWwsIE1BLW5hbWUtc3RyaW5n IGNhbiBiZSB1c2VkIHRvIHN0YW5kIGZvciBwaW5nIGFuZCB0cmFjZXJvdXRlIGZyb20gZGlmZmVy ZW50IHRlbmFudCBvciBjdXN0b21lciwgb3IgZGlzdGluZ3Vpc2ggZGlmZmVyZW50IHRlc3RzIHRo YXQgaXMgdXNlZCB0byBwaW5wb2ludCB0aGUgdHlwZSBvZiBmYXVsdCBhbmQgaXRzIGxvY2F0aW9u Lg0KDQpJZiB0aGUgdGVzdHBvaW50IGluIHRoZSBkYXRhIHBsYW5lIGRvZXNuJ3Qgd2FudCB0byBy ZWNlaXZlIE1EIGFuZCBNQSBsZXZlbCBwYXJhbWV0ZXJzLCB0aGUgbWFuYWdlbWVudCBzeXN0ZW0g Y2FuIGNob29zZSBub3QgdG8gc2VuZCBNRCBhbmQgTUEgbGV2ZWwgcGFyYW1ldGVyIHRvIHRoZSB0 ZXN0IHBvaW50cywgdGhhdCBtZWFucyB0aGUgbWFuYWdlbWVudCBzeXN0ZW0gYW5kIHRlc3QgcG9p bnQgaGFzIGRpZmZlcmVudCBtb2RlbCBzdHJ1Y3R1cmVzLCBvbmUgaXMgY29tcGxldGUgbW9kZWwg c3RydWN0dXJlIHdpdGggTUQgYW5kIE1BIGxldmVsIHBhcmFtZXRlcnMsIG9uZSBpcyBzaW1wbGlm aWVkIG1vZGVsIHN0cnVjdHVyZSB3aXRob3V0IE1EIGFuZCBNQSBsZXZlbCBwYXJhbWV0ZXJzLCB3 aGVuIHRlc3QgcG9pbnQgc2VuZCBiYWNrIHRlc3QgcmVzdWx0cyB1c2luZyBzaW1wbGlmaWVkIG1v ZGVsIHN0cnVjdHVyZSwgdGhlIG1hbmFnZW1lbnQgc3lzdGVtIG5lZWQgdG8gcHV0IE1EIGFuZCBN QSBwYXJhbWV0ZXJzIGJhY2sgYW5kIHJlcHJlc2VudCB0aGVtIHVzaW5nIGNvbXBsZXRlIG1vZGVs IHN0cnVjdHVyZS4gSXQgYWRkcyBhIGxvdCBvZiBjb21wbGV4aXR5IHNpbmNlIHRoZSBtYW5hZ2Vt ZW50IHN5c3RlbSBuZWVkIHRvIGZpZ3VyZSBvdXQgd2hpY2ggdGVzdCByZXN1bHRzIGJlbG9uZyB0 byB3aGljaCBNRCBvciBNQS4gSW4gc29tZSBjYXNlcywgaXQgaXMgbm90IHBvc3NpYmxlIGlmIHRo ZSBtYW5hZ2VtZW50IHN5c3RlbSBzZW5kIG11bHRpcGxlIHJwY3MgZm9yIHBpbmcgdG8gdGhlIHRl c3QgcG9pbnQsIGhvdyB0aGUgbWFuYWdlbWVudCBzeXN0ZW0gdGVsbCAgd2hpY2ggcGluZyBycGMg aXMgZm9yIE1EMSwgd2hpY2ggcGluZyBycGMgaXMgZm9yIE1EMj8NCg0KSG93ZXZlciBpZiB0aGUg dGVzdHBvaW50IGluIHRoZSBkYXRhIHBsYW5lIGNhbiByZWNlaXZlIE1EIGFuZCBNQSBsZXZlbCBw YXJhbWV0ZXJzLCB0aGUgTUQgYW5kIE1BIHBhcmFtZXRlciBNVVNUIG5vdCBpbmplY3RlZCBpbnRv IHBpbmcgb3IgdHJhY2Vyb3V0ZSBpbml0aWF0ZWQgYnkgdGhlIHRlc3Rwb2ludCBzaW5jZSBwaW5n IGFuZCB0cmFjZXJvdXRlIGRvZXNuJ3Qgc3VwcG9ydCBvciB1bmRlcnN0YW5kIE1EIGFuZCBNQSBw YXJhbWV0ZXJzLiAgdGhlcmVmb3JlIHRoZSB0ZXN0IHBvaW50IG5lZWQgdG8ga2VlcCBNRCBhbmQg TUEgcGFyYW1ldGVyLiBXaGVuIHBpbmcgYW5kIHRyYWNlcm91dGUgdGFza3MgY29tcGxldGUgYW5k IHRlc3QgcmVzdWx0cyBjb21lIGJhY2ssIHRoZSB0ZXN0cG9pbnQgcmVwcmVzZW50IHRlc3QgcmVz dWx0cyB0b2dldGhlciB3aXRoIE1EIGFuZCBNQSBwYXJhbWV0ZXIgdXNpbmcgTElNRSBiYXNlIG1v ZGVsIHN0cnVjdHVyZSwgYW5kIHNlbmQgYmFjayB0byB0aGUgbWFuYWdlbWVudCBzeXN0ZW0uDQoN CkhvcGUgdGhpcyBjbGFyaWZpZXMuDQoNCj4gSG93ZXZlciBpZiB3ZSB0YWtlIExJTUUgYXMgYXBw bGljYXRpb24gb2YgQkZELCB0aGVuIGJvdGggQkZEIGFuZCBMSU1FIA0KPiBjYW4gYmUgZGV2ZWxv cGVkIGFzIGJhc2UgbW9kZWxzLCBBcyBhIGNsaWVudCBvZiBCRkQsIHRoZSBMSU1FIGJhc2UgDQo+ IG1vZGVsIHVzZXMgdGhlIHNlcnZpY2VzIHByb3ZpZGVkIGJ5IEJGRCBvciBncm91cGluZyBkZWZp bmVkIGluIEJGRCBtb2RlbChpLmUuLCBCRkQgY2FuIGtlZXAgaXRzIG93biBtb2RlbCBzdHJ1Y3R1 cmUpLiBUaGUgTElNRSBCRkQgWUFORyBtb2RlbCBhdWdtZW50cyB0aGUgYmFzZSBMSU1FIG1vZHVs ZSB0byBzdXBwb3J0IEJGRCBhbmQgcHJvdmlkZSBjb25zaXN0ZW50IHJlcG9ydGluZyAsY29uZmln dXJhdGlvbiBhbmQgcmVwcmVzZW50YXRpb24gYW5kIGlzIGRlZmluZWQgYXMgYSBzZXBhcmF0ZSBt b2R1bGUuDQo+IEluIHRoaXMgd2F5LCB3ZSBjYW4gaGF2ZSBjb21tb24gTElNRSBtb2RlbCBzdHJ1 Y3R1cmUgZm9yIGFsbCB0aGUgT0FNIHRlY2hub2xvZ2llcywgSSB0aGluayB0ZWNobm9sb2dpZXMg c3BlY2lmaWMgbW9kZWwgc2hvdWxkIHNoYXJlIHRoZSBzYW1lIG5hbWVzcGFjZSBhcyB0aGUgYmFz ZSBtb2RlbCwgdGhlIG5hbWVzcGFjZXMgc2hvdWxkIG5vdCBiZSBkaXNqb2ludGVkLiANCj4gDQo+ IEhlcmUgaXMgdGhlIGV4YW1wbGUgb24gaG93IHR3byB3b3JkLXZpZXdzIGFyZSByZWxhdGVkIHRv IGVhY2ggb3RoZXIuDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FuZy15YW5n LWJmZC1vYW0tMDQudHh0DQoNClRoYW5rcyBmb3IgdGhlIC0wNCB1cGRhdGUuIEkgc2VlIHRoYXQg dGhlIGF1dGhvcnMgaGF2ZSBub3cgbW92ZWQgdG8gdXNpbmcgdGhlIEJGRCBkZWZpbmVkIGdyb3Vw aW5ncyBmb3IgdGhlIG1vZGVsLiAgVGhpcyBhZGRyZXNzZXMgb25lIG9mIG15IChhbmQgdGhlIEJG RCB5YW5nIGF1dGhvcnMnKSBiaWcgY29uY2VybnMuDQoNCltRaW5dOiBZZXMsIGhhcHB5IHRvIHNl ZSB0aGF0IHdlIGFyZSBjb252ZXJnaW5nLg0KDQotLSBKZWZmDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTGltZSBtYWlsaW5nIGxpc3QNCkxpbWVAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGltZQ0K From nobody Fri Oct 23 05:31:30 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D9A1B35A5 for ; Fri, 23 Oct 2015 05:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 59frKv5FBJ19 for ; Fri, 23 Oct 2015 05:31:27 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37911B35A3 for ; Fri, 23 Oct 2015 05:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6480; q=dns/txt; s=iport; t=1445603487; x=1446813087; h=to:cc:from:subject:message-id:date:mime-version; bh=SKNzq7JponZ3tEqBqNQsNj1cItkYZ3oaPv9iTfWmZZQ=; b=UeYVjwnTVNNprmPEsXPx0UMc/6HJcMbR3yCwYAbnnNvOnxm8VzS9NKLY S56CTDhTZz1lUPPFjo25aXayJIO4EvZrsF8tfyYOLU9IpeZsOA/WvQ2uN UY/tTY7WPzLvg+cGiDSkrzLmEYBJN4qYI5I0L+s+sr83IzZ/6C+HFEoLY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoBAAVKCpW/xbLJq1ehApvwBAhhXyCFgEBAQEBAYELhDUnVQE8FgsCCwMCAQIBWAgBAYgsDbJXkmEBAQEHAgEghneKC4JwgUUFjRSJF40egViHQI8eg3BjhAU8NAGGQgEBAQ X-IronPort-AV: E=Sophos;i="5.20,186,1444694400"; d="scan'208,217";a="607740118" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 23 Oct 2015 12:31:24 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9NCVOZL029048; Fri, 23 Oct 2015 12:31:24 GMT To: draft-wang-yang-bfd-oam@tools.ietf.org From: Benoit Claise Message-ID: <562A2888.8090807@cisco.com> Date: Fri, 23 Oct 2015 14:31:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030004010401070107000508" Archived-At: Cc: "lime@ietf.org" Subject: [Lime] lime-bfd-extension.yang in draft-wang-yang-bfd-oam-04.txt: doesn't compile X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 12:31:29 -0000 This is a multi-part message in MIME format. --------------030004010401070107000508 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Note that your lime-bfd-extension.yang YANG model doesn't compile _pyang produces: _ lime-bfd-extension.yang:8: warning: imported module ietf-inet-types not used lime-bfd-extension.yang:137: error: prefix "if" is not defined (reported only once) ietf-gen-oam.yang:1: error: unexpected modulename "ietf-trill-oam" in ietf-gen-oam.yang, should be ietf-gen-oam _pyang --ietf produces:_ lime-bfd-extension.yang:1: warning: RFC 6087: 4.1: no module name prefix used, suggest ietf-lime-bfd-extension lime-bfd-extension.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement lime-bfd-extension.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement lime-bfd-extension.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement lime-bfd-extension.yang:8: warning: imported module ietf-inet-types not used lime-bfd-extension.yang:14: error: RFC 6087: 4.7: statement "revision" must have a "reference" substatement lime-bfd-extension.yang:78: error: RFC 6087: 4.12: statement "augment" must have a "description" substatement lime-bfd-extension.yang:79: warning: RFC 6087: 4.12: statement "when" should have a "description" substatement lime-bfd-extension.yang:80: error: RFC 6087: 4.12: statement "leaf" must have a "description" substatement lime-bfd-extension.yang:88: error: RFC 6087: 4.12: statement "augment" must have a "description" substatement lime-bfd-extension.yang:89: warning: RFC 6087: 4.12: statement "when" should have a "description" substatement lime-bfd-extension.yang:102: error: RFC 6087: 4.12: statement "augment" must have a "description" substatement lime-bfd-extension.yang:104: warning: RFC 6087: 4.12: statement "when" should have a "description" substatement lime-bfd-extension.yang:109: error: RFC 6087: 4.12: statement "augment" must have a "description" substatement lime-bfd-extension.yang:110: warning: RFC 6087: 4.12: statement "when" should have a "description" substatement lime-bfd-extension.yang:127: error: RFC 6087: 4.12: statement "augment" must have a "description" substatement lime-bfd-extension.yang:129: warning: RFC 6087: 4.12: statement "when" should have a "description" substatement lime-bfd-extension.yang:133: error: RFC 6087: 4.12,4.14: statement "notification" must have a "description" substatement lime-bfd-extension.yang:137: error: prefix "if" is not defined (reported only once) ietf-gen-oam.yang:1: error: unexpected modulename "ietf-trill-oam" in ietf-gen-oam.yang, should be ietf-gen-oam Note that I compile all YANG models extracted from drafts at http://www.claise.be/IETFYANGPageCompilation.html Regards, Benoit --------------030004010401070107000508 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear authors,

Note that your lime-bfd-extension.yang YANG model doesn't compile

pyang produces:

lime-bfd-extension.yang:8: warning: imported module ietf-inet-types not used
lime-bfd-extension.yang:137: error: prefix "if" is not defined (reported only once)
ietf-gen-oam.yang:1: error: unexpected modulename "ietf-trill-oam" in ietf-gen-oam.yang, should be ietf-gen-oam

pyang --ietf produces:
lime-bfd-extension.yang:1: warning: RFC 6087: 4.1: no module name prefix used, suggest ietf-lime-bfd-extension
lime-bfd-extension.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement
lime-bfd-extension.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement
lime-bfd-extension.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement
lime-bfd-extension.yang:8: warning: imported module ietf-inet-types not used
lime-bfd-extension.yang:14: error: RFC 6087: 4.7: statement "revision" must have a "reference" substatement
lime-bfd-extension.yang:78: error: RFC 6087: 4.12: statement "augment" must have a "description" substatement
lime-bfd-extension.yang:79: warning: RFC 6087: 4.12: statement "when" should have a "description" substatement
lime-bfd-extension.yang:80: error: RFC 6087: 4.12: statement "leaf" must have a "description" substatement
lime-bfd-extension.yang:88: error: RFC 6087: 4.12: statement "augment" must have a "description" substatement
lime-bfd-extension.yang:89: warning: RFC 6087: 4.12: statement "when" should have a "description" substatement
lime-bfd-extension.yang:102: error: RFC 6087: 4.12: statement "augment" must have a "description" substatement
lime-bfd-extension.yang:104: warning: RFC 6087: 4.12: statement "when" should have a "description" substatement
lime-bfd-extension.yang:109: error: RFC 6087: 4.12: statement "augment" must have a "description" substatement
lime-bfd-extension.yang:110: warning: RFC 6087: 4.12: statement "when" should have a "description" substatement
lime-bfd-extension.yang:127: error: RFC 6087: 4.12: statement "augment" must have a "description" substatement
lime-bfd-extension.yang:129: warning: RFC 6087: 4.12: statement "when" should have a "description" substatement
lime-bfd-extension.yang:133: error: RFC 6087: 4.12,4.14: statement "notification" must have a "description" substatement
lime-bfd-extension.yang:137: error: prefix "if" is not defined (reported only once)
ietf-gen-oam.yang:1: error: unexpected modulename "ietf-trill-oam" in ietf-gen-oam.yang, should be ietf-gen-oam

Note that I compile all YANG models extracted from drafts at http://www.claise.be/IETFYANGPageCompilation.html

Regards, Benoit
--------------030004010401070107000508-- From nobody Fri Oct 23 05:48:44 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3E1B36A4; Fri, 23 Oct 2015 05:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 GfA_5o3hS1b8; Fri, 23 Oct 2015 05:48:41 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF4AC1B36A8; Fri, 23 Oct 2015 05:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=467; q=dns/txt; s=iport; t=1445604521; x=1446814121; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=WuFMW7YWboBQv9EIKNeradgyF/ZkNNyJ6REj5f40B0o=; b=Ou9bYQ/QLsdcib64sCIz1szAxFf9/Zkvv7oIz2X2p/g0LvQEnSjCLe3u ca8gjEe/Zg3Td7vNGSyqW7z9s7gv0l7W0kriQ7EppJLjdbNy2I+a6HhlY QXrqCBN1219PXxKu2Ws/dbRefTwjZ6rAXkeGKrys24vXqxiyryZtUVDNh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DNAQDfKypW/xbLJq1ehApvvikBDYFZIYd+FAEBAQEBAQGBCoRcFUA2AgUWBAcCCwMCAQIBSwEMCAEBiCwNslqSYwEBAQcCASCBIoVVjHuBRQEEjRSJF40eiRiTDh8BAUKCRIFBPDQBhkIBAQE X-IronPort-AV: E=Sophos;i="5.20,186,1444694400"; d="scan'208";a="612350954" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 23 Oct 2015 12:48:37 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9NCmbMb010560; Fri, 23 Oct 2015 12:48:37 GMT To: draft-ietf-trill-yang-oam@ietf.org, "lime@ietf.org" From: Benoit Claise Message-ID: <562A2C91.9050103@cisco.com> Date: Fri, 23 Oct 2015 14:48:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Lime] ietf-gen-oam.yang in both draft-ietf-lime-yang-oam-model-00.txt and draft-ietf-trill-yang-oam-01.txt X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 12:48:42 -0000 Dear all, The same YANG module name is used in both drafts. This is confusing, and only of them shows at http://www.claise.be/IETFYANGPageCompilation.html Actually, one should reference the other. Since we have roughly the same authors for both drafts, this shouldn't be an issue. Note: - ietf-gen-oam.yang from both draft-ietf-lime-yang-oam-model-00.txt compiles correctly. - the ones from draft-ietf-trill-yang-oam-01.txt fails Regards, Benoit From nobody Fri Oct 23 06:18:40 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E130E1A00A1 for ; Fri, 23 Oct 2015 06:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 oaAy4CdDQ77w for ; Fri, 23 Oct 2015 06:18:37 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4C11A00A4 for ; Fri, 23 Oct 2015 06:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2378; q=dns/txt; s=iport; t=1445606317; x=1446815917; h=to:cc:from:subject:message-id:date:mime-version; bh=aJDbpqr+UoECdeSwyr2A7DJTzRw8bqZwEbGBPakskrw=; b=m+Yga6B2mthoJH5pS05bgGmBXU4FauKx0J7MGHkyJDdRFPIgkCixd0Ee MGwBWpq43sOsOi8HNP4Q9Ja2GVi3BFaebY3+MwVgakSmDs6YcZqQTxZEz CfgkhPBvwxd9uRvhg8XiqA9yqQ/tlIpGGowin9LJq4sYOk2ekvpqopEPG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOAQDxMipW/xbLJq1ehApvvikBDYFZIYV8ggMUAQEBAQEBAYEKhDUnVQEfARwWCwILAwIBAgFYCAEBiCwNsmGSYgEBCAIBIIZ3igseglKBRQWWK40egViHQI8eg3AfAQFChAU8NAGGQgEBAQ X-IronPort-AV: E=Sophos;i="5.20,186,1444694400"; d="scan'208,217";a="630461164" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 23 Oct 2015 13:18:33 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9NDIX3Q016457; Fri, 23 Oct 2015 13:18:33 GMT To: draft-wang-lime-yang-pm@tools.ietf.org From: Benoit Claise Message-ID: <562A3394.2070000@cisco.com> Date: Fri, 23 Oct 2015 15:18:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090407020408050102050301" Archived-At: Cc: "lime@ietf.org" Subject: [Lime] ietf-gen-oam-pm.yang in draft-wang-lime-yang-pm-00.txt: doesn't compile X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 13:18:39 -0000 This is a multi-part message in MIME format. --------------090407020408050102050301 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Note that your ietf-gen-oam-pm.yang YANG model doesn't compile _pyang --ietf produces:_ lietf-gen-oam-pm.yang:5: error: module "gen-oam" not found in search path ietf-gen-oam-pm.yang:913: error: RFC 6087: 4.12: statement "container" must have a "description" substatement ietf-gen-oam-pm.yang:939: error: RFC 6087: 4.12: statement "container" must have a "description" substatement ietf-gen-oam-pm.yang:967: error: RFC 6087: 4.12: statement "container" must have a "description" substatement ietf-gen-oam-pm.yang:995: error: RFC 6087: 4.12: statement "container" must have a "description" substatement Note that I compile all YANG models extracted from drafts at http://www.claise.be/IETFYANGPageCompilation.html Regards, Benoit --------------090407020408050102050301 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear authors,

Note that your ietf-gen-oam-pm.yang YANG model doesn't compile

pyang --ietf produces:
lietf-gen-oam-pm.yang:5: error: module "gen-oam" not found in search path
ietf-gen-oam-pm.yang:913: error: RFC 6087: 4.12: statement "container" must have a "description" substatement
ietf-gen-oam-pm.yang:939: error: RFC 6087: 4.12: statement "container" must have a "description" substatement
ietf-gen-oam-pm.yang:967: error: RFC 6087: 4.12: statement "container" must have a "description" substatement
ietf-gen-oam-pm.yang:995: error: RFC 6087: 4.12: statement "container" must have a "description" substatement

Note that I compile all YANG models extracted from drafts at http://www.claise.be/IETFYANGPageCompilation.html

Regards, Benoit --------------090407020408050102050301-- From nobody Sun Oct 25 18:16:17 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A621B3478 for ; Sun, 25 Oct 2015 18:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 aiXxqjlcCHiP for ; Sun, 25 Oct 2015 18:16:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA7D1B3477 for ; Sun, 25 Oct 2015 18:16:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZG59848; Mon, 26 Oct 2015 01:16:08 +0000 (GMT) Received: from SZXEML424-HUB.china.huawei.com (10.82.67.153) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 26 Oct 2015 01:16:06 +0000 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.132]) by SZXEML424-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.03.0235.001; Mon, 26 Oct 2015 09:16:02 +0800 From: wangzitao To: Benoit Claise , "draft-wang-yang-bfd-oam@tools.ietf.org" Thread-Topic: [Lime] lime-bfd-extension.yang in draft-wang-yang-bfd-oam-04.txt: doesn't compile Thread-Index: AQHRDY7Fn+NCPHl3yUei6dy+wKWFr558/DbQ Date: Mon, 26 Oct 2015 01:16:01 +0000 Message-ID: References: <562A2888.8090807@cisco.com> In-Reply-To: <562A2888.8090807@cisco.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.120] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EACA9E14szxeml501mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "lime@ietf.org" Subject: Re: [Lime] lime-bfd-extension.yang in draft-wang-yang-bfd-oam-04.txt: doesn't compile X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 01:16:15 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EACA9E14szxeml501mbxchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91ISBXZSB3aWxsIGZpeCBpdCBhcyBzb29uIGFzIHBvc3NpYmxlLg0KDQpCZXN0IFJl Z2FyZHMhDQotTWljaGFlbA0KDQrlj5Hku7bkuro6IExpbWUgW21haWx0bzpsaW1lLWJvdW5jZXNA aWV0Zi5vcmddIOS7o+ihqCBCZW5vaXQgQ2xhaXNlDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQxMOac iDIz5pelIDIwOjMxDQrmlLbku7bkuro6IGRyYWZ0LXdhbmcteWFuZy1iZmQtb2FtQHRvb2xzLmll dGYub3JnDQrmioTpgIE6IGxpbWVAaWV0Zi5vcmcNCuS4u+mimDogW0xpbWVdIGxpbWUtYmZkLWV4 dGVuc2lvbi55YW5nIGluIGRyYWZ0LXdhbmcteWFuZy1iZmQtb2FtLTA0LnR4dDogZG9lc24ndCBj b21waWxlDQoNCkRlYXIgYXV0aG9ycywNCg0KTm90ZSB0aGF0IHlvdXIgbGltZS1iZmQtZXh0ZW5z aW9uLnlhbmcgWUFORyBtb2RlbCBkb2Vzbid0IGNvbXBpbGUNCg0KcHlhbmcgcHJvZHVjZXM6DQoN CmxpbWUtYmZkLWV4dGVuc2lvbi55YW5nOjg6IHdhcm5pbmc6IGltcG9ydGVkIG1vZHVsZSBpZXRm LWluZXQtdHlwZXMgbm90IHVzZWQNCmxpbWUtYmZkLWV4dGVuc2lvbi55YW5nOjEzNzogZXJyb3I6 IHByZWZpeCAiaWYiIGlzIG5vdCBkZWZpbmVkIChyZXBvcnRlZCBvbmx5IG9uY2UpDQppZXRmLWdl bi1vYW0ueWFuZzoxOiBlcnJvcjogdW5leHBlY3RlZCBtb2R1bGVuYW1lICJpZXRmLXRyaWxsLW9h bSIgaW4gaWV0Zi1nZW4tb2FtLnlhbmcsIHNob3VsZCBiZSBpZXRmLWdlbi1vYW0NCg0KcHlhbmcg LS1pZXRmIHByb2R1Y2VzOg0KbGltZS1iZmQtZXh0ZW5zaW9uLnlhbmc6MTogd2FybmluZzogUkZD IDYwODc6IDQuMTogbm8gbW9kdWxlIG5hbWUgcHJlZml4IHVzZWQsIHN1Z2dlc3QgaWV0Zi1saW1l LWJmZC1leHRlbnNpb24NCmxpbWUtYmZkLWV4dGVuc2lvbi55YW5nOjE6IGVycm9yOiBSRkMgNjA4 NzogNC43OiBzdGF0ZW1lbnQgIm1vZHVsZSIgbXVzdCBoYXZlIGEgImNvbnRhY3QiIHN1YnN0YXRl bWVudA0KbGltZS1iZmQtZXh0ZW5zaW9uLnlhbmc6MTogZXJyb3I6IFJGQyA2MDg3OiA0Ljc6IHN0 YXRlbWVudCAibW9kdWxlIiBtdXN0IGhhdmUgYSAib3JnYW5pemF0aW9uIiBzdWJzdGF0ZW1lbnQN CmxpbWUtYmZkLWV4dGVuc2lvbi55YW5nOjE6IGVycm9yOiBSRkMgNjA4NzogNC43OiBzdGF0ZW1l bnQgIm1vZHVsZSIgbXVzdCBoYXZlIGEgImRlc2NyaXB0aW9uIiBzdWJzdGF0ZW1lbnQNCmxpbWUt YmZkLWV4dGVuc2lvbi55YW5nOjg6IHdhcm5pbmc6IGltcG9ydGVkIG1vZHVsZSBpZXRmLWluZXQt dHlwZXMgbm90IHVzZWQNCmxpbWUtYmZkLWV4dGVuc2lvbi55YW5nOjE0OiBlcnJvcjogUkZDIDYw ODc6IDQuNzogc3RhdGVtZW50ICJyZXZpc2lvbiIgbXVzdCBoYXZlIGEgInJlZmVyZW5jZSIgc3Vi c3RhdGVtZW50DQpsaW1lLWJmZC1leHRlbnNpb24ueWFuZzo3ODogZXJyb3I6IFJGQyA2MDg3OiA0 LjEyOiBzdGF0ZW1lbnQgImF1Z21lbnQiIG11c3QgaGF2ZSBhICJkZXNjcmlwdGlvbiIgc3Vic3Rh dGVtZW50DQpsaW1lLWJmZC1leHRlbnNpb24ueWFuZzo3OTogd2FybmluZzogUkZDIDYwODc6IDQu MTI6IHN0YXRlbWVudCAid2hlbiIgc2hvdWxkIGhhdmUgYSAiZGVzY3JpcHRpb24iIHN1YnN0YXRl bWVudA0KbGltZS1iZmQtZXh0ZW5zaW9uLnlhbmc6ODA6IGVycm9yOiBSRkMgNjA4NzogNC4xMjog c3RhdGVtZW50ICJsZWFmIiBtdXN0IGhhdmUgYSAiZGVzY3JpcHRpb24iIHN1YnN0YXRlbWVudA0K bGltZS1iZmQtZXh0ZW5zaW9uLnlhbmc6ODg6IGVycm9yOiBSRkMgNjA4NzogNC4xMjogc3RhdGVt ZW50ICJhdWdtZW50IiBtdXN0IGhhdmUgYSAiZGVzY3JpcHRpb24iIHN1YnN0YXRlbWVudA0KbGlt ZS1iZmQtZXh0ZW5zaW9uLnlhbmc6ODk6IHdhcm5pbmc6IFJGQyA2MDg3OiA0LjEyOiBzdGF0ZW1l bnQgIndoZW4iIHNob3VsZCBoYXZlIGEgImRlc2NyaXB0aW9uIiBzdWJzdGF0ZW1lbnQNCmxpbWUt YmZkLWV4dGVuc2lvbi55YW5nOjEwMjogZXJyb3I6IFJGQyA2MDg3OiA0LjEyOiBzdGF0ZW1lbnQg ImF1Z21lbnQiIG11c3QgaGF2ZSBhICJkZXNjcmlwdGlvbiIgc3Vic3RhdGVtZW50DQpsaW1lLWJm ZC1leHRlbnNpb24ueWFuZzoxMDQ6IHdhcm5pbmc6IFJGQyA2MDg3OiA0LjEyOiBzdGF0ZW1lbnQg IndoZW4iIHNob3VsZCBoYXZlIGEgImRlc2NyaXB0aW9uIiBzdWJzdGF0ZW1lbnQNCmxpbWUtYmZk LWV4dGVuc2lvbi55YW5nOjEwOTogZXJyb3I6IFJGQyA2MDg3OiA0LjEyOiBzdGF0ZW1lbnQgImF1 Z21lbnQiIG11c3QgaGF2ZSBhICJkZXNjcmlwdGlvbiIgc3Vic3RhdGVtZW50DQpsaW1lLWJmZC1l eHRlbnNpb24ueWFuZzoxMTA6IHdhcm5pbmc6IFJGQyA2MDg3OiA0LjEyOiBzdGF0ZW1lbnQgIndo ZW4iIHNob3VsZCBoYXZlIGEgImRlc2NyaXB0aW9uIiBzdWJzdGF0ZW1lbnQNCmxpbWUtYmZkLWV4 dGVuc2lvbi55YW5nOjEyNzogZXJyb3I6IFJGQyA2MDg3OiA0LjEyOiBzdGF0ZW1lbnQgImF1Z21l bnQiIG11c3QgaGF2ZSBhICJkZXNjcmlwdGlvbiIgc3Vic3RhdGVtZW50DQpsaW1lLWJmZC1leHRl bnNpb24ueWFuZzoxMjk6IHdhcm5pbmc6IFJGQyA2MDg3OiA0LjEyOiBzdGF0ZW1lbnQgIndoZW4i IHNob3VsZCBoYXZlIGEgImRlc2NyaXB0aW9uIiBzdWJzdGF0ZW1lbnQNCmxpbWUtYmZkLWV4dGVu c2lvbi55YW5nOjEzMzogZXJyb3I6IFJGQyA2MDg3OiA0LjEyLDQuMTQ6IHN0YXRlbWVudCAibm90 aWZpY2F0aW9uIiBtdXN0IGhhdmUgYSAiZGVzY3JpcHRpb24iIHN1YnN0YXRlbWVudA0KbGltZS1i ZmQtZXh0ZW5zaW9uLnlhbmc6MTM3OiBlcnJvcjogcHJlZml4ICJpZiIgaXMgbm90IGRlZmluZWQg KHJlcG9ydGVkIG9ubHkgb25jZSkNCmlldGYtZ2VuLW9hbS55YW5nOjE6IGVycm9yOiB1bmV4cGVj dGVkIG1vZHVsZW5hbWUgImlldGYtdHJpbGwtb2FtIiBpbiBpZXRmLWdlbi1vYW0ueWFuZywgc2hv dWxkIGJlIGlldGYtZ2VuLW9hbQ0KDQpOb3RlIHRoYXQgSSBjb21waWxlIGFsbCBZQU5HIG1vZGVs cyBleHRyYWN0ZWQgZnJvbSBkcmFmdHMgYXQgaHR0cDovL3d3dy5jbGFpc2UuYmUvSUVURllBTkdQ YWdlQ29tcGlsYXRpb24uaHRtbA0KDQpSZWdhcmRzLCBCZW5vaXQNCg== --_000_E6BC9BBCBCACC246846FC685F9FF41EACA9E14szxeml501mbxchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBs YW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UhIFdlIHdpbGwgZml4IGl0 IGFzIHNvb24gYXMgcG9zc2libGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkJlc3QgUmVnYXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pi1NaWNoYWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6d2luZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 d2luZG93dGV4dCI+IExpbWUgW21haWx0bzpsaW1lLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Luj6KGo IDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOndpbmRvd3RleHQiPkJlbm9pdCBDbGFpc2U8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+IDIwMTU8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMi PjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMzwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJF Ti1VUyI+DQogMjA6MzE8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gZHJhZnQtd2FuZy15YW5nLWJmZC1vYW1A dG9vbHMuaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gbGltZUBpZXRmLm9yZzxicj4NCjwvc3Bhbj48 Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBbTGltZV0gbGltZS1iZmQtZXh0ZW5zaW9uLnlhbmcgaW4gZHJhZnQtd2FuZy15YW5nLWJmZC1v YW0tMDQudHh0OiBkb2Vzbid0IGNvbXBpbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+RGVhciBhdXRob3JzLDxicj4NCjxicj4NCk5vdGUgdGhhdCB5b3VyIGxpbWUt YmZkLWV4dGVuc2lvbi55YW5nIFlBTkcgbW9kZWwgZG9lc24ndCBjb21waWxlIDxicj4NCjxicj4N Cjx1PnB5YW5nIHByb2R1Y2VzOjxicj4NCjwvdT48YnI+DQpsaW1lLWJmZC1leHRlbnNpb24ueWFu Zzo4OiB3YXJuaW5nOiBpbXBvcnRlZCBtb2R1bGUgaWV0Zi1pbmV0LXR5cGVzIG5vdCB1c2VkPGJy Pg0KbGltZS1iZmQtZXh0ZW5zaW9uLnlhbmc6MTM3OiBlcnJvcjogcHJlZml4ICZxdW90O2lmJnF1 b3Q7IGlzIG5vdCBkZWZpbmVkIChyZXBvcnRlZCBvbmx5IG9uY2UpPGJyPg0KaWV0Zi1nZW4tb2Ft Lnlhbmc6MTogZXJyb3I6IHVuZXhwZWN0ZWQgbW9kdWxlbmFtZSAmcXVvdDtpZXRmLXRyaWxsLW9h bSZxdW90OyBpbiBpZXRmLWdlbi1vYW0ueWFuZywgc2hvdWxkIGJlIGlldGYtZ2VuLW9hbTxicj4N Cjxicj4NCjx1PnB5YW5nIC0taWV0ZiBwcm9kdWNlczo8L3U+PGJyPg0KbGltZS1iZmQtZXh0ZW5z aW9uLnlhbmc6MTogd2FybmluZzogUkZDIDYwODc6IDQuMTogbm8gbW9kdWxlIG5hbWUgcHJlZml4 IHVzZWQsIHN1Z2dlc3QgaWV0Zi1saW1lLWJmZC1leHRlbnNpb248YnI+DQpsaW1lLWJmZC1leHRl bnNpb24ueWFuZzoxOiBlcnJvcjogUkZDIDYwODc6IDQuNzogc3RhdGVtZW50ICZxdW90O21vZHVs ZSZxdW90OyBtdXN0IGhhdmUgYSAmcXVvdDtjb250YWN0JnF1b3Q7IHN1YnN0YXRlbWVudDxicj4N CmxpbWUtYmZkLWV4dGVuc2lvbi55YW5nOjE6IGVycm9yOiBSRkMgNjA4NzogNC43OiBzdGF0ZW1l bnQgJnF1b3Q7bW9kdWxlJnF1b3Q7IG11c3QgaGF2ZSBhICZxdW90O29yZ2FuaXphdGlvbiZxdW90 OyBzdWJzdGF0ZW1lbnQ8YnI+DQpsaW1lLWJmZC1leHRlbnNpb24ueWFuZzoxOiBlcnJvcjogUkZD IDYwODc6IDQuNzogc3RhdGVtZW50ICZxdW90O21vZHVsZSZxdW90OyBtdXN0IGhhdmUgYSAmcXVv dDtkZXNjcmlwdGlvbiZxdW90OyBzdWJzdGF0ZW1lbnQ8YnI+DQpsaW1lLWJmZC1leHRlbnNpb24u eWFuZzo4OiB3YXJuaW5nOiBpbXBvcnRlZCBtb2R1bGUgaWV0Zi1pbmV0LXR5cGVzIG5vdCB1c2Vk PGJyPg0KbGltZS1iZmQtZXh0ZW5zaW9uLnlhbmc6MTQ6IGVycm9yOiBSRkMgNjA4NzogNC43OiBz dGF0ZW1lbnQgJnF1b3Q7cmV2aXNpb24mcXVvdDsgbXVzdCBoYXZlIGEgJnF1b3Q7cmVmZXJlbmNl JnF1b3Q7IHN1YnN0YXRlbWVudDxicj4NCmxpbWUtYmZkLWV4dGVuc2lvbi55YW5nOjc4OiBlcnJv cjogUkZDIDYwODc6IDQuMTI6IHN0YXRlbWVudCAmcXVvdDthdWdtZW50JnF1b3Q7IG11c3QgaGF2 ZSBhICZxdW90O2Rlc2NyaXB0aW9uJnF1b3Q7IHN1YnN0YXRlbWVudDxicj4NCmxpbWUtYmZkLWV4 dGVuc2lvbi55YW5nOjc5OiB3YXJuaW5nOiBSRkMgNjA4NzogNC4xMjogc3RhdGVtZW50ICZxdW90 O3doZW4mcXVvdDsgc2hvdWxkIGhhdmUgYSAmcXVvdDtkZXNjcmlwdGlvbiZxdW90OyBzdWJzdGF0 ZW1lbnQ8YnI+DQpsaW1lLWJmZC1leHRlbnNpb24ueWFuZzo4MDogZXJyb3I6IFJGQyA2MDg3OiA0 LjEyOiBzdGF0ZW1lbnQgJnF1b3Q7bGVhZiZxdW90OyBtdXN0IGhhdmUgYSAmcXVvdDtkZXNjcmlw dGlvbiZxdW90OyBzdWJzdGF0ZW1lbnQ8YnI+DQpsaW1lLWJmZC1leHRlbnNpb24ueWFuZzo4ODog ZXJyb3I6IFJGQyA2MDg3OiA0LjEyOiBzdGF0ZW1lbnQgJnF1b3Q7YXVnbWVudCZxdW90OyBtdXN0 IGhhdmUgYSAmcXVvdDtkZXNjcmlwdGlvbiZxdW90OyBzdWJzdGF0ZW1lbnQ8YnI+DQpsaW1lLWJm ZC1leHRlbnNpb24ueWFuZzo4OTogd2FybmluZzogUkZDIDYwODc6IDQuMTI6IHN0YXRlbWVudCAm cXVvdDt3aGVuJnF1b3Q7IHNob3VsZCBoYXZlIGEgJnF1b3Q7ZGVzY3JpcHRpb24mcXVvdDsgc3Vi c3RhdGVtZW50PGJyPg0KbGltZS1iZmQtZXh0ZW5zaW9uLnlhbmc6MTAyOiBlcnJvcjogUkZDIDYw ODc6IDQuMTI6IHN0YXRlbWVudCAmcXVvdDthdWdtZW50JnF1b3Q7IG11c3QgaGF2ZSBhICZxdW90 O2Rlc2NyaXB0aW9uJnF1b3Q7IHN1YnN0YXRlbWVudDxicj4NCmxpbWUtYmZkLWV4dGVuc2lvbi55 YW5nOjEwNDogd2FybmluZzogUkZDIDYwODc6IDQuMTI6IHN0YXRlbWVudCAmcXVvdDt3aGVuJnF1 b3Q7IHNob3VsZCBoYXZlIGEgJnF1b3Q7ZGVzY3JpcHRpb24mcXVvdDsgc3Vic3RhdGVtZW50PGJy Pg0KbGltZS1iZmQtZXh0ZW5zaW9uLnlhbmc6MTA5OiBlcnJvcjogUkZDIDYwODc6IDQuMTI6IHN0 YXRlbWVudCAmcXVvdDthdWdtZW50JnF1b3Q7IG11c3QgaGF2ZSBhICZxdW90O2Rlc2NyaXB0aW9u JnF1b3Q7IHN1YnN0YXRlbWVudDxicj4NCmxpbWUtYmZkLWV4dGVuc2lvbi55YW5nOjExMDogd2Fy bmluZzogUkZDIDYwODc6IDQuMTI6IHN0YXRlbWVudCAmcXVvdDt3aGVuJnF1b3Q7IHNob3VsZCBo YXZlIGEgJnF1b3Q7ZGVzY3JpcHRpb24mcXVvdDsgc3Vic3RhdGVtZW50PGJyPg0KbGltZS1iZmQt ZXh0ZW5zaW9uLnlhbmc6MTI3OiBlcnJvcjogUkZDIDYwODc6IDQuMTI6IHN0YXRlbWVudCAmcXVv dDthdWdtZW50JnF1b3Q7IG11c3QgaGF2ZSBhICZxdW90O2Rlc2NyaXB0aW9uJnF1b3Q7IHN1YnN0 YXRlbWVudDxicj4NCmxpbWUtYmZkLWV4dGVuc2lvbi55YW5nOjEyOTogd2FybmluZzogUkZDIDYw ODc6IDQuMTI6IHN0YXRlbWVudCAmcXVvdDt3aGVuJnF1b3Q7IHNob3VsZCBoYXZlIGEgJnF1b3Q7 ZGVzY3JpcHRpb24mcXVvdDsgc3Vic3RhdGVtZW50PGJyPg0KbGltZS1iZmQtZXh0ZW5zaW9uLnlh bmc6MTMzOiBlcnJvcjogUkZDIDYwODc6IDQuMTIsNC4xNDogc3RhdGVtZW50ICZxdW90O25vdGlm aWNhdGlvbiZxdW90OyBtdXN0IGhhdmUgYSAmcXVvdDtkZXNjcmlwdGlvbiZxdW90OyBzdWJzdGF0 ZW1lbnQ8YnI+DQpsaW1lLWJmZC1leHRlbnNpb24ueWFuZzoxMzc6IGVycm9yOiBwcmVmaXggJnF1 b3Q7aWYmcXVvdDsgaXMgbm90IGRlZmluZWQgKHJlcG9ydGVkIG9ubHkgb25jZSk8YnI+DQppZXRm LWdlbi1vYW0ueWFuZzoxOiBlcnJvcjogdW5leHBlY3RlZCBtb2R1bGVuYW1lICZxdW90O2lldGYt dHJpbGwtb2FtJnF1b3Q7IGluIGlldGYtZ2VuLW9hbS55YW5nLCBzaG91bGQgYmUgaWV0Zi1nZW4t b2FtPGJyPg0KPGJyPg0KTm90ZSB0aGF0IEkgY29tcGlsZSBhbGwgWUFORyBtb2RlbHMgZXh0cmFj dGVkIGZyb20gZHJhZnRzIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cuY2xhaXNlLmJlL0lFVEZZQU5H UGFnZUNvbXBpbGF0aW9uLmh0bWwiPg0KaHR0cDovL3d3dy5jbGFpc2UuYmUvSUVURllBTkdQYWdl Q29tcGlsYXRpb24uaHRtbDwvYT48YnI+DQo8YnI+DQpSZWdhcmRzLCBCZW5vaXQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E6BC9BBCBCACC246846FC685F9FF41EACA9E14szxeml501mbxchina_-- From nobody Sat Oct 31 21:21:56 2015 Return-Path: X-Original-To: lime@ietfa.amsl.com Delivered-To: lime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BB81B5B2E for ; Sat, 31 Oct 2015 21:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1YcRLrj1SL7e for ; Sat, 31 Oct 2015 21:06:40 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id C0DC11B5B23 for ; Sat, 31 Oct 2015 21:06:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A5F7E1E59F2 for ; Sat, 31 Oct 2015 21:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBTvJpGZwPqU for ; Sat, 31 Oct 2015 21:06:14 -0700 (PDT) Received: from t20010c400000302489c1b291c06da7b2.v6.meeting.ietf94.jp (t20010c400000302489c1b291c06da7b2.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:89c1:b291:c06d:a7b2]) by c8a.amsl.com (Postfix) with ESMTPA id 5DBFF1E59F1 for ; Sat, 31 Oct 2015 21:06:14 -0700 (PDT) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sat, 31 Oct 2015 21:06:49 -0700 Message-Id: To: lime@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Sat, 31 Oct 2015 21:06:49 -0700 X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 21:21:55 -0700 Subject: [Lime] Virtual Queue for LIME Remote Attendees X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 04:06:42 -0000 If you are planning to participate in the LIME session here at IETF 94 = on Monday =97 either locally in Prague or as a remote participant =97 we = want to make sure that you are aware that the IETF is providing a remote = participants with a fairly new way to ask questions or make comments. In = addition to using the Jabber room, for the LIME session there is also = the opportunity for remote participants to enter a virtual queue and ask = questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the LIME session =97 a virtual queue and an actual (in-room) queue. = Remote attendees will log into the Meetecho platform and will have a = virtual mic line that they can enter if they have a question or comment. = In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com