From nobody Wed Mar 4 21:32:19 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 0DD2D1AD364 for ; Wed, 4 Mar 2015 21:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 zEFsfirSfEnv for ; Wed, 4 Mar 2015 21:32:16 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73581AD363 for ; Wed, 4 Mar 2015 21:32:16 -0800 (PST) Received: from [172.22.243.167] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t255WCC0002141 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Mar 2015 21:32:13 -0800 Message-ID: <54F7EA5C.1040904@acm.org> Date: Wed, 04 Mar 2015 21:32:12 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: lime@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYBLKZEIaBkTHGVSTHKc184LtLQ9aP2Fc0OYUXe0SiOfgPRJKN/I5VFP5QYyttMYn6mhlN87hiWct4X3EsXs44e X-Sonic-ID: C;1lTj+fjC5BGPzr5YxQPdhw== M;CjMI+vjC5BGPzr5YxQPdhw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: [Lime] Layer-transcending OAM? 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, 05 Mar 2015 05:32:18 -0000 This draft makes 3 points: - we shouldn't hard-code a policy of layer isolation as we think about OAM for NVO3 and other encapsulations - NVO3 encaps might consider enabling the ttl behavior which enables this form of traceroute - this is easy for VXLAN encapsulation - needs a bit in the VXLAN header The first point is relevant to the OAM architecture and model discussion in LIME. In Honolulu there were comments at the mike about thinking about the Internet OAM model in addition to the Ethernet OAM model, and I think this property of traceroute is part of the Internet OAM model. I hope that first point can trigger some discussion about the model in LIME. Thanks, Erik -------- Forwarded Message -------- Subject: New Version Notification for draft-nordmark-nvo3-transcending-traceroute-00.txt Date: Wed, 04 Mar 2015 18:48:12 -0800 From: internet-drafts@ietf.org To: Chandra Appanna , Erik Nordmark , Alton Lo , Alton Lo , Erik Nordmark , Chandra Appanna A new version of I-D, draft-nordmark-nvo3-transcending-traceroute-00.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Name: draft-nordmark-nvo3-transcending-traceroute Revision: 00 Title: Layer-Transcending Traceroute for Overlay Networks like VXLAN Document date: 2015-03-02 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcending-traceroute-00.txt Status: https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-traceroute/ Htmlized: http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-00 Abstract: Tools like traceroute have been very valuable for the operation of the Internet. Part of that value comes from being able to display information about routers and paths over which the user of the tool has no control, but the traceroute output can be passed along to someone else that can further investigate or fix the problem. In overlay networks such as VXLAN and NVGRE the prevailing view is that since the overlay network has no control of the underlay there needs to be special tools and agreements to enable extracting traces from the underlay. We argue that enabling visibility into the underlay and using existing tools like traceroute has been overlooked and would add value in many deployments of overlay networks. This document specifies an approach that can be used to make traceroute transcend layers of encapsulation including details for how to apply this to VXLAN. The technique can be applied to other encapsulations used for overlay networks. It can also be implemented using current commercial silicon. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Mar 5 07:22:20 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 543EA1A0470 for ; Thu, 5 Mar 2015 07:22:19 -0800 (PST) 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 2FKSSLDkkKoP for ; Thu, 5 Mar 2015 07:22:17 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C6C1A01F0 for ; Thu, 5 Mar 2015 07:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3777; q=dns/txt; s=iport; t=1425568788; x=1426778388; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=mqma0HxELC4PGv4uI3tKsZ/VZxJgyE+kTSJc6zx8HLo=; b=bLm849CuqXPFtu3IvL+mgrCU4hmkkbQjGvCRY/mPd2A0Zf985Lwqwvzt THv7E/8kZYvc3Pq/68M1etoqzK68i5xwATpki/Qj5pV4gRjypxj5lEFsH 8fFhy35jpprVZTMlFymDJ9N+hNkS3QZKc7M9iJvxJO3mJszrnZ5+JlSL9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQC8c/hU/5hdJa1agwZSWgTBKAyFbwKBNk0BAQEBAQF8hA8BAQEEAQEBNzQdAQgRAQIBAh83CxcGCAIEARIJiCYN12IBAQEBAQEBAQIBAQEBAQEBARqLFIR1BoQlBZAFg2OFaoEaOYJtjywjg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,347,1422921600"; d="scan'208";a="401158193" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 05 Mar 2015 15:19:47 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t25FJlSf018491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 15:19:47 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.192]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 09:19:47 -0600 From: "Deepak Kumar (dekumar)" To: Erik Nordmark , "lime@ietf.org" Thread-Topic: [Lime] Layer-transcending OAM? Thread-Index: AQHQVwXK5Kzv++tF8k+69WWjNNql950N4AyA Date: Thu, 5 Mar 2015 15:19:46 +0000 Message-ID: In-Reply-To: <54F7EA5C.1040904@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.24.73.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <186E1E112D5D2840BA678EE022428647@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 05 Mar 2015 15:22:19 -0000 Hi Erik, Generic Yang draft for OAM is for Management and it's not enforcing or proposing strict layering, filtering model. It's bringing concept of Data Model from Ethernet OAM but adding IP specifics for Multipath support. Also it's providing way for operator to go over OAM data hierarchy if present. Thanks, Deepak On 3/4/15 9:32 PM, "Erik Nordmark" wrote: > >This draft makes 3 points: > - we shouldn't hard-code a policy of layer isolation as we think about >OAM for NVO3 and other encapsulations > - NVO3 encaps might consider enabling the ttl behavior which enables >this form of traceroute > - this is easy for VXLAN encapsulation - needs a bit in the VXLAN header > >The first point is relevant to the OAM architecture and model discussion >in LIME. >In Honolulu there were comments at the mike about thinking about the >Internet OAM model in addition to the Ethernet OAM model, and I think >this property of traceroute is part of the Internet OAM model. > >I hope that first point can trigger some discussion about the model in >LIME. > >Thanks, > Erik > > > > >-------- Forwarded Message -------- >Subject: New Version Notification for >draft-nordmark-nvo3-transcending-traceroute-00.txt >Date: Wed, 04 Mar 2015 18:48:12 -0800 >From: internet-drafts@ietf.org >To: Chandra Appanna , Erik Nordmark >, Alton Lo , Alton Lo >, Erik Nordmark , Chandra >Appanna > > > >A new version of I-D, draft-nordmark-nvo3-transcending-traceroute-00.txt >has been successfully submitted by Erik Nordmark and posted to the >IETF repository. > >Name: draft-nordmark-nvo3-transcending-traceroute >Revision: 00 >Title: Layer-Transcending Traceroute for Overlay Networks like VXLAN >Document date: 2015-03-02 >Group: Individual Submission >Pages: 18 >URL: =20 >http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcending-trace >route-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-tracerou >te/ >Htmlized: =20 >http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-00 > > >Abstract: > Tools like traceroute have been very valuable for the operation of > the Internet. Part of that value comes from being able to display > information about routers and paths over which the user of the tool > has no control, but the traceroute output can be passed along to > someone else that can further investigate or fix the problem. > > In overlay networks such as VXLAN and NVGRE the prevailing view is > that since the overlay network has no control of the underlay there > needs to be special tools and agreements to enable extracting traces > from the underlay. We argue that enabling visibility into the > underlay and using existing tools like traceroute has been overlooked > and would add value in many deployments of overlay networks. > > This document specifies an approach that can be used to make > traceroute transcend layers of encapsulation including details for > how to apply this to VXLAN. The technique can be applied to other > encapsulations used for overlay networks. It can also be implemented > using current commercial silicon. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > >_______________________________________________ >Lime mailing list >Lime@ietf.org >https://www.ietf.org/mailman/listinfo/lime From nobody Thu Mar 5 15:35:10 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 7A79A1A9073 for ; Thu, 5 Mar 2015 15:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 qSiJ7JrNz0hW for ; Thu, 5 Mar 2015 15:35:01 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7991A897A for ; Thu, 5 Mar 2015 15:35:01 -0800 (PST) Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t25NYw6p022284 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Mar 2015 15:34:58 -0800 Message-ID: <54F8E822.5070409@acm.org> Date: Thu, 05 Mar 2015 15:34:58 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Deepak Kumar (dekumar)" , Erik Nordmark , "lime@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVb4Q9EFq18mshfowDhJLXT4NXdpU6GAE8l9W/TQDqYCzlGWk52YnE0D24UpYy/m+4jud8k4hAFiZhPKrmDSoO5b X-Sonic-ID: C;anM4PJDD5BG3m75YxQPdhw== M;wmNUPJDD5BG3m75YxQPdhw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 05 Mar 2015 23:35:09 -0000 On 3/5/15 7:19 AM, Deepak Kumar (dekumar) wrote: > Hi Erik, > > Generic Yang draft for OAM is for Management and it's not enforcing or > proposing strict layering, filtering model. It's bringing concept of Data > Model from Ethernet OAM but adding IP specifics for Multipath support. > Also it's providing way for operator to go over OAM data hierarchy if > present. Deepak, I haven't looked carefully at the Yang model draft to see whether it actually *prevents* layer-trancendence, but from the architecture/model discussion in Honolulu (that Norm presented) I got the impression that the layers are completely isolated. If the Yang draft wants to *enable* layer-trancendence, then I suspect it needs to have a way to configure the ttl behavior at the tunnel endpoints to be able to select between the pipe and uniform ttl tunnel models. Thus I think the LIME WG should discuss this part of the OAM model. Regards, Erik > > Thanks, > Deepak > > On 3/4/15 9:32 PM, "Erik Nordmark" wrote: > >> This draft makes 3 points: >> - we shouldn't hard-code a policy of layer isolation as we think about >> OAM for NVO3 and other encapsulations >> - NVO3 encaps might consider enabling the ttl behavior which enables >> this form of traceroute >> - this is easy for VXLAN encapsulation - needs a bit in the VXLAN header >> >> The first point is relevant to the OAM architecture and model discussion >> in LIME. >> In Honolulu there were comments at the mike about thinking about the >> Internet OAM model in addition to the Ethernet OAM model, and I think >> this property of traceroute is part of the Internet OAM model. >> >> I hope that first point can trigger some discussion about the model in >> LIME. >> >> Thanks, >> Erik >> >> >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for >> draft-nordmark-nvo3-transcending-traceroute-00.txt >> Date: Wed, 04 Mar 2015 18:48:12 -0800 >> From: internet-drafts@ietf.org >> To: Chandra Appanna , Erik Nordmark >> , Alton Lo , Alton Lo >> , Erik Nordmark , Chandra >> Appanna >> >> >> >> A new version of I-D, draft-nordmark-nvo3-transcending-traceroute-00.txt >> has been successfully submitted by Erik Nordmark and posted to the >> IETF repository. >> >> Name: draft-nordmark-nvo3-transcending-traceroute >> Revision: 00 >> Title: Layer-Transcending Traceroute for Overlay Networks like VXLAN >> Document date: 2015-03-02 >> Group: Individual Submission >> Pages: 18 >> URL: >> http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcending-trace >> route-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-tracerou >> te/ >> Htmlized: >> http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-00 >> >> >> Abstract: >> Tools like traceroute have been very valuable for the operation of >> the Internet. Part of that value comes from being able to display >> information about routers and paths over which the user of the tool >> has no control, but the traceroute output can be passed along to >> someone else that can further investigate or fix the problem. >> >> In overlay networks such as VXLAN and NVGRE the prevailing view is >> that since the overlay network has no control of the underlay there >> needs to be special tools and agreements to enable extracting traces >> from the underlay. We argue that enabling visibility into the >> underlay and using existing tools like traceroute has been overlooked >> and would add value in many deployments of overlay networks. >> >> This document specifies an approach that can be used to make >> traceroute transcend layers of encapsulation including details for >> how to apply this to VXLAN. The technique can be applied to other >> encapsulations used for overlay networks. It can also be implemented >> using current commercial silicon. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> Lime mailing list >> Lime@ietf.org >> https://www.ietf.org/mailman/listinfo/lime > From nobody Thu Mar 5 20:56:53 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 331961AC43B for ; Thu, 5 Mar 2015 20:56:52 -0800 (PST) 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 uj6De015FnCw for ; Thu, 5 Mar 2015 20:56:49 -0800 (PST) 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 1DEED1AC438 for ; Thu, 5 Mar 2015 20:56:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTI37946; Fri, 06 Mar 2015 04:56:47 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Mar 2015 04:56:46 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 6 Mar 2015 12:56:43 +0800 From: Qin Wu To: Erik Nordmark , "lime@ietf.org" Thread-Topic: [Lime] Layer-transcending OAM? Thread-Index: AQHQVwXNeQ4e+LfhO0uyMkw2Sb1ZV50O3/MA Date: Fri, 6 Mar 2015 04:56:42 +0000 Message-ID: References: <54F7EA5C.1040904@acm.org> In-Reply-To: <54F7EA5C.1040904@acm.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 06 Mar 2015 04:56:52 -0000 SGk6DQpTaW5jZSBpdCBpcyByZWxldmFudCB0byB0aGUgT0FNIGFyY2hpdGVjdHVyZSBhbmQgbW9k ZWwgZGlzY3Vzc2lvbiBpbiBMSU1FLCBpdCB3b3VsZCBiZSBuaWNlIGFuZCBmYWlyIHRvIGNpdGUN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lZHByb3Atb3BzYXdnLW11bHRpLWxh eWVyLW9hbS1wcy0wMA0KDQpMSU1FIG1vZGVsIGlzIGEgZ2VuZXJpYyBtb2RlbCBpbiB0aGUgbWFu YWdlbWVudCBwbGFuZS4NCkxJTUUgbW9kZWwgc2hvdWxkIHdvcmsgaXJyZXNwZWN0aXZlIG9mIGxh eWVyIGJlaW5nIGhvbm9yZWQgb3IgYmVpbmcgcmVsYXhlZC4NCkxJTUUgbW9kZWwgc2hvdWxkIHdv cmsgaW5kZXBlbmRlbnQgb2YgZGF0YSBwbGFuZSBPQU0gcHJvdG9jb2xzIGluIGRpZmZlcmVudCBw b3J0aW9ucyBvZiB0aGUgbmV0d29yayB1c2luZyB2YXJpb3VzIHRyYW5zcG9ydCB0ZWNobm9sb2dp ZXMuDQpBbnkgZGF0YSBwbGFuZSBPQU0gcHJvdG9jb2wgZXh0ZW5zaW9uIGlzIG5vdCBpbiB0aGUg c2NvcGUgb2YgTElNRSBXRy4gSSB0aGluayBsYXllci10cmFuc2NlbmRpbmcgdHJhY2Vyb3V0ZSBp cyBkYXRhIHBsYW5lIE9BTSBwcm90b2NvbCBleHRlbnNpb24uDQoNClJlZ2FyZHMhDQotUWluDQot LS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTGltZSBbbWFpbHRvOmxpbWUtYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBFcmlrIE5vcmRtYXJrDQq3osvNyrG85DogMjAxNcTqM9TCNcjVIDEzOjMyDQrK 1bz+yMs6IGxpbWVAaWV0Zi5vcmcNCtb3zOI6IFtMaW1lXSBMYXllci10cmFuc2NlbmRpbmcgT0FN Pw0KDQoNClRoaXMgZHJhZnQgbWFrZXMgMyBwb2ludHM6DQogIC0gd2Ugc2hvdWxkbid0IGhhcmQt Y29kZSBhIHBvbGljeSBvZiBsYXllciBpc29sYXRpb24gYXMgd2UgdGhpbmsgYWJvdXQgT0FNIGZv ciBOVk8zIGFuZCBvdGhlciBlbmNhcHN1bGF0aW9ucw0KICAtIE5WTzMgZW5jYXBzIG1pZ2h0IGNv bnNpZGVyIGVuYWJsaW5nIHRoZSB0dGwgYmVoYXZpb3Igd2hpY2ggZW5hYmxlcyB0aGlzIGZvcm0g b2YgdHJhY2Vyb3V0ZQ0KICAtIHRoaXMgaXMgZWFzeSBmb3IgVlhMQU4gZW5jYXBzdWxhdGlvbiAt IG5lZWRzIGEgYml0IGluIHRoZSBWWExBTiBoZWFkZXINCg0KVGhlIGZpcnN0IHBvaW50IGlzIHJl bGV2YW50IHRvIHRoZSBPQU0gYXJjaGl0ZWN0dXJlIGFuZCBtb2RlbCBkaXNjdXNzaW9uIGluIExJ TUUuDQpJbiBIb25vbHVsdSB0aGVyZSB3ZXJlIGNvbW1lbnRzIGF0IHRoZSBtaWtlIGFib3V0IHRo aW5raW5nIGFib3V0IHRoZSBJbnRlcm5ldCBPQU0gbW9kZWwgaW4gYWRkaXRpb24gdG8gdGhlIEV0 aGVybmV0IE9BTSBtb2RlbCwgYW5kIEkgdGhpbmsgdGhpcyBwcm9wZXJ0eSBvZiB0cmFjZXJvdXRl IGlzIHBhcnQgb2YgdGhlIEludGVybmV0IE9BTSBtb2RlbC4NCg0KSSBob3BlIHRoYXQgZmlyc3Qg cG9pbnQgY2FuIHRyaWdnZXIgc29tZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBtb2RlbCBpbiBMSU1F Lg0KDQpUaGFua3MsDQogIEVyaWsNCg0KDQoNCg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2Ug LS0tLS0tLS0NClN1YmplY3Q6IAlOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KZHJhZnQt bm9yZG1hcmstbnZvMy10cmFuc2NlbmRpbmctdHJhY2Vyb3V0ZS0wMC50eHQNCkRhdGU6IAlXZWQs IDA0IE1hciAyMDE1IDE4OjQ4OjEyIC0wODAwDQpGcm9tOiAJaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnDQpUbzogCUNoYW5kcmEgQXBwYW5uYSA8YWNoYW5kcmFAYXJpc3RhLmNvbT4sIEVyaWsgTm9y ZG1hcmsgDQo8bm9yZG1hcmtAYXJpc3RhLmNvbT4sIEFsdG9uIExvIDxhbHRvbmxvQGFyaXN0YS5j b20+LCBBbHRvbiBMbyA8YWx0b25sb0BhcmlzdGEuY29tPiwgRXJpayBOb3JkbWFyayA8bm9yZG1h cmtAYXJpc3RhLmNvbT4sIENoYW5kcmEgQXBwYW5uYSA8YWNoYW5kcmFAYXJpc3RhLmNvbT4NCg0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ub3JkbWFyay1udm8zLXRyYW5zY2VuZGlu Zy10cmFjZXJvdXRlLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBF cmlrIE5vcmRtYXJrIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJ CWRyYWZ0LW5vcmRtYXJrLW52bzMtdHJhbnNjZW5kaW5nLXRyYWNlcm91dGUNClJldmlzaW9uOgkw MA0KVGl0bGU6CQlMYXllci1UcmFuc2NlbmRpbmcgVHJhY2Vyb3V0ZSBmb3IgT3ZlcmxheSBOZXR3 b3JrcyBsaWtlIFZYTEFODQpEb2N1bWVudCBkYXRlOgkyMDE1LTAzLTAyDQpHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxOA0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5vcmRtYXJrLW52bzMtdHJhbnNjZW5kaW5n LXRyYWNlcm91dGUtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbm9yZG1hcmstbnZvMy10cmFuc2NlbmRpbmctdHJhY2Vyb3V0ZS8N Ckh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ub3JkbWFy ay1udm8zLXRyYW5zY2VuZGluZy10cmFjZXJvdXRlLTAwDQoNCg0KQWJzdHJhY3Q6DQogICAgVG9v bHMgbGlrZSB0cmFjZXJvdXRlIGhhdmUgYmVlbiB2ZXJ5IHZhbHVhYmxlIGZvciB0aGUgb3BlcmF0 aW9uIG9mDQogICAgdGhlIEludGVybmV0LiAgUGFydCBvZiB0aGF0IHZhbHVlIGNvbWVzIGZyb20g YmVpbmcgYWJsZSB0byBkaXNwbGF5DQogICAgaW5mb3JtYXRpb24gYWJvdXQgcm91dGVycyBhbmQg cGF0aHMgb3ZlciB3aGljaCB0aGUgdXNlciBvZiB0aGUgdG9vbA0KICAgIGhhcyBubyBjb250cm9s LCBidXQgdGhlIHRyYWNlcm91dGUgb3V0cHV0IGNhbiBiZSBwYXNzZWQgYWxvbmcgdG8NCiAgICBz b21lb25lIGVsc2UgdGhhdCBjYW4gZnVydGhlciBpbnZlc3RpZ2F0ZSBvciBmaXggdGhlIHByb2Js ZW0uDQoNCiAgICBJbiBvdmVybGF5IG5ldHdvcmtzIHN1Y2ggYXMgVlhMQU4gYW5kIE5WR1JFIHRo ZSBwcmV2YWlsaW5nIHZpZXcgaXMNCiAgICB0aGF0IHNpbmNlIHRoZSBvdmVybGF5IG5ldHdvcmsg aGFzIG5vIGNvbnRyb2wgb2YgdGhlIHVuZGVybGF5IHRoZXJlDQogICAgbmVlZHMgdG8gYmUgc3Bl Y2lhbCB0b29scyBhbmQgYWdyZWVtZW50cyB0byBlbmFibGUgZXh0cmFjdGluZyB0cmFjZXMNCiAg ICBmcm9tIHRoZSB1bmRlcmxheS4gIFdlIGFyZ3VlIHRoYXQgZW5hYmxpbmcgdmlzaWJpbGl0eSBp bnRvIHRoZQ0KICAgIHVuZGVybGF5IGFuZCB1c2luZyBleGlzdGluZyB0b29scyBsaWtlIHRyYWNl cm91dGUgaGFzIGJlZW4gb3Zlcmxvb2tlZA0KICAgIGFuZCB3b3VsZCBhZGQgdmFsdWUgaW4gbWFu eSBkZXBsb3ltZW50cyBvZiBvdmVybGF5IG5ldHdvcmtzLg0KDQogICAgVGhpcyBkb2N1bWVudCBz cGVjaWZpZXMgYW4gYXBwcm9hY2ggdGhhdCBjYW4gYmUgdXNlZCB0byBtYWtlDQogICAgdHJhY2Vy b3V0ZSB0cmFuc2NlbmQgbGF5ZXJzIG9mIGVuY2Fwc3VsYXRpb24gaW5jbHVkaW5nIGRldGFpbHMg Zm9yDQogICAgaG93IHRvIGFwcGx5IHRoaXMgdG8gVlhMQU4uICBUaGUgdGVjaG5pcXVlIGNhbiBi ZSBhcHBsaWVkIHRvIG90aGVyDQogICAgZW5jYXBzdWxhdGlvbnMgdXNlZCBmb3Igb3ZlcmxheSBu ZXR3b3Jrcy4gIEl0IGNhbiBhbHNvIGJlIGltcGxlbWVudGVkDQogICAgdXNpbmcgY3VycmVudCBj b21tZXJjaWFsIHNpbGljb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMaW1lIG1h aWxpbmcgbGlzdA0KTGltZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9saW1lDQo= From nobody Thu Mar 5 21:37:23 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 C76DF1ACC72 for ; Thu, 5 Mar 2015 21:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I5Gu8aS0-tv7 for ; Thu, 5 Mar 2015 21:37:20 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAEE1ACAD8 for ; Thu, 5 Mar 2015 21:37:20 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.191.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A1F18180145E; Fri, 6 Mar 2015 06:37:17 +0100 (CET) Message-ID: <54F93D07.6000807@pi.nu> Date: Fri, 06 Mar 2015 13:37:11 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Erik Nordmark , "lime@ietf.org" References: <54F8E822.5070409@acm.org> In-Reply-To: <54F8E822.5070409@acm.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 06 Mar 2015 05:37:22 -0000 Erik, et.al., While I agree that it is proper for the LIME working group to discuss this, the decision to create Layer-transcending OAM is not entirely up to LIME. "Generic" has the implication - "for everyone to use". If you are doing things for others to use you need to be sure that the intended users actually want and need what you are proposing, and that it does not cause problems for one data plane if another uses your generic model. /Loa On 2015-03-06 07:34, Erik Nordmark wrote: > On 3/5/15 7:19 AM, Deepak Kumar (dekumar) wrote: >> Hi Erik, >> >> Generic Yang draft for OAM is for Management and it's not enforcing or >> proposing strict layering, filtering model. It's bringing concept of Data >> Model from Ethernet OAM but adding IP specifics for Multipath support. >> Also it's providing way for operator to go over OAM data hierarchy if >> present. > > Deepak, > > I haven't looked carefully at the Yang model draft to see whether it > actually *prevents* layer-trancendence, but from the architecture/model > discussion in Honolulu (that Norm presented) I got the impression that > the layers are completely isolated. > > If the Yang draft wants to *enable* layer-trancendence, then I suspect > it needs to have a way to configure the ttl behavior at the tunnel > endpoints to be able to select between the pipe and uniform ttl tunnel > models. > > Thus I think the LIME WG should discuss this part of the OAM model. > > Regards, > Erik > > >> >> Thanks, >> Deepak >> >> On 3/4/15 9:32 PM, "Erik Nordmark" wrote: >> >>> This draft makes 3 points: >>> - we shouldn't hard-code a policy of layer isolation as we think about >>> OAM for NVO3 and other encapsulations >>> - NVO3 encaps might consider enabling the ttl behavior which enables >>> this form of traceroute >>> - this is easy for VXLAN encapsulation - needs a bit in the VXLAN >>> header >>> >>> The first point is relevant to the OAM architecture and model discussion >>> in LIME. >>> In Honolulu there were comments at the mike about thinking about the >>> Internet OAM model in addition to the Ethernet OAM model, and I think >>> this property of traceroute is part of the Internet OAM model. >>> >>> I hope that first point can trigger some discussion about the model in >>> LIME. >>> >>> Thanks, >>> Erik >>> >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for >>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>> Date: Wed, 04 Mar 2015 18:48:12 -0800 >>> From: internet-drafts@ietf.org >>> To: Chandra Appanna , Erik Nordmark >>> , Alton Lo , Alton Lo >>> , Erik Nordmark , Chandra >>> Appanna >>> >>> >>> >>> A new version of I-D, draft-nordmark-nvo3-transcending-traceroute-00.txt >>> has been successfully submitted by Erik Nordmark and posted to the >>> IETF repository. >>> >>> Name: draft-nordmark-nvo3-transcending-traceroute >>> Revision: 00 >>> Title: Layer-Transcending Traceroute for Overlay Networks like >>> VXLAN >>> Document date: 2015-03-02 >>> Group: Individual Submission >>> Pages: 18 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcending-trace >>> >>> route-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-tracerou >>> >>> te/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-00 >>> >>> >>> >>> Abstract: >>> Tools like traceroute have been very valuable for the operation of >>> the Internet. Part of that value comes from being able to display >>> information about routers and paths over which the user of the tool >>> has no control, but the traceroute output can be passed along to >>> someone else that can further investigate or fix the problem. >>> >>> In overlay networks such as VXLAN and NVGRE the prevailing view is >>> that since the overlay network has no control of the underlay there >>> needs to be special tools and agreements to enable extracting traces >>> from the underlay. We argue that enabling visibility into the >>> underlay and using existing tools like traceroute has been >>> overlooked >>> and would add value in many deployments of overlay networks. >>> >>> This document specifies an approach that can be used to make >>> traceroute transcend layers of encapsulation including details for >>> how to apply this to VXLAN. The technique can be applied to other >>> encapsulations used for overlay networks. It can also be >>> implemented >>> using current commercial silicon. >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> _______________________________________________ >>> Lime mailing list >>> Lime@ietf.org >>> https://www.ietf.org/mailman/listinfo/lime >> > > _______________________________________________ > Lime mailing list > Lime@ietf.org > https://www.ietf.org/mailman/listinfo/lime -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Mar 5 22:08:14 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 3619A1ACCDC for ; Thu, 5 Mar 2015 22:08:13 -0800 (PST) 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 yps86vl2o_Ik for ; Thu, 5 Mar 2015 22:08:10 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125D51ACCE5 for ; Thu, 5 Mar 2015 22:08:10 -0800 (PST) X-AuditID: c6180641-f796f6d000004ccc-2e-54f8e353844b Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E4.04.19660.353E8F45; Fri, 6 Mar 2015 00:14:28 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Fri, 6 Mar 2015 01:08:07 -0500 From: Gregory Mirsky To: Loa Andersson , Erik Nordmark , "lime@ietf.org" Thread-Topic: [Lime] Layer-transcending OAM? Thread-Index: AQHQVwXLRRvcWNNCPU6BNhDfBcjPMJ0OVWYAgACKWwCAAGU0gP//s4sw Date: Fri, 6 Mar 2015 06:08:06 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B91B4AB@eusaamb103.ericsson.se> References: <54F8E822.5070409@acm.org> <54F93D07.6000807@pi.nu> In-Reply-To: <54F93D07.6000807@pi.nu> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXSPt27I4x8hBkfuc1l0bNvOZPFv7hxm i/6pO5kcmD0uX/H2WLLkJ5PHrOltbAHMUVw2Kak5mWWpRfp2CVwZz26cZS1oMKro+TqBqYHx rXoXIyeHhICJxPfZs5ghbDGJC/fWs3UxcnEICRxhlFjWtogJJCEksIxRYvdEAxCbTcBI4sXG HnYQW0QgSeLttmawGmEBbYmLuy4wQcR1JJ5N+wRV4yZxdONOIJuDg0VARaLjbSFImFfAV2LC v1ZWiPEpEmv75zCDlHAKqErsa9UACTMCnfP91BqwicwC4hK3nsxngjhTQGLJnvNQJ4tKvHz8 jxXCVpL4+Hs+O0S9jsSC3Z/YIGxtiWULXzNDrBWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZ VjFylBanluWmGxluYgTGxjEJNscdjAs+WR5iFOBgVOLh/XD/R4gQa2JZcWXuIUZpDhYlcd6y KwdDhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBOnvDHz1SThzcrxloge07Vt3zJrcqubbvM X3Jvrpi5Nzdyxse7PXoZwtO+b1u+kiFmwdWA7EqjleECSglaLHJmK8q/V/4NM7d9/CFHwI/Z 2f/So/evp6c9jsyzVN35rkTUNHx3yPfOl8JnE+cftBDctslKs0w4NKfz56LTFm1d85sPmzr/ 7FNiKc5INNRiLipOBACZ6TsybgIAAA== Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 06 Mar 2015 06:08:13 -0000 Dear All, I think it is worth to point that after meeting in Honolulu the LIME WG for= med the Design Team to investigate whether there indeed are sufficient comm= onality among several OAM models in IETF domain - IP, IP/MPLS, MPLS-TP, TRI= LL. The document you reference yet not been adopted by the LIME WG and till= then is individual draft. Regards, Greg -----Original Message----- From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, March 05, 2015 9:37 PM To: Erik Nordmark; lime@ietf.org Subject: Re: [Lime] Layer-transcending OAM? Erik, et.al., While I agree that it is proper for the LIME working group to discuss this,= the decision to create Layer-transcending OAM is not entirely up to LIME. "Generic" has the implication - "for everyone to use". If you are doing thi= ngs for others to use you need to be sure that the intended users actually = want and need what you are proposing, and that it does not cause problems f= or one data plane if another uses your generic model. /Loa On 2015-03-06 07:34, Erik Nordmark wrote: > On 3/5/15 7:19 AM, Deepak Kumar (dekumar) wrote: >> Hi Erik, >> >> Generic Yang draft for OAM is for Management and it's not enforcing=20 >> or proposing strict layering, filtering model. It's bringing concept=20 >> of Data Model from Ethernet OAM but adding IP specifics for Multipath su= pport. >> Also it's providing way for operator to go over OAM data hierarchy if=20 >> present. > > Deepak, > > I haven't looked carefully at the Yang model draft to see whether it=20 > actually *prevents* layer-trancendence, but from the=20 > architecture/model discussion in Honolulu (that Norm presented) I got=20 > the impression that the layers are completely isolated. > > If the Yang draft wants to *enable* layer-trancendence, then I suspect=20 > it needs to have a way to configure the ttl behavior at the tunnel=20 > endpoints to be able to select between the pipe and uniform ttl tunnel=20 > models. > > Thus I think the LIME WG should discuss this part of the OAM model. > > Regards, > Erik > > >> >> Thanks, >> Deepak >> >> On 3/4/15 9:32 PM, "Erik Nordmark" wrote: >> >>> This draft makes 3 points: >>> - we shouldn't hard-code a policy of layer isolation as we think=20 >>> about OAM for NVO3 and other encapsulations >>> - NVO3 encaps might consider enabling the ttl behavior which=20 >>> enables this form of traceroute >>> - this is easy for VXLAN encapsulation - needs a bit in the VXLAN=20 >>> header >>> >>> The first point is relevant to the OAM architecture and model=20 >>> discussion in LIME. >>> In Honolulu there were comments at the mike about thinking about the=20 >>> Internet OAM model in addition to the Ethernet OAM model, and I=20 >>> think this property of traceroute is part of the Internet OAM model. >>> >>> I hope that first point can trigger some discussion about the model=20 >>> in LIME. >>> >>> Thanks, >>> Erik >>> >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for >>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>> Date: Wed, 04 Mar 2015 18:48:12 -0800 >>> From: internet-drafts@ietf.org >>> To: Chandra Appanna , Erik Nordmark >>> , Alton Lo , Alton Lo=20 >>> , Erik Nordmark , Chandra=20 >>> Appanna >>> >>> >>> >>> A new version of I-D,=20 >>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>> has been successfully submitted by Erik Nordmark and posted to the=20 >>> IETF repository. >>> >>> Name: draft-nordmark-nvo3-transcending-traceroute >>> Revision: 00 >>> Title: Layer-Transcending Traceroute for Overlay Networks like >>> VXLAN >>> Document date: 2015-03-02 >>> Group: Individual Submission >>> Pages: 18 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcending >>> -trace >>> >>> route-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-tr >>> acerou >>> >>> te/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-tracerou >>> te-00 >>> >>> >>> >>> Abstract: >>> Tools like traceroute have been very valuable for the operation of >>> the Internet. Part of that value comes from being able to display >>> information about routers and paths over which the user of the tool >>> has no control, but the traceroute output can be passed along to >>> someone else that can further investigate or fix the problem. >>> >>> In overlay networks such as VXLAN and NVGRE the prevailing view is >>> that since the overlay network has no control of the underlay there >>> needs to be special tools and agreements to enable extracting trace= s >>> from the underlay. We argue that enabling visibility into the >>> underlay and using existing tools like traceroute has been=20 >>> overlooked >>> and would add value in many deployments of overlay networks. >>> >>> This document specifies an approach that can be used to make >>> traceroute transcend layers of encapsulation including details for >>> how to apply this to VXLAN. The technique can be applied to other >>> encapsulations used for overlay networks. It can also be=20 >>> implemented >>> using current commercial silicon. >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of=20 >>> submission until the htmlized version and diff are available at=20 >>> tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> _______________________________________________ >>> Lime mailing list >>> Lime@ietf.org >>> https://www.ietf.org/mailman/listinfo/lime >> > > _______________________________________________ > Lime mailing list > Lime@ietf.org > https://www.ietf.org/mailman/listinfo/lime --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ Lime mailing list Lime@ietf.org https://www.ietf.org/mailman/listinfo/lime From nobody Thu Mar 5 22:15: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 384E81ACCDC for ; Thu, 5 Mar 2015 22:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YWAuM6mAw0hL for ; Thu, 5 Mar 2015 22:15:12 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E27D1ACCE1 for ; Thu, 5 Mar 2015 22:15:08 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.191.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 3F15F180145E; Fri, 6 Mar 2015 07:15:04 +0100 (CET) Message-ID: <54F945E3.3000300@pi.nu> Date: Fri, 06 Mar 2015 14:14:59 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gregory Mirsky , Erik Nordmark , "lime@ietf.org" References: <54F8E822.5070409@acm.org> <54F93D07.6000807@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91B4AB@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B91B4AB@eusaamb103.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 06 Mar 2015 06:15:15 -0000 Greg, does "sufficient commonality" mean that you intend to find a common way to do oam for different data planes, or does it mean that you intend to interwork oam for differernt data planes? /Loa On 2015-03-06 14:08, Gregory Mirsky wrote: > Dear All, > I think it is worth to point that after meeting in Honolulu the LIME WG formed the Design Team to investigate whether there indeed are sufficient commonality among several OAM models in IETF domain - IP, IP/MPLS, MPLS-TP, TRILL. The document you reference yet not been adopted by the LIME WG and till then is individual draft. > > Regards, > Greg > > -----Original Message----- > From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, March 05, 2015 9:37 PM > To: Erik Nordmark; lime@ietf.org > Subject: Re: [Lime] Layer-transcending OAM? > > Erik, et.al., > > While I agree that it is proper for the LIME working group to discuss this, the decision to create Layer-transcending OAM is not entirely up to LIME. > > "Generic" has the implication - "for everyone to use". If you are doing things for others to use you need to be sure that the intended users actually want and need what you are proposing, and that it does not cause problems for one data plane if another uses your generic model. > > /Loa > > On 2015-03-06 07:34, Erik Nordmark wrote: >> On 3/5/15 7:19 AM, Deepak Kumar (dekumar) wrote: >>> Hi Erik, >>> >>> Generic Yang draft for OAM is for Management and it's not enforcing >>> or proposing strict layering, filtering model. It's bringing concept >>> of Data Model from Ethernet OAM but adding IP specifics for Multipath support. >>> Also it's providing way for operator to go over OAM data hierarchy if >>> present. >> >> Deepak, >> >> I haven't looked carefully at the Yang model draft to see whether it >> actually *prevents* layer-trancendence, but from the >> architecture/model discussion in Honolulu (that Norm presented) I got >> the impression that the layers are completely isolated. >> >> If the Yang draft wants to *enable* layer-trancendence, then I suspect >> it needs to have a way to configure the ttl behavior at the tunnel >> endpoints to be able to select between the pipe and uniform ttl tunnel >> models. >> >> Thus I think the LIME WG should discuss this part of the OAM model. >> >> Regards, >> Erik >> >> >>> >>> Thanks, >>> Deepak >>> >>> On 3/4/15 9:32 PM, "Erik Nordmark" wrote: >>> >>>> This draft makes 3 points: >>>> - we shouldn't hard-code a policy of layer isolation as we think >>>> about OAM for NVO3 and other encapsulations >>>> - NVO3 encaps might consider enabling the ttl behavior which >>>> enables this form of traceroute >>>> - this is easy for VXLAN encapsulation - needs a bit in the VXLAN >>>> header >>>> >>>> The first point is relevant to the OAM architecture and model >>>> discussion in LIME. >>>> In Honolulu there were comments at the mike about thinking about the >>>> Internet OAM model in addition to the Ethernet OAM model, and I >>>> think this property of traceroute is part of the Internet OAM model. >>>> >>>> I hope that first point can trigger some discussion about the model >>>> in LIME. >>>> >>>> Thanks, >>>> Erik >>>> >>>> >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: New Version Notification for >>>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>>> Date: Wed, 04 Mar 2015 18:48:12 -0800 >>>> From: internet-drafts@ietf.org >>>> To: Chandra Appanna , Erik Nordmark >>>> , Alton Lo , Alton Lo >>>> , Erik Nordmark , Chandra >>>> Appanna >>>> >>>> >>>> >>>> A new version of I-D, >>>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>>> has been successfully submitted by Erik Nordmark and posted to the >>>> IETF repository. >>>> >>>> Name: draft-nordmark-nvo3-transcending-traceroute >>>> Revision: 00 >>>> Title: Layer-Transcending Traceroute for Overlay Networks like >>>> VXLAN >>>> Document date: 2015-03-02 >>>> Group: Individual Submission >>>> Pages: 18 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcending >>>> -trace >>>> >>>> route-00.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-tr >>>> acerou >>>> >>>> te/ >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-tracerou >>>> te-00 >>>> >>>> >>>> >>>> Abstract: >>>> Tools like traceroute have been very valuable for the operation of >>>> the Internet. Part of that value comes from being able to display >>>> information about routers and paths over which the user of the tool >>>> has no control, but the traceroute output can be passed along to >>>> someone else that can further investigate or fix the problem. >>>> >>>> In overlay networks such as VXLAN and NVGRE the prevailing view is >>>> that since the overlay network has no control of the underlay there >>>> needs to be special tools and agreements to enable extracting traces >>>> from the underlay. We argue that enabling visibility into the >>>> underlay and using existing tools like traceroute has been >>>> overlooked >>>> and would add value in many deployments of overlay networks. >>>> >>>> This document specifies an approach that can be used to make >>>> traceroute transcend layers of encapsulation including details for >>>> how to apply this to VXLAN. The technique can be applied to other >>>> encapsulations used for overlay networks. It can also be >>>> implemented >>>> using current commercial silicon. >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at >>>> tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> _______________________________________________ >>>> Lime mailing list >>>> Lime@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lime >>> >> >> _______________________________________________ >> Lime mailing list >> Lime@ietf.org >> https://www.ietf.org/mailman/listinfo/lime > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Mar 5 22:30:35 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 224371ACCE5 for ; Thu, 5 Mar 2015 22:30:35 -0800 (PST) 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 GUkVhIHZu6Ia for ; Thu, 5 Mar 2015 22:30:33 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C141ACCE1 for ; Thu, 5 Mar 2015 22:30:32 -0800 (PST) X-AuditID: c6180641-f796f6d000004ccc-02-54f8e8944631 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 42.54.19660.498E8F45; Fri, 6 Mar 2015 00:36:52 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Fri, 6 Mar 2015 01:30:31 -0500 From: Gregory Mirsky To: Loa Andersson , Erik Nordmark , "lime@ietf.org" Thread-Topic: [Lime] Layer-transcending OAM? Thread-Index: AQHQVwXLRRvcWNNCPU6BNhDfBcjPMJ0OVWYAgACKWwCAAGU0gP//s4swgABXBYD//67tAA== Date: Fri, 6 Mar 2015 06:30:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B91B4E4@eusaamb103.ericsson.se> References: <54F8E822.5070409@acm.org> <54F93D07.6000807@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91B4AB@eusaamb103.ericsson.se> <54F945E3.3000300@pi.nu> In-Reply-To: <54F945E3.3000300@pi.nu> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXSPn+6UFz9CDP5fUbTo2LadyeLf3DnM Fv1TdzI5MHtcvuLtsWTJTyaPWdPb2AKYo7hsUlJzMstSi/TtErgy7q9nLThgUXH+1Xv2Bsa3 Ol2MnBwSAiYSu/csYYKwxSQu3FvP1sXIxSEkcIRR4tK1XSwQzjJGiS/nelhBqtgEjCRebOxh B7FFBJIk3m5rBusWFtCWuLjrAhNEXEfi2bRPUDVhEnPe72cBsVkEVCQ6vjcygti8Ar4S+14c gFpwmFHiwMuXYAlOAVWJlUtfsYHYjEAnfT+1Bmwos4C4xK0n86FOFZBYsuc8M4QtKvHy8T9W CFtJ4uPv+ewQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnF yFFanFqWm25kuIkRGCHHJNgcdzAu+GR5iFGAg1GJh/fD/R8hQqyJZcWVuYcYpTlYlMR5y64c DBESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA2LtZqyFE7371b9tf2neia8QOC8lKzFZZz19/ U1znbvY8ydkh965dXO7DmWHE/PLt6xxj8Y/zG7aKXLkfJx/N4ebdrMS/ojhAWmHHuhXL/SfY sZ6ztMra0bk4toFv0T02YYvnNZaXVs68nF1SrpLkrn7p7hHLo+89wtM0/gdIulwP/vQs3IxL iaU4I9FQi7moOBEA4EIhd3ECAAA= Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 06 Mar 2015 06:30:35 -0000 Hi Loa, my understanding is that it is the former - common model to express and con= trol OAM on various data planes. Transcending, in my view, requires not jus= t understanding of OAM model but understanding of defect data model. Regards, Greg -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Thursday, March 05, 2015 10:15 PM To: Gregory Mirsky; Erik Nordmark; lime@ietf.org Subject: Re: [Lime] Layer-transcending OAM? Greg, does "sufficient commonality" mean that you intend to find a common way to = do oam for different data planes, or does it mean that you intend to interw= ork oam for differernt data planes? /Loa On 2015-03-06 14:08, Gregory Mirsky wrote: > Dear All, > I think it is worth to point that after meeting in Honolulu the LIME WG f= ormed the Design Team to investigate whether there indeed are sufficient co= mmonality among several OAM models in IETF domain - IP, IP/MPLS, MPLS-TP, T= RILL. The document you reference yet not been adopted by the LIME WG and ti= ll then is individual draft. > > Regards, > Greg > > -----Original Message----- > From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, March 05, 2015 9:37 PM > To: Erik Nordmark; lime@ietf.org > Subject: Re: [Lime] Layer-transcending OAM? > > Erik, et.al., > > While I agree that it is proper for the LIME working group to discuss thi= s, the decision to create Layer-transcending OAM is not entirely up to LIME= . > > "Generic" has the implication - "for everyone to use". If you are doing t= hings for others to use you need to be sure that the intended users actuall= y want and need what you are proposing, and that it does not cause problems= for one data plane if another uses your generic model. > > /Loa > > On 2015-03-06 07:34, Erik Nordmark wrote: >> On 3/5/15 7:19 AM, Deepak Kumar (dekumar) wrote: >>> Hi Erik, >>> >>> Generic Yang draft for OAM is for Management and it's not enforcing=20 >>> or proposing strict layering, filtering model. It's bringing concept=20 >>> of Data Model from Ethernet OAM but adding IP specifics for Multipath s= upport. >>> Also it's providing way for operator to go over OAM data hierarchy=20 >>> if present. >> >> Deepak, >> >> I haven't looked carefully at the Yang model draft to see whether it=20 >> actually *prevents* layer-trancendence, but from the=20 >> architecture/model discussion in Honolulu (that Norm presented) I got=20 >> the impression that the layers are completely isolated. >> >> If the Yang draft wants to *enable* layer-trancendence, then I=20 >> suspect it needs to have a way to configure the ttl behavior at the=20 >> tunnel endpoints to be able to select between the pipe and uniform=20 >> ttl tunnel models. >> >> Thus I think the LIME WG should discuss this part of the OAM model. >> >> Regards, >> Erik >> >> >>> >>> Thanks, >>> Deepak >>> >>> On 3/4/15 9:32 PM, "Erik Nordmark" wrote: >>> >>>> This draft makes 3 points: >>>> - we shouldn't hard-code a policy of layer isolation as we think=20 >>>> about OAM for NVO3 and other encapsulations >>>> - NVO3 encaps might consider enabling the ttl behavior which=20 >>>> enables this form of traceroute >>>> - this is easy for VXLAN encapsulation - needs a bit in the=20 >>>> VXLAN header >>>> >>>> The first point is relevant to the OAM architecture and model=20 >>>> discussion in LIME. >>>> In Honolulu there were comments at the mike about thinking about=20 >>>> the Internet OAM model in addition to the Ethernet OAM model, and I=20 >>>> think this property of traceroute is part of the Internet OAM model. >>>> >>>> I hope that first point can trigger some discussion about the model=20 >>>> in LIME. >>>> >>>> Thanks, >>>> Erik >>>> >>>> >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: New Version Notification for >>>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>>> Date: Wed, 04 Mar 2015 18:48:12 -0800 >>>> From: internet-drafts@ietf.org >>>> To: Chandra Appanna , Erik Nordmark >>>> , Alton Lo , Alton Lo=20 >>>> , Erik Nordmark , Chandra=20 >>>> Appanna >>>> >>>> >>>> >>>> A new version of I-D, >>>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>>> has been successfully submitted by Erik Nordmark and posted to the=20 >>>> IETF repository. >>>> >>>> Name: draft-nordmark-nvo3-transcending-traceroute >>>> Revision: 00 >>>> Title: Layer-Transcending Traceroute for Overlay Networks like >>>> VXLAN >>>> Document date: 2015-03-02 >>>> Group: Individual Submission >>>> Pages: 18 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcendin >>>> g >>>> -trace >>>> >>>> route-00.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-t >>>> r >>>> acerou >>>> >>>> te/ >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-tracero >>>> u >>>> te-00 >>>> >>>> >>>> >>>> Abstract: >>>> Tools like traceroute have been very valuable for the operation o= f >>>> the Internet. Part of that value comes from being able to displa= y >>>> information about routers and paths over which the user of the to= ol >>>> has no control, but the traceroute output can be passed along to >>>> someone else that can further investigate or fix the problem. >>>> >>>> In overlay networks such as VXLAN and NVGRE the prevailing view i= s >>>> that since the overlay network has no control of the underlay the= re >>>> needs to be special tools and agreements to enable extracting tra= ces >>>> from the underlay. We argue that enabling visibility into the >>>> underlay and using existing tools like traceroute has been=20 >>>> overlooked >>>> and would add value in many deployments of overlay networks. >>>> >>>> This document specifies an approach that can be used to make >>>> traceroute transcend layers of encapsulation including details fo= r >>>> how to apply this to VXLAN. The technique can be applied to othe= r >>>> encapsulations used for overlay networks. It can also be=20 >>>> implemented >>>> using current commercial silicon. >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of=20 >>>> submission until the htmlized version and diff are available at=20 >>>> tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> _______________________________________________ >>>> Lime mailing list >>>> Lime@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lime >>> >> >> _______________________________________________ >> Lime mailing list >> Lime@ietf.org >> https://www.ietf.org/mailman/listinfo/lime > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Mar 5 22:34:14 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 1B3871ACCE1 for ; Thu, 5 Mar 2015 22:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VVSOwQmzPLZy for ; Thu, 5 Mar 2015 22:34:11 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D2B1ACCE5 for ; Thu, 5 Mar 2015 22:34:09 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.191.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 41E81180145E; Fri, 6 Mar 2015 07:33:48 +0100 (CET) Message-ID: <54F94A44.1060500@pi.nu> Date: Fri, 06 Mar 2015 14:33:40 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gregory Mirsky , Erik Nordmark , "lime@ietf.org" References: <54F8E822.5070409@acm.org> <54F93D07.6000807@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91B4AB@eusaamb103.ericsson.se> <54F945E3.3000300@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91B4E4@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B91B4E4@eusaamb103.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 06 Mar 2015 06:34:13 -0000 Greg, Thanks - as long as we are looking at common ways to do things I'm comfortable. Interworking OAM for different data planes is a totally kettle of fish. /Loa On 2015-03-06 14:30, Gregory Mirsky wrote: > Hi Loa, > my understanding is that it is the former - common model to express and control OAM on various data planes. Transcending, in my view, requires not just understanding of OAM model but understanding of defect data model. > > Regards, > Greg > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, March 05, 2015 10:15 PM > To: Gregory Mirsky; Erik Nordmark; lime@ietf.org > Subject: Re: [Lime] Layer-transcending OAM? > > Greg, > > does "sufficient commonality" mean that you intend to find a common way to do oam for different data planes, or does it mean that you intend to interwork oam for differernt data planes? > > /Loa > > On 2015-03-06 14:08, Gregory Mirsky wrote: >> Dear All, >> I think it is worth to point that after meeting in Honolulu the LIME WG formed the Design Team to investigate whether there indeed are sufficient commonality among several OAM models in IETF domain - IP, IP/MPLS, MPLS-TP, TRILL. The document you reference yet not been adopted by the LIME WG and till then is individual draft. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Thursday, March 05, 2015 9:37 PM >> To: Erik Nordmark; lime@ietf.org >> Subject: Re: [Lime] Layer-transcending OAM? >> >> Erik, et.al., >> >> While I agree that it is proper for the LIME working group to discuss this, the decision to create Layer-transcending OAM is not entirely up to LIME. >> >> "Generic" has the implication - "for everyone to use". If you are doing things for others to use you need to be sure that the intended users actually want and need what you are proposing, and that it does not cause problems for one data plane if another uses your generic model. >> >> /Loa >> >> On 2015-03-06 07:34, Erik Nordmark wrote: >>> On 3/5/15 7:19 AM, Deepak Kumar (dekumar) wrote: >>>> Hi Erik, >>>> >>>> Generic Yang draft for OAM is for Management and it's not enforcing >>>> or proposing strict layering, filtering model. It's bringing concept >>>> of Data Model from Ethernet OAM but adding IP specifics for Multipath support. >>>> Also it's providing way for operator to go over OAM data hierarchy >>>> if present. >>> >>> Deepak, >>> >>> I haven't looked carefully at the Yang model draft to see whether it >>> actually *prevents* layer-trancendence, but from the >>> architecture/model discussion in Honolulu (that Norm presented) I got >>> the impression that the layers are completely isolated. >>> >>> If the Yang draft wants to *enable* layer-trancendence, then I >>> suspect it needs to have a way to configure the ttl behavior at the >>> tunnel endpoints to be able to select between the pipe and uniform >>> ttl tunnel models. >>> >>> Thus I think the LIME WG should discuss this part of the OAM model. >>> >>> Regards, >>> Erik >>> >>> >>>> >>>> Thanks, >>>> Deepak >>>> >>>> On 3/4/15 9:32 PM, "Erik Nordmark" wrote: >>>> >>>>> This draft makes 3 points: >>>>> - we shouldn't hard-code a policy of layer isolation as we think >>>>> about OAM for NVO3 and other encapsulations >>>>> - NVO3 encaps might consider enabling the ttl behavior which >>>>> enables this form of traceroute >>>>> - this is easy for VXLAN encapsulation - needs a bit in the >>>>> VXLAN header >>>>> >>>>> The first point is relevant to the OAM architecture and model >>>>> discussion in LIME. >>>>> In Honolulu there were comments at the mike about thinking about >>>>> the Internet OAM model in addition to the Ethernet OAM model, and I >>>>> think this property of traceroute is part of the Internet OAM model. >>>>> >>>>> I hope that first point can trigger some discussion about the model >>>>> in LIME. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>> >>>>> >>>>> >>>>> -------- Forwarded Message -------- >>>>> Subject: New Version Notification for >>>>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>>>> Date: Wed, 04 Mar 2015 18:48:12 -0800 >>>>> From: internet-drafts@ietf.org >>>>> To: Chandra Appanna , Erik Nordmark >>>>> , Alton Lo , Alton Lo >>>>> , Erik Nordmark , Chandra >>>>> Appanna >>>>> >>>>> >>>>> >>>>> A new version of I-D, >>>>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>>>> has been successfully submitted by Erik Nordmark and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-nordmark-nvo3-transcending-traceroute >>>>> Revision: 00 >>>>> Title: Layer-Transcending Traceroute for Overlay Networks like >>>>> VXLAN >>>>> Document date: 2015-03-02 >>>>> Group: Individual Submission >>>>> Pages: 18 >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcendin >>>>> g >>>>> -trace >>>>> >>>>> route-00.txt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-t >>>>> r >>>>> acerou >>>>> >>>>> te/ >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-tracero >>>>> u >>>>> te-00 >>>>> >>>>> >>>>> >>>>> Abstract: >>>>> Tools like traceroute have been very valuable for the operation of >>>>> the Internet. Part of that value comes from being able to display >>>>> information about routers and paths over which the user of the tool >>>>> has no control, but the traceroute output can be passed along to >>>>> someone else that can further investigate or fix the problem. >>>>> >>>>> In overlay networks such as VXLAN and NVGRE the prevailing view is >>>>> that since the overlay network has no control of the underlay there >>>>> needs to be special tools and agreements to enable extracting traces >>>>> from the underlay. We argue that enabling visibility into the >>>>> underlay and using existing tools like traceroute has been >>>>> overlooked >>>>> and would add value in many deployments of overlay networks. >>>>> >>>>> This document specifies an approach that can be used to make >>>>> traceroute transcend layers of encapsulation including details for >>>>> how to apply this to VXLAN. The technique can be applied to other >>>>> encapsulations used for overlay networks. It can also be >>>>> implemented >>>>> using current commercial silicon. >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> _______________________________________________ >>>>> Lime mailing list >>>>> Lime@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lime >>>> >>> >>> _______________________________________________ >>> Lime mailing list >>> Lime@ietf.org >>> https://www.ietf.org/mailman/listinfo/lime >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Mar 6 01:14: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 9DE341ACD3A for ; Fri, 6 Mar 2015 01:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QJv--TZGkQ1 for ; Fri, 6 Mar 2015 01:14:34 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (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 01DDE1ACD35 for ; Fri, 6 Mar 2015 01:14:34 -0800 (PST) Received: by wesx3 with SMTP id x3so11545835wes.4 for ; Fri, 06 Mar 2015 01:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=W/43CBnKZQmL5UzFck60bR0mGd8CMbmILW+ihfUODA0=; b=zzhXxU3JCZ4vWO2Y5l+j1kDcBOx2PdhNRjL6LbPq6SKaT6eBusqMqcBEahJw19S23g KMFNRDte1xEuj6JUTlrPvKqkTkf3IHkBpxlGQZwhwfRg+zBVRGK4qwSsIVaaY8OSPBIf EheM8Lx7g/YxhL2D3ESM9I8fvdGGJw9J6fQSUpqZvETQYTZgt5ymNQC217QXo+u5pWnb RlP4LlPAezP1T4sDj4VBof0h9r+Y/daaWUSKB+qZjX1vhLR2zJNI/jb0RK64QBEnQDJD 4Jj+pKiF7UXYV7ArffgaJ9ttgl1g8SSQOi9XSKeoiUvKp4RFwLlD/pv3FO55Q+/lKJ30 h1Zg== X-Received: by 10.194.21.193 with SMTP id x1mr26956722wje.144.1425633272666; Fri, 06 Mar 2015 01:14:32 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id dq1sm11966394wib.20.2015.03.06.01.14.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 01:14:31 -0800 (PST) Message-ID: <54F96FF5.7000707@gmail.com> Date: Fri, 06 Mar 2015 10:14:29 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Loa Andersson , Gregory Mirsky , Erik Nordmark , "lime@ietf.org" References: <54F8E822.5070409@acm.org> <54F93D07.6000807@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91B4AB@eusaamb103.ericsson.se> <54F945E3.3000300@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91B4E4@eusaamb103.ericsson.se> <54F94A44.1060500@pi.nu> In-Reply-To: <54F94A44.1060500@pi.nu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Lime] Layer-transcending OAM? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com 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, 06 Mar 2015 09:14:36 -0000 Hello Loa, I agree with you: > Thanks - as long as we are looking at common ways to do things I'm > comfortable. Interworking OAM for different data planes is a totally > kettle of fish. To catch those fish a can of worms has to be opened, which is even worse Regards, Huub. > On 2015-03-06 14:30, Gregory Mirsky wrote: >> Hi Loa, >> my understanding is that it is the former - common model to express >> and control OAM on various data planes. Transcending, in my view, >> requires not just understanding of OAM model but understanding of >> defect data model. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Thursday, March 05, 2015 10:15 PM >> To: Gregory Mirsky; Erik Nordmark; lime@ietf.org >> Subject: Re: [Lime] Layer-transcending OAM? >> >> Greg, >> >> does "sufficient commonality" mean that you intend to find a common >> way to do oam for different data planes, or does it mean that you >> intend to interwork oam for differernt data planes? >> >> /Loa >> >> On 2015-03-06 14:08, Gregory Mirsky wrote: >>> Dear All, >>> I think it is worth to point that after meeting in Honolulu the LIME >>> WG formed the Design Team to investigate whether there indeed are >>> sufficient commonality among several OAM models in IETF domain - IP, >>> IP/MPLS, MPLS-TP, TRILL. The document you reference yet not been >>> adopted by the LIME WG and till then is individual draft. >>> >>> Regards, >>> Greg >>> >>> -----Original Message----- >>> From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Loa Andersson >>> Sent: Thursday, March 05, 2015 9:37 PM >>> To: Erik Nordmark; lime@ietf.org >>> Subject: Re: [Lime] Layer-transcending OAM? >>> >>> Erik, et.al., >>> >>> While I agree that it is proper for the LIME working group to discuss >>> this, the decision to create Layer-transcending OAM is not entirely >>> up to LIME. >>> >>> "Generic" has the implication - "for everyone to use". If you are >>> doing things for others to use you need to be sure that the intended >>> users actually want and need what you are proposing, and that it does >>> not cause problems for one data plane if another uses your generic >>> model. >>> >>> /Loa >>> >>> On 2015-03-06 07:34, Erik Nordmark wrote: >>>> On 3/5/15 7:19 AM, Deepak Kumar (dekumar) wrote: >>>>> Hi Erik, >>>>> >>>>> Generic Yang draft for OAM is for Management and it's not enforcing >>>>> or proposing strict layering, filtering model. It's bringing concept >>>>> of Data Model from Ethernet OAM but adding IP specifics for >>>>> Multipath support. >>>>> Also it's providing way for operator to go over OAM data hierarchy >>>>> if present. >>>> >>>> Deepak, >>>> >>>> I haven't looked carefully at the Yang model draft to see whether it >>>> actually *prevents* layer-trancendence, but from the >>>> architecture/model discussion in Honolulu (that Norm presented) I got >>>> the impression that the layers are completely isolated. >>>> >>>> If the Yang draft wants to *enable* layer-trancendence, then I >>>> suspect it needs to have a way to configure the ttl behavior at the >>>> tunnel endpoints to be able to select between the pipe and uniform >>>> ttl tunnel models. >>>> >>>> Thus I think the LIME WG should discuss this part of the OAM model. >>>> >>>> Regards, >>>> Erik >>>> >>>> >>>>> >>>>> Thanks, >>>>> Deepak >>>>> >>>>> On 3/4/15 9:32 PM, "Erik Nordmark" wrote: >>>>> >>>>>> This draft makes 3 points: >>>>>> - we shouldn't hard-code a policy of layer isolation as we think >>>>>> about OAM for NVO3 and other encapsulations >>>>>> - NVO3 encaps might consider enabling the ttl behavior which >>>>>> enables this form of traceroute >>>>>> - this is easy for VXLAN encapsulation - needs a bit in the >>>>>> VXLAN header >>>>>> >>>>>> The first point is relevant to the OAM architecture and model >>>>>> discussion in LIME. >>>>>> In Honolulu there were comments at the mike about thinking about >>>>>> the Internet OAM model in addition to the Ethernet OAM model, and I >>>>>> think this property of traceroute is part of the Internet OAM model. >>>>>> >>>>>> I hope that first point can trigger some discussion about the model >>>>>> in LIME. >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: New Version Notification for >>>>>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>>>>> Date: Wed, 04 Mar 2015 18:48:12 -0800 >>>>>> From: internet-drafts@ietf.org >>>>>> To: Chandra Appanna , Erik Nordmark >>>>>> , Alton Lo , Alton Lo >>>>>> , Erik Nordmark , Chandra >>>>>> Appanna >>>>>> >>>>>> >>>>>> >>>>>> A new version of I-D, >>>>>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>>>>> has been successfully submitted by Erik Nordmark and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Name: draft-nordmark-nvo3-transcending-traceroute >>>>>> Revision: 00 >>>>>> Title: Layer-Transcending Traceroute for Overlay Networks like >>>>>> VXLAN >>>>>> Document date: 2015-03-02 >>>>>> Group: Individual Submission >>>>>> Pages: 18 >>>>>> URL: >>>>>> http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcendin >>>>>> g >>>>>> -trace >>>>>> >>>>>> route-00.txt >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-t >>>>>> r >>>>>> acerou >>>>>> >>>>>> te/ >>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-tracero >>>>>> u >>>>>> te-00 >>>>>> >>>>>> >>>>>> >>>>>> Abstract: >>>>>> Tools like traceroute have been very valuable for the >>>>>> operation of >>>>>> the Internet. Part of that value comes from being able to >>>>>> display >>>>>> information about routers and paths over which the user of >>>>>> the tool >>>>>> has no control, but the traceroute output can be passed >>>>>> along to >>>>>> someone else that can further investigate or fix the problem. >>>>>> >>>>>> In overlay networks such as VXLAN and NVGRE the prevailing >>>>>> view is >>>>>> that since the overlay network has no control of the >>>>>> underlay there >>>>>> needs to be special tools and agreements to enable >>>>>> extracting traces >>>>>> from the underlay. We argue that enabling visibility into the >>>>>> underlay and using existing tools like traceroute has been >>>>>> overlooked >>>>>> and would add value in many deployments of overlay networks. >>>>>> >>>>>> This document specifies an approach that can be used to make >>>>>> traceroute transcend layers of encapsulation including >>>>>> details for >>>>>> how to apply this to VXLAN. The technique can be applied to >>>>>> other >>>>>> encapsulations used for overlay networks. It can also be >>>>>> implemented >>>>>> using current commercial silicon. >>>>>> >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission until the htmlized version and diff are available at >>>>>> tools.ietf.org. >>>>>> >>>>>> The IETF Secretariat -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From nobody Fri Mar 6 01:35:22 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 7DA121ACD41 for ; Fri, 6 Mar 2015 01:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZSpfgeHJexc for ; Fri, 6 Mar 2015 01:35:19 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 C3BAB1ACD3D for ; Fri, 6 Mar 2015 01:35:17 -0800 (PST) Received: by wibbs8 with SMTP id bs8so2123407wib.0 for ; Fri, 06 Mar 2015 01:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rPku1N7ZR2NCVRL1KP1d2i00HCKOCeim5IX86OcL4I8=; b=VbeUNDJKw5dlO0bMr1RjmPMvQJRmJXo8eTkCWuH/fr+Hj8fX4m94fZM3pvo/Xl9kjA +bOO5FjGQIdf6unZx5sOZ4S0RVwDtdkP8/lhUOFRTjKdaFOSXLp7zZQ1g/GxetlnAUxb 4mGjiBMFDE/hQ5w0P/+1rEcn8+r+NAdMELC8fyRn0k3R6+HURqC/iM2MZPWpLaoTl9fr IQlJApBStieJYnj3gonaXFi7fmufnzLc4SWGojtBCSwHHdjL3DTWQFmnG6Fl1q6a48Nx 1tV6Ol1LWVo0rImfBqLUPdmz8C+IfDHkmHF2A0uBHk07w5guB2P0eJ5RFMa9zX/hHXF0 dBjA== X-Received: by 10.180.106.70 with SMTP id gs6mr74300852wib.39.1425634516590; Fri, 06 Mar 2015 01:35:16 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id dj4sm14124985wjc.13.2015.03.06.01.35.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 01:35:15 -0800 (PST) Message-ID: <54F974D2.20202@gmail.com> Date: Fri, 06 Mar 2015 10:35:14 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Qin Wu , Erik Nordmark , "lime@ietf.org" References: <54F7EA5C.1040904@acm.org> In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Lime] Layer-transcending OAM? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com 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, 06 Mar 2015 09:35:21 -0000 Hello Qin. You wrote: > LIME model is a generic model in the management plane. OK. > LIME model should work irrespective of layer being honored or being > relaxed. Layer-transcending would prevent this. > LIME model should work independent of data plane OAM protocols in > different portions of the network using various transport > technologies. Layer-transcending is discouraged in the data-plane, the LIME model should follow this/ > Any data plane OAM protocol extension is not in the scope of LIME WG. I agree. > I think layer-transcending traceroute is data plane OAM protocol > extension. And this should be discouraged. Regards, Huub. -- ***************************************************************** סǶһ޶ģÿһһ From nobody Fri Mar 6 02:31:59 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 85D6A1A8FD6 for ; Fri, 6 Mar 2015 02:31:58 -0800 (PST) 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 D95KaId93lij for ; Fri, 6 Mar 2015 02:31:56 -0800 (PST) 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 ADC0B1A8F3F for ; Fri, 6 Mar 2015 02:31:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPY50817; Fri, 06 Mar 2015 10:31:53 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Mar 2015 10:31:52 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 6 Mar 2015 18:31:49 +0800 From: Qin Wu To: "huubatwork@gmail.com" , Loa Andersson , Gregory Mirsky , Erik Nordmark , "lime@ietf.org" Thread-Topic: [Lime] Layer-transcending OAM? Thread-Index: AQHQVwXNeQ4e+LfhO0uyMkw2Sb1ZV50Ne3gAgACKWwCAAGU0gIAACKQAgAAB7ICAAARWAIAAAOIAgAAs74CAAJm10A== Date: Fri, 6 Mar 2015 10:31:48 +0000 Message-ID: References: <54F8E822.5070409@acm.org> <54F93D07.6000807@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91B4AB@eusaamb103.ericsson.se> <54F945E3.3000300@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91B4E4@eusaamb103.ericsson.se> <54F94A44.1060500@pi.nu> <54F96FF5.7000707@gmail.com> In-Reply-To: <54F96FF5.7000707@gmail.com> 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: Subject: Re: [Lime] Layer-transcending OAM? 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, 06 Mar 2015 10:31:58 -0000 QWdyZWUsDQppbnRlcndvcmtpbmcgT0FNIGZvciBkaWZmZXJlbnQgZGF0YSBwbGFuZXMgaXMgc29t ZXRoaW5nIHdlIGVhcmx5IGRpc2N1c3NlZCBpbiBkcmFmdC1lZHByb3Atb3BzYXdnLW11bHRpLWxh eWVyLW9hbS1wcy4NCkJ1dCBub3cgSSBiZWxpZXZlIHRoaXMgcGllY2UgYXMgcGFydCBvZiBkYXRh IHBsYW5lIE9BTSBpcyBub3QgaW4gdGhlIHNjb3BlIG9mIExJTUUgV0cuDQoNCi1RaW4NCi0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogTGltZSBbbWFpbHRvOmxpbWUtYm91bmNlc0Bp ZXRmLm9yZ10g5Luj6KGoIEh1dWIgdmFuIEhlbHZvb3J0DQrlj5HpgIHml7bpl7Q6IDIwMTXlubQz 5pyINuaXpSAxNzoxNA0K5pS25Lu25Lq6OiBMb2EgQW5kZXJzc29uOyBHcmVnb3J5IE1pcnNreTsg RXJpayBOb3JkbWFyazsgbGltZUBpZXRmLm9yZw0K5Li76aKYOiBSZTogW0xpbWVdIExheWVyLXRy YW5zY2VuZGluZyBPQU0/DQoNCkhlbGxvIExvYSwNCg0KSSBhZ3JlZSB3aXRoIHlvdToNCg0KPiBU aGFua3MgLSBhcyBsb25nIGFzIHdlIGFyZSBsb29raW5nIGF0IGNvbW1vbiB3YXlzIHRvIGRvIHRo aW5ncyBJJ20gDQo+IGNvbWZvcnRhYmxlLiBJbnRlcndvcmtpbmcgT0FNIGZvciBkaWZmZXJlbnQg ZGF0YSBwbGFuZXMgaXMgYSB0b3RhbGx5IA0KPiBrZXR0bGUgb2YgZmlzaC4NCg0KVG8gY2F0Y2gg dGhvc2UgZmlzaCBhIGNhbiBvZiB3b3JtcyBoYXMgdG8gYmUgb3BlbmVkLCB3aGljaCBpcyBldmVu IHdvcnNlDQoNClJlZ2FyZHMsIEh1dWIuDQoNCg0KDQo+IE9uIDIwMTUtMDMtMDYgMTQ6MzAsIEdy ZWdvcnkgTWlyc2t5IHdyb3RlOg0KPj4gSGkgTG9hLA0KPj4gbXkgdW5kZXJzdGFuZGluZyBpcyB0 aGF0IGl0IGlzIHRoZSBmb3JtZXIgLSBjb21tb24gbW9kZWwgdG8gZXhwcmVzcyANCj4+IGFuZCBj b250cm9sIE9BTSBvbiB2YXJpb3VzIGRhdGEgcGxhbmVzLiBUcmFuc2NlbmRpbmcsIGluIG15IHZp ZXcsIA0KPj4gcmVxdWlyZXMgbm90IGp1c3QgdW5kZXJzdGFuZGluZyBvZiBPQU0gbW9kZWwgYnV0 IHVuZGVyc3RhbmRpbmcgb2YgDQo+PiBkZWZlY3QgZGF0YSBtb2RlbC4NCj4+DQo+PiAgICAgUmVn YXJkcywNCj4+ICAgICAgICAgR3JlZw0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51XQ0KPj4gU2VudDogVGh1 cnNkYXksIE1hcmNoIDA1LCAyMDE1IDEwOjE1IFBNDQo+PiBUbzogR3JlZ29yeSBNaXJza3k7IEVy aWsgTm9yZG1hcms7IGxpbWVAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbTGltZV0gTGF5ZXIt dHJhbnNjZW5kaW5nIE9BTT8NCj4+DQo+PiBHcmVnLA0KPj4NCj4+IGRvZXMgInN1ZmZpY2llbnQg Y29tbW9uYWxpdHkiIG1lYW4gdGhhdCB5b3UgaW50ZW5kIHRvIGZpbmQgYSBjb21tb24gDQo+PiB3 YXkgdG8gZG8gb2FtIGZvciBkaWZmZXJlbnQgZGF0YSBwbGFuZXMsIG9yIGRvZXMgaXQgbWVhbiB0 aGF0IHlvdSANCj4+IGludGVuZCB0byBpbnRlcndvcmsgb2FtIGZvciBkaWZmZXJlcm50IGRhdGEg cGxhbmVzPw0KPj4NCj4+IC9Mb2ENCj4+DQo+PiBPbiAyMDE1LTAzLTA2IDE0OjA4LCBHcmVnb3J5 IE1pcnNreSB3cm90ZToNCj4+PiBEZWFyIEFsbCwNCj4+PiBJIHRoaW5rIGl0IGlzIHdvcnRoIHRv IHBvaW50IHRoYXQgYWZ0ZXIgbWVldGluZyBpbiBIb25vbHVsdSB0aGUgTElNRSANCj4+PiBXRyBm b3JtZWQgdGhlIERlc2lnbiBUZWFtIHRvIGludmVzdGlnYXRlIHdoZXRoZXIgdGhlcmUgaW5kZWVk IGFyZSANCj4+PiBzdWZmaWNpZW50IGNvbW1vbmFsaXR5IGFtb25nIHNldmVyYWwgT0FNIG1vZGVs cyBpbiBJRVRGIGRvbWFpbiAtIElQLCANCj4+PiBJUC9NUExTLCBNUExTLVRQLCBUUklMTC4gVGhl IGRvY3VtZW50IHlvdSByZWZlcmVuY2UgeWV0IG5vdCBiZWVuIA0KPj4+IGFkb3B0ZWQgYnkgdGhl IExJTUUgV0cgYW5kIHRpbGwgdGhlbiBpcyBpbmRpdmlkdWFsIGRyYWZ0Lg0KPj4+DQo+Pj4gICAg IFJlZ2FyZHMsDQo+Pj4gICAgICAgICBHcmVnDQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+IEZyb206IExpbWUgW21haWx0bzpsaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBMb2EgQW5kZXJzc29uDQo+Pj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDA1LCAy MDE1IDk6MzcgUE0NCj4+PiBUbzogRXJpayBOb3JkbWFyazsgbGltZUBpZXRmLm9yZw0KPj4+IFN1 YmplY3Q6IFJlOiBbTGltZV0gTGF5ZXItdHJhbnNjZW5kaW5nIE9BTT8NCj4+Pg0KPj4+IEVyaWss IGV0LmFsLiwNCj4+Pg0KPj4+IFdoaWxlIEkgYWdyZWUgdGhhdCBpdCBpcyBwcm9wZXIgZm9yIHRo ZSBMSU1FIHdvcmtpbmcgZ3JvdXAgdG8gDQo+Pj4gZGlzY3VzcyB0aGlzLCB0aGUgZGVjaXNpb24g dG8gY3JlYXRlIExheWVyLXRyYW5zY2VuZGluZyBPQU0gaXMgbm90IA0KPj4+IGVudGlyZWx5IHVw IHRvIExJTUUuDQo+Pj4NCj4+PiAiR2VuZXJpYyIgaGFzIHRoZSBpbXBsaWNhdGlvbiAtICJmb3Ig ZXZlcnlvbmUgdG8gdXNlIi4gSWYgeW91IGFyZSANCj4+PiBkb2luZyB0aGluZ3MgZm9yIG90aGVy cyB0byB1c2UgeW91IG5lZWQgdG8gYmUgc3VyZSB0aGF0IHRoZSBpbnRlbmRlZCANCj4+PiB1c2Vy cyBhY3R1YWxseSB3YW50IGFuZCBuZWVkIHdoYXQgeW91IGFyZSBwcm9wb3NpbmcsIGFuZCB0aGF0 IGl0IA0KPj4+IGRvZXMgbm90IGNhdXNlIHByb2JsZW1zIGZvciBvbmUgZGF0YSBwbGFuZSBpZiBh bm90aGVyIHVzZXMgeW91ciANCj4+PiBnZW5lcmljIG1vZGVsLg0KPj4+DQo+Pj4gL0xvYQ0KPj4+ DQo+Pj4gT24gMjAxNS0wMy0wNiAwNzozNCwgRXJpayBOb3JkbWFyayB3cm90ZToNCj4+Pj4gT24g My81LzE1IDc6MTkgQU0sIERlZXBhayBLdW1hciAoZGVrdW1hcikgd3JvdGU6DQo+Pj4+PiBIaSBF cmlrLA0KPj4+Pj4NCj4+Pj4+IEdlbmVyaWMgWWFuZyBkcmFmdCBmb3IgT0FNIGlzIGZvciBNYW5h Z2VtZW50IGFuZCBpdCdzIG5vdCANCj4+Pj4+IGVuZm9yY2luZyBvciBwcm9wb3Npbmcgc3RyaWN0 IGxheWVyaW5nLCBmaWx0ZXJpbmcgbW9kZWwuIEl0J3MgDQo+Pj4+PiBicmluZ2luZyBjb25jZXB0 IG9mIERhdGEgTW9kZWwgZnJvbSBFdGhlcm5ldCBPQU0gYnV0IGFkZGluZyBJUCANCj4+Pj4+IHNw ZWNpZmljcyBmb3IgTXVsdGlwYXRoIHN1cHBvcnQuDQo+Pj4+PiBBbHNvIGl0J3MgcHJvdmlkaW5n IHdheSBmb3Igb3BlcmF0b3IgdG8gZ28gb3ZlciBPQU0gZGF0YSBoaWVyYXJjaHkgDQo+Pj4+PiBp ZiBwcmVzZW50Lg0KPj4+Pg0KPj4+PiBEZWVwYWssDQo+Pj4+DQo+Pj4+IEkgaGF2ZW4ndCBsb29r ZWQgY2FyZWZ1bGx5IGF0IHRoZSBZYW5nIG1vZGVsIGRyYWZ0IHRvIHNlZSB3aGV0aGVyIA0KPj4+ PiBpdCBhY3R1YWxseSAqcHJldmVudHMqIGxheWVyLXRyYW5jZW5kZW5jZSwgYnV0IGZyb20gdGhl IA0KPj4+PiBhcmNoaXRlY3R1cmUvbW9kZWwgZGlzY3Vzc2lvbiBpbiBIb25vbHVsdSAodGhhdCBO b3JtIHByZXNlbnRlZCkgSSANCj4+Pj4gZ290IHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIGxheWVy cyBhcmUgY29tcGxldGVseSBpc29sYXRlZC4NCj4+Pj4NCj4+Pj4gSWYgdGhlIFlhbmcgZHJhZnQg d2FudHMgdG8gKmVuYWJsZSogbGF5ZXItdHJhbmNlbmRlbmNlLCB0aGVuIEkgDQo+Pj4+IHN1c3Bl Y3QgaXQgbmVlZHMgdG8gaGF2ZSBhIHdheSB0byBjb25maWd1cmUgdGhlIHR0bCBiZWhhdmlvciBh dCB0aGUgDQo+Pj4+IHR1bm5lbCBlbmRwb2ludHMgdG8gYmUgYWJsZSB0byBzZWxlY3QgYmV0d2Vl biB0aGUgcGlwZSBhbmQgdW5pZm9ybSANCj4+Pj4gdHRsIHR1bm5lbCBtb2RlbHMuDQo+Pj4+DQo+ Pj4+IFRodXMgSSB0aGluayB0aGUgTElNRSBXRyBzaG91bGQgZGlzY3VzcyB0aGlzIHBhcnQgb2Yg dGhlIE9BTSBtb2RlbC4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4gICAgICAgRXJpaw0KPj4+ Pg0KPj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoYW5rcywNCj4+Pj4+IERlZXBhaw0KPj4+Pj4NCj4+Pj4+ IE9uIDMvNC8xNSA5OjMyIFBNLCAiRXJpayBOb3JkbWFyayIgPG5vcmRtYXJrQGFjbS5vcmc+IHdy b3RlOg0KPj4+Pj4NCj4+Pj4+PiBUaGlzIGRyYWZ0IG1ha2VzIDMgcG9pbnRzOg0KPj4+Pj4+ICAg ICAtIHdlIHNob3VsZG4ndCBoYXJkLWNvZGUgYSBwb2xpY3kgb2YgbGF5ZXIgaXNvbGF0aW9uIGFz IHdlIA0KPj4+Pj4+IHRoaW5rIGFib3V0IE9BTSBmb3IgTlZPMyBhbmQgb3RoZXIgZW5jYXBzdWxh dGlvbnMNCj4+Pj4+PiAgICAgLSBOVk8zIGVuY2FwcyBtaWdodCBjb25zaWRlciBlbmFibGluZyB0 aGUgdHRsIGJlaGF2aW9yIHdoaWNoIA0KPj4+Pj4+IGVuYWJsZXMgdGhpcyBmb3JtIG9mIHRyYWNl cm91dGUNCj4+Pj4+PiAgICAgLSB0aGlzIGlzIGVhc3kgZm9yIFZYTEFOIGVuY2Fwc3VsYXRpb24g LSBuZWVkcyBhIGJpdCBpbiB0aGUgDQo+Pj4+Pj4gVlhMQU4gaGVhZGVyDQo+Pj4+Pj4NCj4+Pj4+ PiBUaGUgZmlyc3QgcG9pbnQgaXMgcmVsZXZhbnQgdG8gdGhlIE9BTSBhcmNoaXRlY3R1cmUgYW5k IG1vZGVsIA0KPj4+Pj4+IGRpc2N1c3Npb24gaW4gTElNRS4NCj4+Pj4+PiBJbiBIb25vbHVsdSB0 aGVyZSB3ZXJlIGNvbW1lbnRzIGF0IHRoZSBtaWtlIGFib3V0IHRoaW5raW5nIGFib3V0IA0KPj4+ Pj4+IHRoZSBJbnRlcm5ldCBPQU0gbW9kZWwgaW4gYWRkaXRpb24gdG8gdGhlIEV0aGVybmV0IE9B TSBtb2RlbCwgYW5kIA0KPj4+Pj4+IEkgdGhpbmsgdGhpcyBwcm9wZXJ0eSBvZiB0cmFjZXJvdXRl IGlzIHBhcnQgb2YgdGhlIEludGVybmV0IE9BTSBtb2RlbC4NCj4+Pj4+Pg0KPj4+Pj4+IEkgaG9w ZSB0aGF0IGZpcnN0IHBvaW50IGNhbiB0cmlnZ2VyIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCB0aGUg DQo+Pj4+Pj4gbW9kZWwgaW4gTElNRS4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcywNCj4+Pj4+PiAg ICAgRXJpaw0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gLS0tLS0tLS0g Rm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4+Pj4+PiBTdWJqZWN0OiAgICAgTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvcg0KPj4+Pj4+IGRyYWZ0LW5vcmRtYXJrLW52bzMtdHJhbnNjZW5k aW5nLXRyYWNlcm91dGUtMDAudHh0DQo+Pj4+Pj4gRGF0ZTogICAgIFdlZCwgMDQgTWFyIDIwMTUg MTg6NDg6MTIgLTA4MDANCj4+Pj4+PiBGcm9tOiAgICAgaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn DQo+Pj4+Pj4gVG86ICAgICBDaGFuZHJhIEFwcGFubmEgPGFjaGFuZHJhQGFyaXN0YS5jb20+LCBF cmlrIE5vcmRtYXJrDQo+Pj4+Pj4gPG5vcmRtYXJrQGFyaXN0YS5jb20+LCBBbHRvbiBMbyA8YWx0 b25sb0BhcmlzdGEuY29tPiwgQWx0b24gTG8gDQo+Pj4+Pj4gPGFsdG9ubG9AYXJpc3RhLmNvbT4s IEVyaWsgTm9yZG1hcmsgPG5vcmRtYXJrQGFyaXN0YS5jb20+LCANCj4+Pj4+PiBDaGFuZHJhIEFw cGFubmEgPGFjaGFuZHJhQGFyaXN0YS5jb20+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+ Pj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsDQo+Pj4+Pj4gZHJhZnQtbm9yZG1hcmstbnZvMy10cmFu c2NlbmRpbmctdHJhY2Vyb3V0ZS0wMC50eHQNCj4+Pj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEVyaWsgTm9yZG1hcmsgYW5kIHBvc3RlZCB0byANCj4+Pj4+PiB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KPj4+Pj4+DQo+Pj4+Pj4gTmFtZTogICAgICAgIGRyYWZ0LW5vcmRtYXJr LW52bzMtdHJhbnNjZW5kaW5nLXRyYWNlcm91dGUNCj4+Pj4+PiBSZXZpc2lvbjogICAgMDANCj4+ Pj4+PiBUaXRsZTogICAgICAgIExheWVyLVRyYW5zY2VuZGluZyBUcmFjZXJvdXRlIGZvciBPdmVy bGF5IE5ldHdvcmtzIGxpa2UNCj4+Pj4+PiBWWExBTg0KPj4+Pj4+IERvY3VtZW50IGRhdGU6ICAg IDIwMTUtMDMtMDINCj4+Pj4+PiBHcm91cDogICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K Pj4+Pj4+IFBhZ2VzOiAgICAgICAgMTgNCj4+Pj4+PiBVUkw6DQo+Pj4+Pj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbm9yZG1hcmstbnZvMy10cmFuc2NlbmQNCj4+ Pj4+PiBpbg0KPj4+Pj4+IGcNCj4+Pj4+PiAtdHJhY2UNCj4+Pj4+Pg0KPj4+Pj4+IHJvdXRlLTAw LnR4dA0KPj4+Pj4+IFN0YXR1czoNCj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1ub3JkbWFyay1udm8zLXRyYW5zY2VuZGluZw0KPj4+Pj4+IC10DQo+Pj4+Pj4g cg0KPj4+Pj4+IGFjZXJvdQ0KPj4+Pj4+DQo+Pj4+Pj4gdGUvDQo+Pj4+Pj4gSHRtbGl6ZWQ6DQo+ Pj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbm9yZG1hcmstbnZvMy10cmFu c2NlbmRpbmctdHJhY2UNCj4+Pj4+PiBybw0KPj4+Pj4+IHUNCj4+Pj4+PiB0ZS0wMA0KPj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEFic3RyYWN0Og0KPj4+Pj4+ICAgICAgIFRvb2xzIGxp a2UgdHJhY2Vyb3V0ZSBoYXZlIGJlZW4gdmVyeSB2YWx1YWJsZSBmb3IgdGhlIA0KPj4+Pj4+IG9w ZXJhdGlvbiBvZg0KPj4+Pj4+ICAgICAgIHRoZSBJbnRlcm5ldC4gIFBhcnQgb2YgdGhhdCB2YWx1 ZSBjb21lcyBmcm9tIGJlaW5nIGFibGUgdG8gDQo+Pj4+Pj4gZGlzcGxheQ0KPj4+Pj4+ICAgICAg IGluZm9ybWF0aW9uIGFib3V0IHJvdXRlcnMgYW5kIHBhdGhzIG92ZXIgd2hpY2ggdGhlIHVzZXIg b2YgDQo+Pj4+Pj4gdGhlIHRvb2wNCj4+Pj4+PiAgICAgICBoYXMgbm8gY29udHJvbCwgYnV0IHRo ZSB0cmFjZXJvdXRlIG91dHB1dCBjYW4gYmUgcGFzc2VkIA0KPj4+Pj4+IGFsb25nIHRvDQo+Pj4+ Pj4gICAgICAgc29tZW9uZSBlbHNlIHRoYXQgY2FuIGZ1cnRoZXIgaW52ZXN0aWdhdGUgb3IgZml4 IHRoZSBwcm9ibGVtLg0KPj4+Pj4+DQo+Pj4+Pj4gICAgICAgSW4gb3ZlcmxheSBuZXR3b3JrcyBz dWNoIGFzIFZYTEFOIGFuZCBOVkdSRSB0aGUgcHJldmFpbGluZyANCj4+Pj4+PiB2aWV3IGlzDQo+ Pj4+Pj4gICAgICAgdGhhdCBzaW5jZSB0aGUgb3ZlcmxheSBuZXR3b3JrIGhhcyBubyBjb250cm9s IG9mIHRoZSANCj4+Pj4+PiB1bmRlcmxheSB0aGVyZQ0KPj4+Pj4+ICAgICAgIG5lZWRzIHRvIGJl IHNwZWNpYWwgdG9vbHMgYW5kIGFncmVlbWVudHMgdG8gZW5hYmxlIA0KPj4+Pj4+IGV4dHJhY3Rp bmcgdHJhY2VzDQo+Pj4+Pj4gICAgICAgZnJvbSB0aGUgdW5kZXJsYXkuICBXZSBhcmd1ZSB0aGF0 IGVuYWJsaW5nIHZpc2liaWxpdHkgaW50byB0aGUNCj4+Pj4+PiAgICAgICB1bmRlcmxheSBhbmQg dXNpbmcgZXhpc3RpbmcgdG9vbHMgbGlrZSB0cmFjZXJvdXRlIGhhcyBiZWVuIA0KPj4+Pj4+IG92 ZXJsb29rZWQNCj4+Pj4+PiAgICAgICBhbmQgd291bGQgYWRkIHZhbHVlIGluIG1hbnkgZGVwbG95 bWVudHMgb2Ygb3ZlcmxheSBuZXR3b3Jrcy4NCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgIFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIGFuIGFwcHJvYWNoIHRoYXQgY2FuIGJlIHVzZWQgdG8gbWFrZQ0KPj4+ Pj4+ICAgICAgIHRyYWNlcm91dGUgdHJhbnNjZW5kIGxheWVycyBvZiBlbmNhcHN1bGF0aW9uIGlu Y2x1ZGluZyANCj4+Pj4+PiBkZXRhaWxzIGZvcg0KPj4+Pj4+ICAgICAgIGhvdyB0byBhcHBseSB0 aGlzIHRvIFZYTEFOLiAgVGhlIHRlY2huaXF1ZSBjYW4gYmUgYXBwbGllZCANCj4+Pj4+PiB0byBv dGhlcg0KPj4+Pj4+ICAgICAgIGVuY2Fwc3VsYXRpb25zIHVzZWQgZm9yIG92ZXJsYXkgbmV0d29y a3MuICBJdCBjYW4gYWxzbyBiZSANCj4+Pj4+PiBpbXBsZW1lbnRlZA0KPj4+Pj4+ICAgICAgIHVz aW5nIGN1cnJlbnQgY29tbWVyY2lhbCBzaWxpY29uLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIA0KPj4+Pj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCANCj4+Pj4+PiB0b29scy5pZXRmLm9yZy4N Cj4+Pj4+Pg0KPj4+Pj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQotLQ0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN CiAgICAgICAgICAgICAgIOivt+iusOS9j++8jOS9oOaYr+eLrOS4gOaXoOS6jOeahO+8jOWwseWD j+WFtuS7luavj+S4gOS4quS6uuS4gOagtw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KTGltZSBtYWlsaW5nIGxpc3QNCkxpbWVAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGltZQ0K From nobody Fri Mar 6 02:45: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 B7A3B1A03E3 for ; Fri, 6 Mar 2015 02:45:43 -0800 (PST) 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 Ir7Ssx6oz3Qx for ; Fri, 6 Mar 2015 02:45:42 -0800 (PST) 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 580DC1A0211 for ; Fri, 6 Mar 2015 02:45:42 -0800 (PST) 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 BTI67152; Fri, 06 Mar 2015 10:45:40 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Mar 2015 10:45:34 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 6 Mar 2015 18:45:28 +0800 From: Qin Wu To: "huubatwork@gmail.com" , Erik Nordmark , "lime@ietf.org" Thread-Topic: [Lime] Layer-transcending OAM? Thread-Index: AQHQVwXNeQ4e+LfhO0uyMkw2Sb1ZV50O3/MA///NlwCAAJd6wA== Date: Fri, 6 Mar 2015 10:45:27 +0000 Message-ID: References: <54F7EA5C.1040904@acm.org> <54F974D2.20202@gmail.com> In-Reply-To: <54F974D2.20202@gmail.com> 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 06 Mar 2015 10:45:43 -0000 SHV1YjoNCkkgYWdyZWUgdGhlIExJTUUgc2hvdWxkIHJlc3BlY3Qgc3RyaWN0IE9BTSBsYXllcmlu ZyBpZiBsYXllciB0cmFuc2NlbmRpbmcgaXMgZGlzY291cmFnZWQgaW4gdGhlIGRhdGEgcGxhbmUu DQpNeSBwb2ludCBiZWxvdyBpcyBMSU1FIG1vZGVsIGlzIG9ydGhvZ29uYWwgdG8gZGF0YSBwbGFu ZSBPQU0gbW9kZWwuDQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBIdXViIHZh biBIZWx2b29ydCBbbWFpbHRvOmh1dWJhdHdvcmtAZ21haWwuY29tXSANCreiy83KsbzkOiAyMDE1 xOoz1MI2yNUgMTc6MzUNCsrVvP7IyzogUWluIFd1OyBFcmlrIE5vcmRtYXJrOyBsaW1lQGlldGYu b3JnDQrW98ziOiBSZTogW0xpbWVdIExheWVyLXRyYW5zY2VuZGluZyBPQU0/DQoNCkhlbGxvIFFp bi4NCg0KWW91IHdyb3RlOg0KDQo+IExJTUUgbW9kZWwgaXMgYSBnZW5lcmljIG1vZGVsIGluIHRo ZSBtYW5hZ2VtZW50IHBsYW5lLg0KDQpPSy4NCg0KPiBMSU1FIG1vZGVsIHNob3VsZCB3b3JrIGly cmVzcGVjdGl2ZSBvZiBsYXllciBiZWluZyBob25vcmVkIG9yIGJlaW5nIA0KPiByZWxheGVkLg0K DQpMYXllci10cmFuc2NlbmRpbmcgd291bGQgcHJldmVudCB0aGlzLg0KDQo+IExJTUUgbW9kZWwg c2hvdWxkIHdvcmsgaW5kZXBlbmRlbnQgb2YgZGF0YSBwbGFuZSBPQU0gcHJvdG9jb2xzIGluIA0K PiBkaWZmZXJlbnQgcG9ydGlvbnMgb2YgdGhlIG5ldHdvcmsgdXNpbmcgdmFyaW91cyB0cmFuc3Bv cnQgDQo+IHRlY2hub2xvZ2llcy4NCg0KTGF5ZXItdHJhbnNjZW5kaW5nIGlzIGRpc2NvdXJhZ2Vk IGluIHRoZSBkYXRhLXBsYW5lLCB0aGUgTElNRSBtb2RlbCBzaG91bGQgZm9sbG93IHRoaXMvDQoN Cj4gQW55IGRhdGEgcGxhbmUgT0FNIHByb3RvY29sIGV4dGVuc2lvbiBpcyBub3QgaW4gdGhlIHNj b3BlIG9mIExJTUUgV0cuDQoNCkkgYWdyZWUuDQoNCj4gSSB0aGluayBsYXllci10cmFuc2NlbmRp bmcgdHJhY2Vyb3V0ZSBpcyBkYXRhIHBsYW5lIE9BTSBwcm90b2NvbCANCj4gZXh0ZW5zaW9uLg0K DQpBbmQgdGhpcyBzaG91bGQgYmUgZGlzY291cmFnZWQuDQoNClJlZ2FyZHMsIEh1dWIuDQoNCg0K LS0NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQogICAgICAgICAgICAgICDH67zH16GjrMTjyse2wNK7zt62/rXEo6y+zc/x xuTL+8O/0ru49sjL0rvR+Q0K From nobody Fri Mar 6 06:55: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 2C9681ACE47 for ; Fri, 6 Mar 2015 06:55:25 -0800 (PST) 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 6HywgnkP2f9J for ; Fri, 6 Mar 2015 06:55:21 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0143.outbound.protection.outlook.com [65.55.169.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDE11ACE50 for ; Fri, 6 Mar 2015 06:54:09 -0800 (PST) Received: from CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) by CO1PR05MB538.namprd05.prod.outlook.com (10.141.73.24) with Microsoft SMTP Server (TLS) id 15.1.99.14; Fri, 6 Mar 2015 14:54:07 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.106.15; Fri, 6 Mar 2015 14:54:03 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.100]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.100]) with mapi id 15.01.0106.007; Fri, 6 Mar 2015 14:54:02 +0000 From: Ronald Bonica To: Gregory Mirsky , Loa Andersson , Erik Nordmark , "lime@ietf.org" Thread-Topic: [Lime] Layer-transcending OAM? Thread-Index: AQHQVwXE/wSLlhz2JEii2jFppJurgJ0OAZQAgACKXACAAGU0gIAACKMAgAAB7ICAAARWAIAAjCDg Date: Fri, 6 Mar 2015 14:54:02 +0000 Message-ID: References: <54F8E822.5070409@acm.org> <54F93D07.6000807@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91B4AB@eusaamb103.ericsson.se> <54F945E3.3000300@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91B4E4@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B91B4E4@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB441; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB538; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377424004)(13464003)(252514010)(479174004)(377454003)(51704005)(24454002)(93886004)(50986999)(2501003)(66066001)(77156002)(2656002)(62966003)(33656002)(87936001)(74316001)(1720100001)(54356999)(76176999)(107886001)(76576001)(99286002)(19580405001)(19580395003)(92566002)(2900100001)(102836002)(46102003)(86362001)(15975445007)(122556002)(106116001)(40100003)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002007)(5005006); SRVR:CO1PR05MB441; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB441; x-forefront-prvs: 05079D8470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2015 14:54:02.6427 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB441 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 06 Mar 2015 14:55:25 -0000 Hi Loa, Greg's statement, below, reflects the WG charter. Ron / chair hat on > -----Original Message----- > From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Gregory Mirsky > Sent: Friday, March 06, 2015 1:31 AM > To: Loa Andersson; Erik Nordmark; lime@ietf.org > Subject: Re: [Lime] Layer-transcending OAM? >=20 > Hi Loa, > my understanding is that it is the former - common model to express and > control OAM on various data planes. Transcending, in my view, requires no= t > just understanding of OAM model but understanding of defect data model. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, March 05, 2015 10:15 PM > To: Gregory Mirsky; Erik Nordmark; lime@ietf.org > Subject: Re: [Lime] Layer-transcending OAM? >=20 > Greg, >=20 > does "sufficient commonality" mean that you intend to find a common way > to do oam for different data planes, or does it mean that you intend to > interwork oam for differernt data planes? >=20 > /Loa >=20 > On 2015-03-06 14:08, Gregory Mirsky wrote: > > Dear All, > > I think it is worth to point that after meeting in Honolulu the LIME WG > formed the Design Team to investigate whether there indeed are sufficient > commonality among several OAM models in IETF domain - IP, IP/MPLS, > MPLS-TP, TRILL. The document you reference yet not been adopted by the > LIME WG and till then is individual draft. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Loa Andersson > > Sent: Thursday, March 05, 2015 9:37 PM > > To: Erik Nordmark; lime@ietf.org > > Subject: Re: [Lime] Layer-transcending OAM? > > > > Erik, et.al., > > > > While I agree that it is proper for the LIME working group to discuss t= his, > the decision to create Layer-transcending OAM is not entirely up to LIME. > > > > "Generic" has the implication - "for everyone to use". If you are doing > things for others to use you need to be sure that the intended users actu= ally > want and need what you are proposing, and that it does not cause problems > for one data plane if another uses your generic model. > > > > /Loa > > > > On 2015-03-06 07:34, Erik Nordmark wrote: > >> On 3/5/15 7:19 AM, Deepak Kumar (dekumar) wrote: > >>> Hi Erik, > >>> > >>> Generic Yang draft for OAM is for Management and it's not enforcing > >>> or proposing strict layering, filtering model. It's bringing concept > >>> of Data Model from Ethernet OAM but adding IP specifics for Multipath > support. > >>> Also it's providing way for operator to go over OAM data hierarchy > >>> if present. > >> > >> Deepak, > >> > >> I haven't looked carefully at the Yang model draft to see whether it > >> actually *prevents* layer-trancendence, but from the > >> architecture/model discussion in Honolulu (that Norm presented) I got > >> the impression that the layers are completely isolated. > >> > >> If the Yang draft wants to *enable* layer-trancendence, then I > >> suspect it needs to have a way to configure the ttl behavior at the > >> tunnel endpoints to be able to select between the pipe and uniform > >> ttl tunnel models. > >> > >> Thus I think the LIME WG should discuss this part of the OAM model. > >> > >> Regards, > >> Erik > >> > >> > >>> > >>> Thanks, > >>> Deepak > >>> > >>> On 3/4/15 9:32 PM, "Erik Nordmark" wrote: > >>> > >>>> This draft makes 3 points: > >>>> - we shouldn't hard-code a policy of layer isolation as we think > >>>> about OAM for NVO3 and other encapsulations > >>>> - NVO3 encaps might consider enabling the ttl behavior which > >>>> enables this form of traceroute > >>>> - this is easy for VXLAN encapsulation - needs a bit in the > >>>> VXLAN header > >>>> > >>>> The first point is relevant to the OAM architecture and model > >>>> discussion in LIME. > >>>> In Honolulu there were comments at the mike about thinking about > >>>> the Internet OAM model in addition to the Ethernet OAM model, and I > >>>> think this property of traceroute is part of the Internet OAM model. > >>>> > >>>> I hope that first point can trigger some discussion about the model > >>>> in LIME. > >>>> > >>>> Thanks, > >>>> Erik > >>>> > >>>> > >>>> > >>>> > >>>> -------- Forwarded Message -------- > >>>> Subject: New Version Notification for > >>>> draft-nordmark-nvo3-transcending-traceroute-00.txt > >>>> Date: Wed, 04 Mar 2015 18:48:12 -0800 > >>>> From: internet-drafts@ietf.org > >>>> To: Chandra Appanna , Erik Nordmark > >>>> , Alton Lo , Alton Lo > >>>> , Erik Nordmark , > Chandra > >>>> Appanna > >>>> > >>>> > >>>> > >>>> A new version of I-D, > >>>> draft-nordmark-nvo3-transcending-traceroute-00.txt > >>>> has been successfully submitted by Erik Nordmark and posted to the > >>>> IETF repository. > >>>> > >>>> Name: draft-nordmark-nvo3-transcending-traceroute > >>>> Revision: 00 > >>>> Title: Layer-Transcending Traceroute for Overlay Networks lik= e > >>>> VXLAN > >>>> Document date: 2015-03-02 > >>>> Group: Individual Submission > >>>> Pages: 18 > >>>> URL: > >>>> http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcendin > >>>> g > >>>> -trace > >>>> > >>>> route-00.txt > >>>> Status: > >>>> https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-t > >>>> r > >>>> acerou > >>>> > >>>> te/ > >>>> Htmlized: > >>>> http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-tracero > >>>> u > >>>> te-00 > >>>> > >>>> > >>>> > >>>> Abstract: > >>>> Tools like traceroute have been very valuable for the operation= of > >>>> the Internet. Part of that value comes from being able to disp= lay > >>>> information about routers and paths over which the user of the = tool > >>>> has no control, but the traceroute output can be passed along t= o > >>>> someone else that can further investigate or fix the problem. > >>>> > >>>> In overlay networks such as VXLAN and NVGRE the prevailing view= is > >>>> that since the overlay network has no control of the underlay t= here > >>>> needs to be special tools and agreements to enable extracting t= races > >>>> from the underlay. We argue that enabling visibility into the > >>>> underlay and using existing tools like traceroute has been > >>>> overlooked > >>>> and would add value in many deployments of overlay networks. > >>>> > >>>> This document specifies an approach that can be used to make > >>>> traceroute transcend layers of encapsulation including details = for > >>>> how to apply this to VXLAN. The technique can be applied to ot= her > >>>> encapsulations used for overlay networks. It can also be > >>>> implemented > >>>> using current commercial silicon. > >>>> > >>>> > >>>> > >>>> Please note that it may take a couple of minutes from the time of > >>>> submission until the htmlized version and diff are available at > >>>> tools.ietf.org. > >>>> > >>>> The IETF Secretariat > >>>> > >>>> > >>>> _______________________________________________ > >>>> Lime mailing list > >>>> Lime@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lime > >>> > >> > >> _______________________________________________ > >> Lime mailing list > >> Lime@ietf.org > >> https://www.ietf.org/mailman/listinfo/lime > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > Lime mailing list > Lime@ietf.org > https://www.ietf.org/mailman/listinfo/lime From nobody Fri Mar 6 12:03: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 559741A7011 for ; Fri, 6 Mar 2015 12:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 QaSvgLY97Fby for ; Fri, 6 Mar 2015 12:03:30 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2FE1A710C for ; Fri, 6 Mar 2015 12:03:30 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t26K3Ewi004332; Fri, 6 Mar 2015 20:03:14 GMT Received: from 950129200 (089144213255.atnat0022.highway.a1.net [89.144.213.255]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t26K24e8003548 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2015 20:03:13 GMT From: "Adrian Farrel" To: "'Qin Wu'" , , "'Erik Nordmark'" , References: <54F7EA5C.1040904@acm.org> <54F974D2.20202@gmail.com> In-Reply-To: Date: Fri, 6 Mar 2015 20:02:05 -0000 Message-ID: <030001d05848$953ee100$bfbca300$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHZB6IxJNGhLxHV4KgtBM+nAOu+KwLeHNdmAi35mf4C5NMayZy+yS1w Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21382.002 X-TM-AS-Result: No--11.964-10.0-31-10 X-imss-scan-details: No--11.964-10.0-31-10 X-TMASE-MatchedRID: cgbqQT5W8heOhHkPCXAFR3uTVkeYosXtDYBVKmbeeQOzotxpJhQnA4pG tCmuhU7r6sHEhWYp76Udq7eFk3EF05/zS12FgF2DxFLSluI58ptEkG+GyPC3SdJgDNnoqapax5M FoTaoWr+/JDJJEniQqU6nIMfjRtNUFkrTnESQKQIthMwJZwfKESTa6AWhmfi1ClyrX4tOmxSjxY yRBa/qJX3mXSdV7KK4OubYLCVnBVEgBwKKRHe+r4hJUG6bkN185CSd5Ob0C1Y/b1zQSWTyQtTPs ROS/CDL/TTWEKLd/Q0= Archived-At: Subject: Re: [Lime] Layer-transcending OAM? X-BeenThere: lime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk 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, 06 Mar 2015 20:03:39 -0000 All, (responding to Qin at the top of the thread, but not specifically to his email) I'm finding this discussion hard. The "layer independence" in LIME means "being independent of layers". Going back to presentations in an old BoF that wasn't even called LIME is not helpful, and we should look at what the LIME WG is working on, not what was floated at a BoF. So, if the network is using a multi-layered approach with OAM in each layer, LIME is supposed to be able to interact with the OAM in each layer (independently) in a generic way. That means configuring the OAM, and receiving reports from the OAM. If the network is using "layer transcendence" (TM) and running some form of network-wide layer-transcending OAM, then LIME is supposed to be able to interact with the OAM in a generic way. (Ditto config, reports). LIME makes no statement about how OAM should be operated in data planes. LIME *does* have a secondary deliverable about specifying general guidance to people designing new OAM or building OAM for new data planes. It looks like that work is some way off (I don't recall seeing a draft) and *that* work might have something to say about transcendental OAM. Thanks, Adrian From nobody Fri Mar 6 18:25:11 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 090A11A87AE for ; Fri, 6 Mar 2015 18:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 Pd-HhtNziTVi for ; Fri, 6 Mar 2015 18:25:06 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011861A87B0 for ; Fri, 6 Mar 2015 18:25:05 -0800 (PST) Received: from [10.0.0.133] (64-13-15-87.sfo.clearwire-wmx.net [64.13.15.87] (may be forged)) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t272OtVW006231 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Mar 2015 18:24:57 -0800 Message-ID: <54FA6177.1020207@acm.org> Date: Fri, 06 Mar 2015 18:24:55 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: huubatwork@gmail.com, Qin Wu , Erik Nordmark , "lime@ietf.org" References: <54F7EA5C.1040904@acm.org> <54F974D2.20202@gmail.com> In-Reply-To: <54F974D2.20202@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbeJfHl8kYYC689RKP0oBUwJOMXVs7Qr7vIECdItWQiGAw+gX973oDw8U2/rzgALpvV7SsYCyKAAWNZsX85Uakj X-Sonic-ID: C;dESJJHHE5BGPFu8Jj30JFw== M;OPr5JXHE5BGPFu8Jj30JFw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 07 Mar 2015 02:25:10 -0000 On 3/6/15 1:35 AM, Huub van Helvoort wrote: > >> LIME model should work independent of data plane OAM protocols in >> different portions of the network using various transport >> technologies. > > Layer-transcending is discouraged in the data-plane, Huub, Who is discouraging this? The IETF? The Internet architecture? Please provide references and/or more detail. Thanks, Erik From nobody Fri Mar 6 18:26: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 84A9F1A87B0 for ; Fri, 6 Mar 2015 18:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 I1rXLU7sYtZ2 for ; Fri, 6 Mar 2015 18:26:42 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8891A87AD for ; Fri, 6 Mar 2015 18:26:34 -0800 (PST) Received: from [10.0.0.133] (64-13-15-87.eug.clearwire-dns.net [64.13.15.87]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t272QSab031675 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Mar 2015 18:26:28 -0800 Message-ID: <54FA61D4.9050000@acm.org> Date: Fri, 06 Mar 2015 18:26:28 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Loa Andersson , Erik Nordmark , "lime@ietf.org" References: <54F8E822.5070409@acm.org> <54F93D07.6000807@pi.nu> In-Reply-To: <54F93D07.6000807@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZ/nqz1DLJ5q3rv77zXmsJiITI7+KOIg0rLxnjGJ3Vo6Vp6pftk4Im8xqjfBk3OEyoB9ELWDhQcSY2wvLEQARX2 X-Sonic-ID: C;3GENXHHE5BGtxL5YxQPdhw== M;GNthXHHE5BGtxL5YxQPdhw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [Lime] Layer-transcending OAM? 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, 07 Mar 2015 02:26:44 -0000 On 3/5/15 9:37 PM, Loa Andersson wrote: > Erik, et.al., > > While I agree that it is proper for the LIME working group to > discuss this, the decision to create Layer-transcending OAM is not > entirely up to LIME. > > "Generic" has the implication - "for everyone to use". If you are doing > things for others to use you need to be sure that the intended users > actually want and need what you are proposing, and that it does not > cause problems for one data plane if another uses your generic model. Loa, Hopefully "generic" doesn't mean "least common denominator". If it did then someones favorite approach (such as the IP over avian carrier RFC) would then constrain too much of what you can do. Thus I think "generic" means a base class with optional components and/or behaviors. Regards, Erik > > /Loa > > On 2015-03-06 07:34, Erik Nordmark wrote: >> On 3/5/15 7:19 AM, Deepak Kumar (dekumar) wrote: >>> Hi Erik, >>> >>> Generic Yang draft for OAM is for Management and it's not enforcing or >>> proposing strict layering, filtering model. It's bringing concept of >>> Data >>> Model from Ethernet OAM but adding IP specifics for Multipath support. >>> Also it's providing way for operator to go over OAM data hierarchy if >>> present. >> >> Deepak, >> >> I haven't looked carefully at the Yang model draft to see whether it >> actually *prevents* layer-trancendence, but from the architecture/model >> discussion in Honolulu (that Norm presented) I got the impression that >> the layers are completely isolated. >> >> If the Yang draft wants to *enable* layer-trancendence, then I suspect >> it needs to have a way to configure the ttl behavior at the tunnel >> endpoints to be able to select between the pipe and uniform ttl tunnel >> models. >> >> Thus I think the LIME WG should discuss this part of the OAM model. >> >> Regards, >> Erik >> >> >>> >>> Thanks, >>> Deepak >>> >>> On 3/4/15 9:32 PM, "Erik Nordmark" wrote: >>> >>>> This draft makes 3 points: >>>> - we shouldn't hard-code a policy of layer isolation as we think >>>> about >>>> OAM for NVO3 and other encapsulations >>>> - NVO3 encaps might consider enabling the ttl behavior which enables >>>> this form of traceroute >>>> - this is easy for VXLAN encapsulation - needs a bit in the VXLAN >>>> header >>>> >>>> The first point is relevant to the OAM architecture and model >>>> discussion >>>> in LIME. >>>> In Honolulu there were comments at the mike about thinking about the >>>> Internet OAM model in addition to the Ethernet OAM model, and I think >>>> this property of traceroute is part of the Internet OAM model. >>>> >>>> I hope that first point can trigger some discussion about the model in >>>> LIME. >>>> >>>> Thanks, >>>> Erik >>>> >>>> >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: New Version Notification for >>>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>>> Date: Wed, 04 Mar 2015 18:48:12 -0800 >>>> From: internet-drafts@ietf.org >>>> To: Chandra Appanna , Erik Nordmark >>>> , Alton Lo , Alton Lo >>>> , Erik Nordmark , Chandra >>>> Appanna >>>> >>>> >>>> >>>> A new version of I-D, >>>> draft-nordmark-nvo3-transcending-traceroute-00.txt >>>> has been successfully submitted by Erik Nordmark and posted to the >>>> IETF repository. >>>> >>>> Name: draft-nordmark-nvo3-transcending-traceroute >>>> Revision: 00 >>>> Title: Layer-Transcending Traceroute for Overlay Networks like >>>> VXLAN >>>> Document date: 2015-03-02 >>>> Group: Individual Submission >>>> Pages: 18 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-nordmark-nvo3-transcending-trace >>>> >>>> >>>> route-00.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-nordmark-nvo3-transcending-tracerou >>>> >>>> >>>> te/ >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-00 >>>> >>>> >>>> >>>> >>>> Abstract: >>>> Tools like traceroute have been very valuable for the operation of >>>> the Internet. Part of that value comes from being able to display >>>> information about routers and paths over which the user of the >>>> tool >>>> has no control, but the traceroute output can be passed along to >>>> someone else that can further investigate or fix the problem. >>>> >>>> In overlay networks such as VXLAN and NVGRE the prevailing view is >>>> that since the overlay network has no control of the underlay >>>> there >>>> needs to be special tools and agreements to enable extracting >>>> traces >>>> from the underlay. We argue that enabling visibility into the >>>> underlay and using existing tools like traceroute has been >>>> overlooked >>>> and would add value in many deployments of overlay networks. >>>> >>>> This document specifies an approach that can be used to make >>>> traceroute transcend layers of encapsulation including details for >>>> how to apply this to VXLAN. The technique can be applied to other >>>> encapsulations used for overlay networks. It can also be >>>> implemented >>>> using current commercial silicon. >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> _______________________________________________ >>>> Lime mailing list >>>> Lime@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lime >>> >> >> _______________________________________________ >> Lime mailing list >> Lime@ietf.org >> https://www.ietf.org/mailman/listinfo/lime > From nobody Mon Mar 23 12:15: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 0E13C1AD47E for ; Mon, 23 Mar 2015 12:15:15 -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 qCALLZXhGpcH for ; Mon, 23 Mar 2015 12:15:13 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703011AD376 for ; Mon, 23 Mar 2015 12:15:13 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 23 Mar 2015 19:14:52 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.69]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.69]) with mapi id 15.01.0118.021; Mon, 23 Mar 2015 19:14:52 +0000 From: Ronald Bonica To: "lime@ietf.org" Thread-Topic: IETF 92 Thread-Index: AdBlnYfQIVJ97NF8Q3azGstHZN4b0A== Date: Mon, 23 Mar 2015 19:14:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(92566002)(76576001)(102836002)(122556002)(50986999)(99286002)(110136001)(2900100001)(46102003)(33656002)(66066001)(40100003)(2351001)(62966003)(107886001)(77156002)(450100001)(229853001)(2501003)(54356999)(2656002)(74316001)(87936001)(86362001)(558084003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB443; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; x-forefront-prvs: 05245CA661 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: 23 Mar 2015 19:14:51.8156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 Archived-At: Subject: [Lime] IETF 92 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, 23 Mar 2015 19:15:15 -0000 Folks, Would anyone be willing to serve as scribe or jabber scribe for tomorrow's = meeting? Ron Bonica From nobody Mon Mar 23 12:23:24 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 E2EFC1B29B9 for ; Mon, 23 Mar 2015 12:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 EyxUe_h_S0O2 for ; Mon, 23 Mar 2015 12:23:16 -0700 (PDT) Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 170871A00F5 for ; Mon, 23 Mar 2015 12:22:54 -0700 (PDT) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Ya7w5-0003wW-B2; Mon, 23 Mar 2015 19:22:53 +0000 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0224.002; Mon, 23 Mar 2015 19:22:44 +0000 From: "King, Daniel" To: Ronald Bonica Thread-Topic: IETF 92 Thread-Index: AdBlnYfQIVJ97NF8Q3azGstHZN4b0AAAQsNA Date: Mon, 23 Mar 2015 19:22:43 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A323F53B5@EX-0-MB2.lancs.local> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.207.28.190] x-iss-local-domain: 1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lime@ietf.org" Subject: Re: [Lime] IETF 92 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, 23 Mar 2015 19:23:18 -0000 Hi Ron. +1 Scribe here.=20 BR, Dan.=20 -----Original Message----- From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: 23 March 2015 14:15 To: lime@ietf.org Subject: [Lime] IETF 92 Folks, Would anyone be willing to serve as scribe or jabber scribe for tomorrow's = meeting? Ron Bonica _______________________________________________ Lime mailing list Lime@ietf.org https://www.ietf.org/mailman/listinfo/lime