From balajivenkat@force10networks.com Tue May 8 07:14:15 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D3221F85E3 for ; Tue, 8 May 2012 07:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXdjoCCx3ZZG for ; Tue, 8 May 2012 07:14:14 -0700 (PDT) Received: from mx.force10networks.com (maa.force10networks.com [59.163.202.254]) by ietfa.amsl.com (Postfix) with ESMTP id 40F1521F8653 for ; Tue, 8 May 2012 07:14:14 -0700 (PDT) Received: from EXCH-CLUSTER-11.force10networks.com ([10.16.127.21]) by exch7-maa-fe.force10networks.com ([10.16.126.10]) with mapi; Tue, 8 May 2012 19:44:09 +0530 From: Balaji Venkat Venkataswami To: "opsawg@ietf.org" Date: Tue, 8 May 2012 19:44:06 +0530 Thread-Topic: New Version Notification for draft-janapath-opsawg-flowoam-req-00.txt Thread-Index: Ac0s+Ermvdd6tgQzSEGk0njzc6C2+AAK/bRg Message-ID: <5EC91DDA759C324DB62C5A5F7B4922193CC8390459@EXCH-CLUSTER-11.force10networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "phoose@fb.com" Subject: [OPSAWG] FW: New Version Notification for draft-janapath-opsawg-flowoam-req-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 14:14:15 -0000 RGVhciBhbGwsDQoNCkVhcmxpZXIgaW4gdGhlIG1vbnRoIG9mIEZlYnJ1YXJ5IDIwMTIgYSBncm91 cCBvZiBhdXRob3JzIGZyb20gTWljcm9zb2Z0LCBGYWNlYm9vayBhbmQgREVMTCBoYWQgcHVibGlz aGVkDQphIGRyYWZ0IGZvciBhIG1lY2hhbmlzbSBuYW1lZCBUcmFjZWZsb3cgKHdoaWNoIGhhZCBz ZWVuIGFuIGVhcmxpZXIgaW5jYXJuYXRpb24gaW4gMjAwOCkuIEFmdGVyIHN1YnNlcXVlbnQNCmRp c2N1c3Npb25zIHdpdGggUm9uIEJvbmljYSBhbmQgTWVsaW5kYSBTaG9yZSBhbmQgYSBwcmVzZW50 YXRpb24gb2YgVHJhY2VmbG93IGluIElFVEY4MyBpbiBQYXJpcywgaXQgd2FzDQpkZWNpZGVkIHRv IHB1Ymxpc2ggYSBzZXQgb2YgcmVxdWlyZW1lbnRzIHJhdGhlciB0aGFuIGEgdG9vbCBzcGVjaWZp Y2F0aW9uIGl0c2VsZi4gU28gd2UgaGF2ZSBzcGxpdCB0aGUNCnJlcXVpcmVtZW50cyBzZXBhcmF0 ZWx5IGFuZCBhcmUgcHVibGlzaGluZyB0aGUgZm9sbG93aW5nIGVuY2xvc2VkIGRyYWZ0IGZvciB5 b3VyIGtpbmQgcGVydXNhbCBhbmQgcmV2aWV3Lg0KDQpZb3VyIGNvbGxlY3RpdmUgZmVlZGJhY2sg b24gdGhlIHByb3Bvc2FsIGlzIG1vc3Qgd2VsY29tZS4gVGhpcyBtYWlsIGlzIHRvIGluaXRpYXRl IHRoYXQgbmVlZGVkIGRpc2N1c3Npb24NCm9uIHRoZSBzdWJqZWN0LiANCg0KdGhhbmtzIGFuZCBy ZWdhcmRzLA0KVHJhY2VmbG93IHRlYW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQpTZW50OiBUdWVzZGF5LCBNYXkgMDgsIDIwMTIgMjoyNSBQTQ0KVG86IGJhbGFqaV92 ZW5rYXRfdmVua2F0QGRlbGwuY29tDQpDYzogcGF0aGFuZ2lfamFuYXJkaGFuYW5AZGVsbC5jb207 IHBob29zZUBmYi5jb207IHJncm92ZXNAbWljcm9zb2Z0LmNvbQ0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qYW5hcGF0aC1vcHNhd2ctZmxvd29hbS1yZXEtMDAu dHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qYW5hcGF0aC1vcHNhd2ctZmxvd29h bS1yZXEtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmFsYWppIFZl bmthdCBWZW5rYXRhc3dhbWkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpG aWxlbmFtZToJIGRyYWZ0LWphbmFwYXRoLW9wc2F3Zy1mbG93b2FtLXJlcQ0KUmV2aXNpb246CSAw MA0KVGl0bGU6CQkgUmVxdWlyZW1lbnRzIGZvciBPQU0gdG9vbHMgdGhhdCBlbmFibGUgZmxvdyBB bmFseXNpcw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDUtMDgNCldHIElEOgkJIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgKE9BTSkgcmVxdWlyZW1l bnRzDQogICB0aGF0IGltcHJvdmUgb24gdGhlIHRyYWRpdGlvbmFsIE9BTSB0b29scyBsaWtlIFBp bmcgYW5kICBUcmFjZXJvdXRlLg0KICAgVGhlc2UgcmVxdWlyZW1lbnRzIGhhdmUgYXJpc2VuIGZy b20gdGhlIGZhY3QgdGhhdCBtb3JlIGRldGFpbHMgdGhhbg0KICAgZ2l2ZW4gYnkgUGluZyBhbmQg VHJhY2Vyb3V0ZSBhcmUgcmVxdWlyZWQgd2hpbGUgdHJvdWJsZXNob290aW5nIG9yDQogICBkb2lu ZyBwZXJmb3JtYW5jZSBhbmQgbmV0d29yayBwbGFubmluZy4gVGhlc2UgcmVxdWlyZW1lbnRzIGhh dmUgYmVlbg0KICAgZ2F0aGVyZWQgZnJvbSBuZXR3b3JrIG9wZXJhdG9ycyBlc3BlY2lhbGx5IGZy b20gZGF0YSBjZW50ZXJzIHdoZXJlDQogICB0aGUgbmV0d29ya3MgaGF2ZSBzbGlnaHRseSBkaWZm ZXJlbnQgY2hhcmFjdGVyaXN0aWNzIGNvbXBhcmVkIHRvDQogICByZWd1bGFyIGNhbXB1cy9jYXJy aWVyIG5ldHdvcmtzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg== From vumip1@gmail.com Fri May 11 14:04:45 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1AB21F85FC; Fri, 11 May 2012 14:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoYYYECbZDlr; Fri, 11 May 2012 14:04:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 15D3C21F85E7; Fri, 11 May 2012 14:04:44 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4501710obb.31 for ; Fri, 11 May 2012 14:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XTSXnf3kjHL7oPeQEZccX/AI4eNlwmsuUCGZLcWlpc8=; b=jaFX9uUOeb/AUA2SXpEiCeFFqhlC2azxhREcuSQ3IFPZD3M5QDUrEfnTvVgOLn4g/c hcAPkOCZHYrKxAj/MMIGhU2cJKzhX/hOhxU7/8H32KN73who8Faf14Jh4cJXWBefctpV B7d1VPcKTZMO0dN/7jtb//NzNKZDv/PUg1PheXc1iBPj/zs9RRghQWgDDBaiFIkHnIRC lKUyIPJrb8RetoTGxcb8ucaD+GKhzHF/6vp2ScoYUTZT07qv/MpzBlaL/3NCpH5QGMOL da1DMt0rW+BQZ41tM/O3sucOWvTJvTc344L2Van0rb0ya+QwS6AZpCt57/3vQhjlD7KU IidQ== MIME-Version: 1.0 Received: by 10.182.167.104 with SMTP id zn8mr13388696obb.62.1336770283631; Fri, 11 May 2012 14:04:43 -0700 (PDT) Received: by 10.182.32.42 with HTTP; Fri, 11 May 2012 14:04:43 -0700 (PDT) Date: Fri, 11 May 2012 17:04:43 -0400 Message-ID: From: Bhumip Khasnabish To: nvo3@ietf.org, opsawg@ietf.org Content-Type: multipart/alternative; boundary=e89a8f13ec66e6f3b904bfc915f5 Subject: [OPSAWG] Fwd: a draft on PSN Independent Overlay Network(PION) Architecture X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:04:45 -0000 --e89a8f13ec66e6f3b904bfc915f5 Content-Type: text/plain; charset=ISO-8859-1 Dear All, We have recently published an IETF draft ( http://www.ietf.org/id/draft-kj-nvo3-pion-architecture-00.txt) discussing packet switched network (PSN) independent overlay network (PION) architecture for intra- and inter-datacenter (DC) connections. Please see below for further details. Looking forward to your comments and suggestions. Thanks. Best. Bhumip (vumip1@gmail.com), and LiZhong (lizho.jin@gmail.com) ============================================================ I-D Action: draft-kj-nvo3-pion-architecture-00.txt ------------------------------ - *To*: i-d-announce at ietf.org - *Subject*: I-D Action: draft-kj-nvo3-pion-architecture-00.txt - *From*: internet-drafts at ietf.org - *Date*: Fri, 11 May 2012 07:11:17 -0700 - *Delivered-to*: i-d-announce at ietfa.amsl.com - *List-archive*: - *List-help*: > - *List-id*: Internet Draft Announcements only - *List-post*: > - *List-subscribe*: , > - *List-unsubscribe*: , > - *Reply-to*: internet-drafts at ietf.org ------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Architecture of PSN Independent Overlay Network(PION) Author(s) : Lizhong Jin Bhumip Khasnabish Filename : draft-kj-nvo3-pion-architecture-00.txt Pages : 12 Date : 2012-05-11 This draft introduces PSN independent overlay network (PION) architecture for intra- and inter-datacenter (DC) connections. The motivations, protocol layers, applications, and etc, for PION are also discussed. PION provides a virtualized underlying-PSN- independent network in order to maximize the reuse of IETF protocol definitions and implementations. The inter- and intra-DC connection provided by PION could be from endpoint to endpoint, or endpoint to network, or network to network. The packet transport capabilities provided by the overlay network are determined by the capability of the underlying PSN. A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-kj-nvo3-pion-architecture-00.txt Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at:ftp://ftp.ietf.org/internet-drafts/draft-kj-nvo3-pion-architecture-00.txt The IETF datatracker page for this Internet-Draft is:https://datatracker.ietf.org/doc/draft-kj-nvo3-pion-architecture/ --e89a8f13ec66e6f3b904bfc915f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,
=A0
We have recently published an IETF draft (http://www.= ietf.org/id/draft-kj-nvo3-pion-architecture-00.txt)
discussing packet switched network (PSN) independent
overlay network (PION) architecture for intra- and inter-datacenter (D= C) connections.
=A0
Please see below for further details.
=A0
Looking forward to your comments and suggestions. Thanks.
=A0
Best.
=A0
Bhumip (vumip1@gmail.com), and=

=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I-D Action: draft-kj-nvo3-pion-architecture-00.txt

 
A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

	Title           : Architecture of PSN Independent Overlay Network(PION)
	Author(s)       : Lizhong Jin
                          Bhumip Khasnabish
	Filename        : draft-kj-nvo3-pion-architecture-00.txt
	Pages           : 12
	Date            : 2012-05-11

   This draft introduces PSN independent overlay network (PION)
   architecture for intra- and inter-datacenter (DC) connections.  The
   motivations, protocol layers, applications, and etc, for PION are
   also discussed.  PION provides a virtualized underlying-PSN-
   independent network in order to maximize the reuse of IETF protocol
   definitions and implementations.  The inter- and intra-DC connection
   provided by PION could be from endpoint to endpoint, or endpoint to
   network, or network to network.  The packet transport capabilities
   provided by the overlay network are determined by the capability of
   the underlying PSN.


A URL for this Internet-Draft is:
http://www.ietf.org/internet=
-drafts/draft-kj-nvo3-pion-architecture-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-d=
rafts/draft-kj-nvo3-pion-architecture-00.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draf=
t-kj-nvo3-pion-architecture/
--e89a8f13ec66e6f3b904bfc915f5-- From acmorton@att.com Sun May 13 10:06:41 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC0521F8554; Sun, 13 May 2012 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.394 X-Spam-Level: X-Spam-Status: No, score=-105.394 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qINOSR6QlAXb; Sun, 13 May 2012 10:06:40 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 955F721F854F; Sun, 13 May 2012 10:06:40 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id f1aefaf4.0.36946.00-490.93934.nbfkord-smmo03.seg.att.com (envelope-from ); Sun, 13 May 2012 17:06:40 +0000 (UTC) X-MXL-Hash: 4fafea203fee9d1e-b683bccbe4e07f07206b7c4c1ae0dc5b40a4547b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4DH6cCC030786; Sun, 13 May 2012 13:06:39 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4DH6WMY030756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 May 2012 13:06:35 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint03.pst.cso.att.com (RSA Interceptor); Sun, 13 May 2012 13:06:13 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4DH6CZi011344; Sun, 13 May 2012 13:06:12 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4DH66I7010967; Sun, 13 May 2012 13:06:07 -0400 Message-Id: <201205131706.q4DH66I7010967@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-175-94.vpn.mwst.att.com[135.70.175.94](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120513170235gw10060l36e>; Sun, 13 May 2012 17:02:41 +0000 X-Originating-IP: [135.70.175.94] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 13 May 2012 13:06:56 -0400 To: "Aamer Akhter (aakhter)" From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=Vt2btoSP3IcA:10 a=jZD9Sfm6waUA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=eRgcI_ov3eUA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:1] X-AnalysisOut: [0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=48vgC7mUAAAA:8 a=YVutamS] X-AnalysisOut: [Y1dF6Lui1zDcA:9 a=twHSKHTm3m0CHogLfp4A:7 a=CjuIK1q_8ugA:10] X-AnalysisOut: [ a=aFSRYU0w_9zJEdOb:21 a=b84Q6Pqyg_Cl9GAn:21] Cc: opsawg@ietf.org, ipfix@ietf.org Subject: [OPSAWG] Comments on draft-akhter-opsawg-perfmon-method-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 17:06:41 -0000 Hi Aamer, I finally made some time to review one of your drafts: http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-method-02 and comments follow below. Not sure exactly which list will be best, so I CC'd ipfix and opsawg. hope this helps, Al -=-=-=-=-=-=-=-=-=-=-=-=-=- Main Comments: 1. Packet Loss Calculation Method (4.1.1) Each metric has a paragraph labeled Calculation Method, but they contain a useful discussion of the possible issues instead. Many details are left to the implementor, with the likely outcome that different implementations will produce different results. For example, "synchronization" is mentioned many times, but what does this process entail? Try to minimize interpretation, perhaps by including a high-level step-by-step procedure for processing each arriving packet, both during initiation (synchronization, when the first few packets arrive) and steady-state processing (which involves using the info from sync). Since this draft is proposed for the Standards Track, it really needs to provide definitions that will stand-up to scrutiny of multiple implementations. 2. Packet Loss "Rate" (4.1.3) This metric is really a Statistic, or a metric derived from the fundamental metrics of Packet Loss and Expected Packet (counts) over a particular measurement interval. Thus, there's no need to talk about measurement points, you've already defined these in the Loss and Expected metrics. Also, this is more accurately named "Loss Ratio", especially when expressed as a percentage as you've done. 3. Jitter (4.1.5 and beyond) This metric will disappoint for use in SLAs or de-jitter buffer sizing if it is based on the RFCC3550 smoothed jitter calculation. Regardless of the measurement interval, only the last 16 packets have any influence over the current value (which is your Average?) General Editorial: There are a number of sentences that seem to contain alternate wordings, as though some deleted text returned somehow. Also, running a spell-check will help. Specific comments follow: 3.1. Quality of Service (QoS) Monitoring The network operator needs to be able to gauge the end user's satisfaction with the network service. While there are many components of the satisfaction such as pricing, packaging, offering, etc., a major component of satisfaction is delivering a consistent service. Consistent Service in what dimensions? Is Service Performance meant here? 4. New Information Elements The information elements are organized into two main groups: Transport Layer: Metrics that might be calculated from observations at higher layers but essentially provide information about the network transport of user date. s/date/data/ 4.1.1. perfPacketLoss Name: perfPacketLoss In this section, s/loss packet/lost packet/ Also, what is the 5-tuple? SSRC + Src IP and Port + Dst IP and Port? At the end: Measurment Timing To be able to calculate this metric a continuous set of the flow's packets (as each would have an incrementing sequence number) needs to be monitored. Therefore, per-packet sampling would prevent this metric from being calculated. s/per-packet/sub-rate/ ?? 4.1.2. perfPacketExpected Name: perfPacketExpected ... Use and Applications The perfPacketExpected is a mid-calculation metric used in the generation of perfPacketLossRate. It is equivilent to the highest received packet sequence number at the time of measurement. True when there is no roll-over in Seq numbers. ... As the value only increments when packets are received, packet loss may be occouring at the time of measurement but perfPacketExpected remains constant. This is an issue worth mitigating, some sort of average packet rate could be used to estimate the number of losses while the Expected count remains constant. Calculation Method: The subtraction of the last sequence number from the first sequence number in monitoring interval yields the expected count. As discussed with perfPacketLost, there might be a delay due to synchronization with the flow's sequence numbers and in such times the value of the metric should be set to 0xFFFFFFFE. Care has to be taken to account for cases where the packet's sequence number field wraps. This is an opportunity for more specifics, as an example (I didn't check the Appendix 3 reference, no access today...) 4.1.3. perfPacketLossRate Name: perfPacketLossPercentage These aren't the same! Which is it? 4.1.4. perfPacketLossEvent Name: perfPacketLossEvent Need "consecutive" in the name, or some other way to distinguish single losses from "bursts". ... Calculation Method: This data value is a simplified version of the Lost Packets metric. Whereas Lost Packets counts individual packet loss, the 'loss event count' metric counts sets of packets that are lost. For example, in the case of a sequence of packets: 1,3,6,7,10 the packets marked 2,4,5,8 and 9 are lost. So, a total How long does the process wait to make the lost determination? 4.1.5. perfPacketInterArrivalJitterAvg Name: perfPacketInterArrivalJitterAvg Description: This metric measures the absolute deviation of the difference in packet spacing at the measurement point compared to the packet spacing at the sender. I don't think that's what 3550 Jitter does... ... Use and Applications The inter arrival jitter data value can be used be network operator to determine the network's impact to the spacing in between a media stream's packets as they traverse the network. What about Source Jitter? this can be very significant, more than network. Again, Min and Max are statistics. 4.2. User and Application Layer 4.2.1. perfSessionSetupDelay Name: perfSessionSetupDelay This seems to be the only two-point metric, worth noting. and [I-D.ietf-pmol-sip-perf-metrics] is an RFC now (which mostly defined metrics, not methods). From internet-drafts@ietf.org Mon May 14 21:33:10 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D007D11E807F; Mon, 14 May 2012 21:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZNO5EBrtcNv; Mon, 14 May 2012 21:33:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3E321F847E; Mon, 14 May 2012 21:33:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120515043307.17124.13290.idtracker@ietfa.amsl.com> Date: Mon, 14 May 2012 21:33:07 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-lsn-deployment-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 04:33:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Workin= g Group Working Group of the IETF. Title : CGN Deployment with BGP/MPLS IP VPNs Author(s) : Victor Kuarsingh John Cianfarani Filename : draft-ietf-opsawg-lsn-deployment-00.txt Pages : 18 Date : 2012-05-14 This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). CGN is a concept also described in [I-D.ietf-behave-lsn-requirements] and describes the model as a dual layer translation model. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows CGN to be integrated into the network meeting the connectivity needs of the customer while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model includes the use of BGP/MPLS IP VPNs defined in [RFC4364] as a tool to achieve this goal. This document does not intend to defend the merits of CGN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-lsn-deployment-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsawg-lsn-deployment-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ From victor.kuarsingh@gmail.com Sun May 20 06:36:18 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD3621F8554; Sun, 20 May 2012 06:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDGuRb-0kPe7; Sun, 20 May 2012 06:36:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE8721F854E; Sun, 20 May 2012 06:36:17 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so8285338obb.31 for ; Sun, 20 May 2012 06:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=xCWgGwqLK41BY1MTkTrEiuFee+Ccbjp60iKjfO720XE=; b=g8nyvD461P/IlLC4Z02+eMz1VMHvbB1wqLdy/i8YSo8sLT8xWDHGyGyuOqtO7NBDhO IbsKEq8vyna6OC0qemJ83wujCNHa8HfuqJlwQshQbjm33DUB2jySsgnWjNgMTeSqOdEi w32+gvf4esoLAyIyIfYG0pUOsHnlHpOgfSq0WM2n7cfuxMAVkuBI+/ln56B229SrR3MW ECHC3uu9dl/weXC1usIn2V9wOLYtmqtBeEWrijTamzi+gzLg0Rb453P2ckQGSvCzMmdg v7WKrjuEo9SJjQueLT64ZUT8VqwuHrxa2FgrDyNlQ8+kpg7ZMc9NqicwDQGHAcZvnql4 pZXQ== Received: by 10.50.202.100 with SMTP id kh4mr4596919igc.43.1337520976875; Sun, 20 May 2012 06:36:16 -0700 (PDT) Received: from [192.168.1.2] ([74.198.164.15]) by mx.google.com with ESMTPS id yg9sm5162757igb.15.2012.05.20.06.36.11 (version=SSLv3 cipher=OTHER); Sun, 20 May 2012 06:36:15 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 20 May 2012 09:36:05 -0400 From: Victor Kuarsingh To: , Message-ID: Thread-Topic: [OPSAWG] LSN Deployment Draft Feedback Request In-Reply-To: <20120515043307.17124.13290.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: opsawg@ietf.org Subject: [OPSAWG] LSN Deployment Draft Feedback Request X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 13:36:18 -0000 WG, I am looking to make improvements and mature this draft with the assistance of the working group. As a start, I was thinking that the current section 7 (labeled performance) should be replaced with references to other documents which cover this topic. When we/I first started this draft, there was far less reference material, so inclusion was made directly into this document. Any nay or ayes on this approach? Again this draft was less about CGN/NAT444 justification and more about how to implement it with BGP/MPLS IP VPNs (RFC4364). Other comments welcome. Document Reference: http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-00 Regards, Victor K On 12-05-15 12:33 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the Operations and Management >Area Working Group Working Group of the IETF. > > Title : CGN Deployment with BGP/MPLS IP VPNs > Author(s) : Victor Kuarsingh > John Cianfarani > Filename : draft-ietf-opsawg-lsn-deployment-00.txt > Pages : 18 > Date : 2012-05-14 > > This document specifies a framework to integrate a Network Address > Translation layer into an operator's network to function as a Carrier > Grade NAT (also known as CGN or Large Scale NAT). CGN is a concept > also described in [I-D.ietf-behave-lsn-requirements] and describes > the model as a dual layer translation model. Although operators may > wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near > term needs may not be satisfied with an IPv6 deployment alone. This > document provides a practical integration model which allows CGN to > be integrated into the network meeting the connectivity needs of the > customer while being mindful of not disrupting existing services and > meeting the technical challenges that CGN brings. The model includes > the use of BGP/MPLS IP VPNs defined in [RFC4364] as a tool to achieve > this goal. This document does not intend to defend the merits of > CGN. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-opsawg-lsn-deployment-00.tx >t > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsawg-lsn-deployment-00.txt > >The IETF datatracker page for this Internet-Draft is: >https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From surenck@gmail.com Mon May 21 17:57:28 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA2021F85A1; Mon, 21 May 2012 17:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIRuQxvGRy4g; Mon, 21 May 2012 17:57:27 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9C5721F8569; Mon, 21 May 2012 17:57:22 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4440164qcs.31 for ; Mon, 21 May 2012 17:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=pNK8gEqjsYvVQaZaKe1ryUySoP+jPfELmzKTVFfOE4E=; b=eu5LSAUJnfkER+zPFPJdxad/25hIzyEF8qxuhvg9jkyl/er80ktrMZTf3Jmj2y2PSK 8XvS37KgGQ9b/qmB9DgOIJrVJ3YjLz7iYnPWcowxPOKt1LqxNScdAFaZy6lgA/KmT4i1 Orvxm9CaXOmR1UZ0HroNa65wAqukl5DMpbXeSYNHtxfiGEgmxYjZ/r1l4oSkXeFpaLh6 mphdsjJbrrfIddFM74i1Pcw7/tIGGjo/HuroyS2ezJ4mxwPlKa0Te6hgjwj5TeIfecna QI9locV6XRIL5ruGvKXHcrQF4aAMKbY0BQHufFcsuaIRCLdEdE4d6jUjE9tbMpowz8CR d4pA== Received: by 10.229.136.66 with SMTP id q2mr11082811qct.32.1337648242183; Mon, 21 May 2012 17:57:22 -0700 (PDT) Received: from TRAYAATESURENK (c-24-147-245-141.hsd1.ma.comcast.net. [24.147.245.141]) by mx.google.com with ESMTPS id gw2sm42269429qab.10.2012.05.21.17.57.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 May 2012 17:57:20 -0700 (PDT) From: "Suren Karavettil" To: , , , References: In-Reply-To: Date: Mon, 21 May 2012 20:57:24 -0400 Message-ID: <005001cd37b5$daf6fb80$90e4f280$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01CD3794.53E55B80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0SgPdvFz4TADxpRGyKOPN6fV7xuQlMyQLw Content-Language: en-us Cc: wei.dong@tek.com, ning.so@tatacommunications.com Subject: [OPSAWG] Virtual Data Center Security Framework - Informational Draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 00:57:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0051_01CD3794.53E55B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'm in the process of getting this Information Draft for the Cloud Security Framework in a Virtual Data Center Operations updated in the next 2-3 weeks. The security concepts and areas are equally applicable in the network, systems and applications environment. I would like hear from members who like to share their ideas in the security area (specifically how it would impact the Cloud) and interested in contributing to this Draft. IETF draft URL: http://tools.ietf.org/html/draft-karavettil-vdcs-security-framework-03 Please reach out to anyone of the authors listed in cc. Look forward to hearing from the team members. Thank you. -- Best Regards, Suren Karavettil 978-857-5461 surenck@gmail.com http://www.linkedin.com/in/skaravettil ------=_NextPart_000_0051_01CD3794.53E55B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I’m in the = process of getting this Information Draft for the Cloud Security = Framework in a Virtual Data Center Operations updated in the next 2-3 = weeks. The security concepts and areas are equally applicable in the = network, systems and applications environment.

 

I would like hear = from members who like to share their ideas in the security area = (specifically how it would impact the Cloud) and interested in = contributing to this Draft.

 

 

Please reach out to anyone of the authors listed in = cc. Look forward to hearing from the team members.

 

Thank = you.

 

-- =

Best Regards,
Suren = Karavettil
978-857-5461
surenck@gmail.com

http://www.linkedin.com/in/skaravettil=

 <= /o:p>

------=_NextPart_000_0051_01CD3794.53E55B80-- From narten@us.ibm.com Thu May 24 09:14:50 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AF821F8525 for ; Thu, 24 May 2012 09:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq8EFoWUNs7R for ; Thu, 24 May 2012 09:14:49 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7806721F8491 for ; Thu, 24 May 2012 09:14:49 -0700 (PDT) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 24 May 2012 10:14:48 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 24 May 2012 10:14:34 -0600 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 3B7423E4004F for ; Thu, 24 May 2012 10:14:32 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4OGDuTt018412 for ; Thu, 24 May 2012 10:14:16 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4OGDqSF004078 for ; Thu, 24 May 2012 10:13:52 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-49-149-83.mts.ibm.com [9.49.149.83]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q4OGDoLN003950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 May 2012 10:13:51 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q4OGDXrj028911 for ; Thu, 24 May 2012 12:13:33 -0400 Message-Id: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com> To: opsawg@ietf.org Date: Thu, 24 May 2012 12:13:32 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12052416-3270-0000-0000-0000069DA51B Subject: [OPSAWG] definitions of continuity and connectivity X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 16:14:50 -0000 Hi. In developing requirements for TRILL OAM (e.g., draft-tissa-trill-oam-req-01.txt), we've had some difficulty finding standard/crisp definitions of some well known terms. Specifically: Reachability: [is there an existing definition we can use?] Continuity: [is there an existing definition we can use?] Liveness: [is there an existing definition we can use?] I would have expected to be able to reuse existing definitions of such terms, but have not been successful. draft-ietf-opsawg-oam-overview-06.txt says (in 2.2.5) > 2.2.5. Connectivity Verification and Continuity Checks > > Two distinct classes of failure management functions are used in OAM > protocols, connectivity verification and continuity checks. The > distinction between these terms is defined in [MPLS-TP OAM], and is > used similarly in this document. But, the MPLS-TP OAM document (RFC 5860 " Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks") has no such definitions. Indeed, the defintions and usages seem to be a bit circular. E.g.: > 2.2.2. Continuity Checks > > The MPLS-TP OAM toolset MUST provide a function to enable an End > Point to monitor the liveness of a PW, LSP, or Section. And that is pretty much all it says. Morever the term "liveness" is not defined in RFC 5860 (or draft-ietf-opsawg-oam-overview-06.txt) RFC 5860 also says: > 2.2.3. Connectivity Verifications > > The MPLS-TP OAM toolset MUST provide a function to enable an End > Point to determine whether or not it is connected to specific End > Point(s) by means of the expected PW, LSP, or Section. But also does not define what connectivity means. Are there standard definitions for the terms "continuity", "connectivity" and "liveness"? Thomas From linda.dunbar@huawei.com Thu May 24 09:45:12 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B8C21F8480 for ; Thu, 24 May 2012 09:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLJzddssVhTO for ; Thu, 24 May 2012 09:45:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF8221F847F for ; Thu, 24 May 2012 09:45:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGM63589; Thu, 24 May 2012 12:45:10 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 09:43:15 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 24 May 2012 09:43:17 -0700 From: Linda Dunbar To: Thomas Narten , "opsawg@ietf.org" Thread-Topic: [OPSAWG] definitions of continuity and connectivity Thread-Index: AQHNOchfgZgXdZXbNkmZM0l/ZYbvY5bZIxOg Date: Thu, 24 May 2012 16:43:17 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F633936092@dfweml506-mbx> References: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com> In-Reply-To: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.216] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OPSAWG] definitions of continuity and connectivity X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 16:45:12 -0000 Thomas,=20 IEEE802.1Q - 2011 has this definition: "3.37 Connectivity Fault Management (CFM): Connectivity Fault Management co= mprises capabilities for detecting, verifying, and isolating connectivity f= ailures in Virtual Bridged Local Area Networks." If you really want to define "connectivity", you can use the description by= Merriam Webster Dictionary:=20 the quality, state, or capability of being connective or connected ; especially : the ability to connect to or communicate= with another computer or computer system For " Continuity check", IEEE802.1Q has this definition:=20 "3.38 Continuity Check Message (CCM): A multicast CFM PDU transmitted perio= dically by a MEP in order to ensure continuity over the MA to which the tra= nsmitting MEP belongs. No reply is sent by any MP in response to receiving = a CCM." =20 Linda=20 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Thomas Narten > Sent: Thursday, May 24, 2012 11:14 AM > To: opsawg@ietf.org > Subject: [OPSAWG] definitions of continuity and connectivity >=20 > Hi. >=20 > In developing requirements for TRILL OAM (e.g., > draft-tissa-trill-oam-req-01.txt), we've had some difficulty finding > standard/crisp definitions of some well known terms. Specifically: >=20 >=20 > Reachability: [is there an existing definition we can use?] >=20 > Continuity: [is there an existing definition we can use?] >=20 > Liveness: [is there an existing definition we can use?] >=20 > I would have expected to be able to reuse existing definitions of such > terms, but have not been successful. >=20 > draft-ietf-opsawg-oam-overview-06.txt says (in 2.2.5) >=20 > > 2.2.5. Connectivity Verification and Continuity Checks > > > > Two distinct classes of failure management functions are used in > OAM > > protocols, connectivity verification and continuity checks. The > > distinction between these terms is defined in [MPLS-TP OAM], and > is > > used similarly in this document. >=20 > But, the MPLS-TP OAM document (RFC 5860 " Requirements for Operations, > Administration, and Maintenance (OAM) in MPLS Transport Networks") has > no such definitions. Indeed, the defintions and usages seem to be a > bit circular. E.g.: >=20 > > 2.2.2. Continuity Checks > > > > The MPLS-TP OAM toolset MUST provide a function to enable an End > > Point to monitor the liveness of a PW, LSP, or Section. >=20 > And that is pretty much all it says. Morever the term "liveness" is > not defined in RFC 5860 (or draft-ietf-opsawg-oam-overview-06.txt) >=20 > RFC 5860 also says: >=20 > > 2.2.3. Connectivity Verifications > > > > The MPLS-TP OAM toolset MUST provide a function to enable an End > > Point to determine whether or not it is connected to specific End > > Point(s) by means of the expected PW, LSP, or Section. >=20 > But also does not define what connectivity means. >=20 > Are there standard definitions for the terms "continuity", > "connectivity" and "liveness"? >=20 > Thomas >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From narten@us.ibm.com Thu May 24 12:56:06 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AB911E8097 for ; Thu, 24 May 2012 12:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR-an29mCIT0 for ; Thu, 24 May 2012 12:56:05 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0C011E8086 for ; Thu, 24 May 2012 12:56:05 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 24 May 2012 15:56:04 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 24 May 2012 15:55:59 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 5E41A38C8052 for ; Thu, 24 May 2012 15:55:58 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4OJtwNx064236 for ; Thu, 24 May 2012 15:55:58 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4OJtvqu002428 for ; Thu, 24 May 2012 16:55:58 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-49-149-83.mts.ibm.com [9.49.149.83]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q4OJtuvp002117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 May 2012 16:55:56 -0300 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q4OJtreh030888; Thu, 24 May 2012 15:55:55 -0400 Message-Id: <201205241955.q4OJtreh030888@cichlid.raleigh.ibm.com> To: Linda Dunbar In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F633936092@dfweml506-mbx> References: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F633936092@dfweml506-mbx> Comments: In-reply-to Linda Dunbar message dated "Thu, 24 May 2012 16:43:17 -0000." Date: Thu, 24 May 2012 15:55:53 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12052419-9360-0000-0000-000006A954CA Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] definitions of continuity and connectivity X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:56:06 -0000 Linda Dunbar writes: > IEEE802.1Q - 2011 has this definition: > "3.37 Connectivity Fault Management (CFM): Connectivity Fault > Management comprises capabilities for detecting, verifying, and > isolating connectivity failures in Virtual Bridged Local Area > Networks." > If you really want to define "connectivity", you can use the > description by Merriam Webster Dictionary: the quality, state, > or capability of being connective or connected of a surface>; especially : the ability to connect to or > communicate with another computer or computer system I want a definition that makes sense for networking, and TRILL in particular. Does saying A & B are "connected" mean the same thing as B is reachable from A? That if A sends a packet to B, there is a working path? And does it mean there is a two-way path between A&B, or just that a one-way path exists and works? > For " Continuity check", IEEE802.1Q has this definition: > "3.38 Continuity Check Message (CCM): A multicast CFM PDU > transmitted periodically by a MEP in order to ensure continuity > over the MA to which the transmitting MEP belongs. No reply is > sent by any MP in response to receiving a CCM." That is a circular definition... What does continuity mean? How does continuity differ from connectivity (if the above definition is correct)? Thomas From melinda.shore@gmail.com Thu May 24 13:02:03 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA4411E8097 for ; Thu, 24 May 2012 13:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLSLjcALHLG9 for ; Thu, 24 May 2012 13:02:02 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8AA11E8086 for ; Thu, 24 May 2012 13:02:02 -0700 (PDT) Received: by dacx6 with SMTP id x6so215538dac.31 for ; Thu, 24 May 2012 13:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ELQzAa1TPROKdlZX5SPzHCCLEhdiLB+FUS9ttpOppH4=; b=MVbOm/9iJap9FdT35x0m/NnnU11I6NgKU+o/mLPUNnVVfK7RfDvrSbgIAyBnL58y9p foaK6ZGcQ4Gn+jFVPbTCG94fVp6SaosTgbcQjMjKNfIDq7dNSaySsG8yjHlx8+LkN1MV cYPxhvOebfgFK2g5o8Vf3NiFdTHtCl+k9ELWe4HRVi/FpEWSmBpKRmg9uzMIzi0mUuQE dxIZXahWrlvV7AAkwLnvaKLXxF8Y/kYMqazPx6Ctn5zSPO1rsETuKZ86K3twNG00wTNi AcTx7rFGn4NJg5DJkY5d8bsVgz4ZuawdLR9AnFkVExmcw8sW91vbwyrsDREvuMZDeQyT AFEQ== Received: by 10.68.212.197 with SMTP id nm5mr24236498pbc.110.1337889722319; Thu, 24 May 2012 13:02:02 -0700 (PDT) Received: from polypro-2.local (66-230-84-254-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.254]) by mx.google.com with ESMTPS id in7sm6445357pbc.23.2012.05.24.13.02.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 13:02:01 -0700 (PDT) Message-ID: <4FBE93B6.5050703@gmail.com> Date: Thu, 24 May 2012 12:01:58 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: opsawg@ietf.org References: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F633936092@dfweml506-mbx> <201205241955.q4OJtreh030888@cichlid.raleigh.ibm.com> In-Reply-To: <201205241955.q4OJtreh030888@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] definitions of continuity and connectivity X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:02:03 -0000 On 5/24/12 11:55 AM, Thomas Narten wrote: > Does saying A& B are "connected" mean the same thing as B is > reachable from A? That if A sends a packet to B, there is a working > path? I've tended to use "reachable" and "reachability" quite a bit in the past (related to NAT traversal) and I would distinguish between "reachable" and "connected." "Connected" implies state of some sort, even if it's just an open socket on an endpoint. "Connected" would seem to suggest "reachable" but I don't think it always does - you can have connection state maintained while reachability disappears out from underneath. > And does it mean there is a two-way path between A&B, or just that a > one-way path exists and works? Because of the NAT stuff I tend to feel pretty strongly that it's one-way. I think that much of this stuff is impossible to separate from routing. Melinda From linda.dunbar@huawei.com Thu May 24 13:40:06 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D7911E80A3 for ; Thu, 24 May 2012 13:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ey3mCnGDCKl for ; Thu, 24 May 2012 13:40:05 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6411421F847B for ; Thu, 24 May 2012 13:40:05 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGF78321; Thu, 24 May 2012 16:40:05 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 13:38:32 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 24 May 2012 13:38:26 -0700 From: Linda Dunbar To: Thomas Narten Thread-Topic: [OPSAWG] definitions of continuity and connectivity Thread-Index: AQHNOchfgZgXdZXbNkmZM0l/ZYbvY5bZIxOggACtKID//5MvgA== Date: Thu, 24 May 2012 20:38:26 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F633936288@dfweml506-mbx> References: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F633936092@dfweml506-mbx> <201205241955.q4OJtreh030888@cichlid.raleigh.ibm.com> In-Reply-To: <201205241955.q4OJtreh030888@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.216] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] definitions of continuity and connectivity X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:40:06 -0000 IEEE802.1Q uses the wording "Continuity Check Message" (instead of connect= ivity) because "connectivity" has the connotation as a line between two poi= nts.=20 In IEEE802.1Q, the word "Continuity" doesn't mean much other than in the p= hrase " Continuity Check Message". If you don't like the circular definitio= n, you can simply apply the definition to "CCM". The important part is the = "multicast" message to reach all the nodes in the VLAN.=20 TRILL is multi-point to multi-point interconnect, the "connectivity" is not= only between two points (same as in IEEE802.1Q).=20 So it is not about A reaching B, it is about A reaching all the TRILL edge = nodes which has the VLAN enabled.=20 Linda=20 > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 24, 2012 2:56 PM > To: Linda Dunbar > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] definitions of continuity and connectivity >=20 > Linda Dunbar writes: >=20 > > IEEE802.1Q - 2011 has this definition: >=20 > > "3.37 Connectivity Fault Management (CFM): Connectivity Fault > > Management comprises capabilities for detecting, verifying, and > > isolating connectivity failures in Virtual Bridged Local Area > > Networks." >=20 > > If you really want to define "connectivity", you can use the > > description by Merriam Webster Dictionary: the quality, state, > > or capability of being connective or connected > of a surface>; especially : the ability to connect to or > > communicate with another computer or computer system >=20 > I want a definition that makes sense for networking, and TRILL in > particular. >=20 > Does saying A & B are "connected" mean the same thing as B is > reachable from A? That if A sends a packet to B, there is a working > path? >=20 > And does it mean there is a two-way path between A&B, or just that a > one-way path exists and works? >=20 > > For " Continuity check", IEEE802.1Q has this definition: >=20 > > "3.38 Continuity Check Message (CCM): A multicast CFM PDU > > transmitted periodically by a MEP in order to ensure continuity > > over the MA to which the transmitting MEP belongs. No reply is > > sent by any MP in response to receiving a CCM." >=20 > That is a circular definition... What does continuity mean? >=20 > How does continuity differ from connectivity (if the above definition > is correct)? >=20 > Thomas From narten@us.ibm.com Fri May 25 03:20:24 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7756C21F85F9 for ; Fri, 25 May 2012 03:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58Su5CmRz0r4 for ; Fri, 25 May 2012 03:20:24 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id B99F221F85E6 for ; Fri, 25 May 2012 03:20:23 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 May 2012 06:20:22 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 25 May 2012 06:20:21 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id AA1426E804A for ; Fri, 25 May 2012 06:20:20 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4PAKKBd24510500 for ; Fri, 25 May 2012 06:20:20 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4PAKKSc009611 for ; Fri, 25 May 2012 07:20:20 -0300 Received: from cichlid.raleigh.ibm.com ([9.80.11.36]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q4PAKJMa009571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 May 2012 07:20:19 -0300 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q4PAKIlA013751 for ; Fri, 25 May 2012 06:20:18 -0400 Message-Id: <201205251020.q4PAKIlA013751@cichlid.raleigh.ibm.com> To: "opsawg@ietf.org" In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F633936288@dfweml506-mbx> References: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F633936092@dfweml506-mbx> <201205241955.q4OJtreh030888@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F633936288@dfweml506-mbx> Comments: In-reply-to Linda Dunbar message dated "Thu, 24 May 2012 20:38:26 -0000." Date: Fri, 25 May 2012 06:20:17 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12052510-9360-0000-0000-000006ACCA0C Subject: Re: [OPSAWG] definitions of continuity and connectivity X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 10:20:24 -0000 Some more background. In defining terms like continuity/connectivity, I'm looking for a definition that isn't operational. When we give a definition in terms of packets and responses to packets, that is like having C code be the definition of something. We shouldn't need a detailed algorithm to define terms. What is driving this discussion is that the TRILL OAM document (draft-tissa-trill-oam-req-01.txt) says things like : > 4.2.1. Unicast > > OAM MUST have the ability to verify connectivity from an RBridge RB1 > to a specific RBridge RB2. and > 4.3. Continuity Check > > [RFC5860] defines Continuity Check as the ability of end points to > monitor liveliness of a path or a section of a path [RFC5860]. We > use similar semantics in this document where end points are the > ingress or egress RBridges. > > OAM MUST provide functions that allow an RBridge to perform a > Continuity Check to any other RBridge. I have a very practical question. Are the two MUST requirements above the same, or are they different? I can't tell without knowing what the difference between continuity and connectivity is. Thomas From clonvick@cisco.com Fri May 25 03:57:30 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43CE21F863D for ; Fri, 25 May 2012 03:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6Z3MO8dZAWw for ; Fri, 25 May 2012 03:57:30 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 32D3F21F85E6 for ; Fri, 25 May 2012 03:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=1644; q=dns/txt; s=iport; t=1337943450; x=1339153050; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=+tPJARQNaCafsObjtsNynj0u5LaIDgqa+qQB7MIAh9o=; b=TLc7SiQDIMWdiS99UXGU8uTitclkdHUF0HQ4/ptoFxNfvQI57+vXjIsy Qmos6Z+jOgyM9q+15KI/G0PbJ327uOMEa/2xvFR2sOHBPzV5CwoWl3NBr TjeyLl2nqjpCJqfntz/keRkjpOK1dq5TuL9M8FXPp6HMEb09evNqoxZ/B E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAChlv0+rRDoI/2dsb2JhbABEtSOBB4IVAQEBAwEBAQEPASUCNAsFCwtGJzAGEwkZh2YEDJs6n3eLAYVGA4g/l1ODEoFkgwA X-IronPort-AV: E=Sophos;i="4.75,655,1330905600"; d="scan'208";a="46364082" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 25 May 2012 10:57:29 +0000 Received: from sjc-xdm-114.cisco.com (sjc-xdm-114.cisco.com [171.71.188.119]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4PAvTwX027402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 May 2012 10:57:29 GMT Received: from sjc-xdm-114.cisco.com (localhost.localdomain [127.0.0.1]) by sjc-xdm-114.cisco.com (8.13.8/8.13.8) with ESMTP id q4PAvSwl021596; Fri, 25 May 2012 03:57:28 -0700 Received: from localhost (clonvick@localhost) by sjc-xdm-114.cisco.com (8.13.8/8.13.8/Submit) with ESMTP id q4PAvS8E021593; Fri, 25 May 2012 03:57:28 -0700 X-Authentication-Warning: sjc-xdm-114.cisco.com: clonvick owned process doing -bs Date: Fri, 25 May 2012 03:57:28 -0700 (PDT) From: Chris Lonvick To: Thomas Narten In-Reply-To: <201205251020.q4PAKIlA013751@cichlid.raleigh.ibm.com> Message-ID: References: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F633936092@dfweml506-mbx> <201205241955.q4OJtreh030888@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F633936288@dfweml506-mbx> <201205251020.q4PAKIlA013751@cichlid.raleigh.ibm.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] definitions of continuity and connectivity X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 10:57:31 -0000 Hi, The only glossary that I know of that contains both terms is at ATIS. http://www.atis.org/glossary/ In my opinion, a continuity check is the same as verifying connectivity. Hope this helps, Chris On Fri, 25 May 2012, Thomas Narten wrote: > Some more background. > > In defining terms like continuity/connectivity, I'm looking for a > definition that isn't operational. When we give a definition in terms > of packets and responses to packets, that is like having C code be the > definition of something. We shouldn't need a detailed algorithm to > define terms. > > What is driving this discussion is that the TRILL OAM document > (draft-tissa-trill-oam-req-01.txt) says things like : > >> 4.2.1. Unicast >> >> OAM MUST have the ability to verify connectivity from an RBridge RB1 >> to a specific RBridge RB2. > > > and > >> 4.3. Continuity Check >> >> [RFC5860] defines Continuity Check as the ability of end points to >> monitor liveliness of a path or a section of a path [RFC5860]. We >> use similar semantics in this document where end points are the >> ingress or egress RBridges. >> >> OAM MUST provide functions that allow an RBridge to perform a >> Continuity Check to any other RBridge. > > > I have a very practical question. Are the two MUST requirements above > the same, or are they different? I can't tell without knowing what the > difference between continuity and connectivity is. > > Thomas > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From linda.dunbar@huawei.com Fri May 25 07:45:59 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8022F21F8541 for ; Fri, 25 May 2012 07:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoIgnFRUFntY for ; Fri, 25 May 2012 07:45:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC6A21F8674 for ; Fri, 25 May 2012 07:45:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGG42989; Fri, 25 May 2012 10:45:58 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 25 May 2012 07:43:24 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 25 May 2012 07:43:22 -0700 From: Linda Dunbar To: Thomas Narten , "opsawg@ietf.org" Thread-Topic: [OPSAWG] definitions of continuity and connectivity Thread-Index: AQHNOchfgZgXdZXbNkmZM0l/ZYbvY5bZIxOggACtKID//5MvgIABXlOA///S14A= Date: Fri, 25 May 2012 14:43:22 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F633936529@dfweml506-mbx> References: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F633936092@dfweml506-mbx> <201205241955.q4OJtreh030888@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F633936288@dfweml506-mbx> <201205251020.q4PAKIlA013751@cichlid.raleigh.ibm.com> In-Reply-To: <201205251020.q4PAKIlA013751@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OPSAWG] definitions of continuity and connectivity X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 14:45:59 -0000 "Continuity Check" should be the periodic OAM messages in fixed intervals (= e.g. 3ms) which are used to verify the connectivity between end points.=20 So "Continuity" itself is not same as "connectivity".=20 Connectivity is declared as "down" when an end point not receiving "Continu= ity Check" messages for X number of intervals.=20 Linda=20 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Thomas Narten > Sent: Friday, May 25, 2012 5:20 AM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] definitions of continuity and connectivity >=20 > Some more background. >=20 > In defining terms like continuity/connectivity, I'm looking for a > definition that isn't operational. When we give a definition in terms > of packets and responses to packets, that is like having C code be the > definition of something. We shouldn't need a detailed algorithm to > define terms. >=20 > What is driving this discussion is that the TRILL OAM document > (draft-tissa-trill-oam-req-01.txt) says things like : >=20 > > 4.2.1. Unicast > > > > OAM MUST have the ability to verify connectivity from an RBridge > RB1 > > to a specific RBridge RB2. >=20 >=20 > and >=20 > > 4.3. Continuity Check > > > > [RFC5860] defines Continuity Check as the ability of end points to > > monitor liveliness of a path or a section of a path [RFC5860]. We > > use similar semantics in this document where end points are the > > ingress or egress RBridges. > > > > OAM MUST provide functions that allow an RBridge to perform a > > Continuity Check to any other RBridge. >=20 >=20 > I have a very practical question. Are the two MUST requirements above > the same, or are they different? I can't tell without knowing what the > difference between continuity and connectivity is. >=20 > Thomas >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From janovak@cisco.com Tue May 22 01:58:05 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E4221F853D; Tue, 22 May 2012 01:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO56jk7CT555; Tue, 22 May 2012 01:58:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABFE21F84FC; Tue, 22 May 2012 01:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=janovak@cisco.com; l=2864; q=dns/txt; s=iport; t=1337677085; x=1338886685; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mJ5YAiuzwuVtKnAZUc2+/OUsXwOz0bApdbjZL33z1iM=; b=iJt6R807NLHSr+A4ld+ZHSgy4xy6OZ/M2+sqNEkuKXgu0iFaf2CzgbJe P6lpo8dRkG4+8Q59Gr2Yj/SnrrS+sBNc4i5Vm25tqMbsZwPrlP3MzLJXb xFlJ9a1I0D9BN1daxO1Vdt1JDs4RJvRtHgUJtbb7m1azd1n8K69c4PNmn 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJhUu0+Q/khL/2dsb2JhbABEtBSBB4IWAQEEEgEdCj8QAgEqBhgGAVYBAQQBGhqHbJ4PoBSLG4RHYgOjJ4FkgmuBVA X-IronPort-AV: E=Sophos;i="4.75,637,1330905600"; d="scan'208";a="138295200" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 22 May 2012 08:58:02 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4M8w24e024362; Tue, 22 May 2012 08:58:02 GMT Received: from xmb-ams-212.cisco.com ([144.254.75.23]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 May 2012 10:58:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 May 2012 10:58:00 +0200 Message-ID: In-Reply-To: <201205161453.q4GErZNl015927@alpd052.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Thread-Index: Ac0zc8BXTR41oCKqTcOQDS4l95WyzAEhILoQ References: <201205161453.q4GErZNl015927@alpd052.aldc.att.com> From: "Jan Novak (janovak)" To: "Aamer Akhter (aakhter)" , , X-OriginalArrivalTime: 22 May 2012 08:58:02.0093 (UTC) FILETIME=[FE4479D0:01CD37F8] X-Mailman-Approved-At: Fri, 25 May 2012 20:34:24 -0700 Cc: Al Morton , pmol@ietf.org Subject: [OPSAWG] Comments on draft-akhter-opsawg-perfmon-ipfix-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 08:58:06 -0000 Hi Amer, I have reviewed your draft draft-akhter-opsawg-perfmon-ipfix-02.txt. There seems to be a lot of text overlap with your methodology document - section 1,3, 4 could probably be abbreviated or omitted leaving the document just with raw IPFIX IE specifications or just add the IE specification as sub-sections or a new section into the first document ??=20 Section 2 uses definitions from RFC5610 - I think those you use there are defined in RFC5102 as DataTypeSemantic, units and range while RFC5610 specifies how this information should be exported - here you are defining the IE itself so you should use the definitions from RFC5102 Also the methodology documents already speaks in terms of IPFIX IEs while you are trying to specify some performance metrics - the methodology could have names and an exact definitions of the metric and then a reference which IE represents the particular metric RFC5102 section 2.1 specifies a template for IEs with a MUST so the MUST entries should be literally followed in your IEs spec - namely name, elementID, description, dataType and status. RFC5102 section 2.1 specifies MAY entries for the template - like DataTypeSemantic, units, name - might be preferable to follow the naming as well You interchanged ElementId with name - ElementId should be the numerical ID of the particular IE, while name of the IE is actually missing Instead of using Observation Point - wouldn't be the scope of the element appropriate ?? Or if not then scope should be actually added - are the=20 metrics (like perfPacketLoss) applicable to all the traffic seen by the UUT (or more specifically passing through the Observation Point) or to just individual flows ?? This should also be part of the particular metric definition. Will your IEs be enterprise IEs or IANA ones ?? Section 4.1.2 - Units packets ?? Section 4.1.3 - there is a mis-match between the definition and the range=20 - it should be limited to 0 - 100 + a value when the rate is unknown This definition is also missing in section 4.1.3 of your methodology Sections 4.3.1, 4.3.2 - the values are just numbers/ids so units shouldn't be octets but "none" ?? The IPFIX guys here have had few discussions regarding IE definitions explosions with all the needs like this - have you thought using RFC6313 now (structured data) ?? I am not sure I would use RFC2321 as a reference work :-). huic-ipfix-sipfix is not a work in progress - the ID expired 3 years ago. ie-doctors is a WG doc version 2 now - draft-ietf-ipfix-ie-doctors-02.txt pmol-metrics-framework is RFC 6390 The document would benefit from running it through spell checker. Rgds, Jan The climate of Edinburgh is such that the weak succumb young ....=20 and the strong envy them. Dr. Johnson From mehmet.ersue@nsn.com Wed May 30 11:24:16 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EB111E80E8; Wed, 30 May 2012 11:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw0S39S8VKWi; Wed, 30 May 2012 11:24:16 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id CB1C211E80E5; Wed, 30 May 2012 11:24:15 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4UIOA7u000371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 May 2012 20:24:10 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4UIO81J025488; Wed, 30 May 2012 20:24:10 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 20:24:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 May 2012 20:24:00 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403D56943@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: New Maillist for the discussion on the Management of Constrained Networks and Devices Thread-Index: Ac0+kWJuHevLc3OQQiun3QRVzjfThQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 May 2012 18:24:08.0463 (UTC) FILETIME=[671B39F0:01CD3E91] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3587 X-purgate-ID: 151667::1338402250-00001F01-9841B028/0-0/0-0 Cc: ops-dir@ietf.org, core-chairs@tools.ietf.org, ietf@ietf.org, smartobject-interest@ietf.org, core@ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] New Maillist for the discussion on the Management of Constrained Networks and Devices X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 18:24:17 -0000 Hi All, as noted in the maillist announcement of IETF secretary "coma" maillist is for the discussion on the management of constrained networks and devices. The mailing list will discuss and identify the issues and requirements and objectives for the management of devices in such an environment with a special focus on and differentiation of device classes.=20 The idea and trigger for the maillist creation came from a discussion in the OPS directorate during IETF #82. As draft-ietf-opsawg-management-stds-07 states IETF so far has not developed specific technologies for the management of constrained networks. OPS directorate members stated in IETF #82 that there is a need to understand the requirements and the necessary solutions for the management of such a constrained network and its devices. The assumption people had was that we need a comprehensive management approach to be able to address the diverse needs of different device classes. Although the OPS area was doing already standardization work for network management, the Core WG is one of the essential WGs at IETF interested in the management of constrained devices.=20 Following are some of the questions which have been raised in the OPS directorate meeting, which are for sure subject to extend from Core WG pov.: * Do we need a new development for IoT management (i.e. constrained devices) at all?=20 - If yes, what is really needed as standard and what is an overkill? * What type of devices can we support? * How are the classes 0-2 for constrained devices defined in detail? * Is some simple configuration management already sufficient? - Or do we need also a simple fault management and monitoring? * What type of data model modules do we need to standardize?=20 - Just a few core models like ip-cfg, interface? - or also other specific models for monitoring? * Can we use available management standards and data models as a starting point and simplify them? * Concerning the encoding (JSON, XML, or binary) we seem to be flexible with tools. - Concerning a normative data modeling language, we need to choose a suitable language capable to prepare structured models.=20 - Is JSON sufficient for this purpose, or should YANG or any other modeling language be used?=20 * What is appropriate as message transport? - CoAP over UDP with soft-transactions? - Netconf-Light over TCP? Obviously the list of the questions above is not exhaustive. Carsten kindfully provided already in the Prague meeting the definition of device classes 0-2 (http://www.ietf.org/proceedings/80/slides/core-0.pdf). I think it would be useful to start a discussion first on the detailed definition of these device classes 0-2 in constrained networks and based on their capabilities which functionality they will be able to support. This can be then used as a guideline for further discussion on the requirements or objectives for management of such devices.=20 As noted in the announcement the result of the coma discussion can lead to a taxonomy document and a problem statement highlighting the need for new work. Please send your opinions/comments to the coma maillist (coma@ietf.org). To subscribe pls go to: https://www.ietf.org/mailman/listinfo/coma=20 Cheers,=20 Mehmet=20 BTW: Coma has been chosen as the maillist name following the definition below: Coma \Co"ma\, n. [L., hair, fr. Gr. ko`mh.] 1. (Astron.) The envelope of a comet; a nebulous covering, which surrounds the nucleus or body of a comet. [1913 Webster] From ietfc@btconnect.com Thu May 31 10:08:34 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5573111E8147 for ; Thu, 31 May 2012 10:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvtLWrvEZRcJ for ; Thu, 31 May 2012 10:08:33 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7044121F8709 for ; Thu, 31 May 2012 10:08:33 -0700 (PDT) Received: from mail67-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Thu, 31 May 2012 17:08:03 +0000 Received: from mail67-ch1 (localhost [127.0.0.1]) by mail67-ch1-R.bigfish.com (Postfix) with ESMTP id 5DCEF2010B; Thu, 31 May 2012 17:08:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zz9371I542M1432N1418Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail67-ch1 (localhost.localdomain [127.0.0.1]) by mail67-ch1 (MessageSwitch) id 1338484081758719_14703; Thu, 31 May 2012 17:08:01 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail67-ch1.bigfish.com (Postfix) with ESMTP id AD39C120045; Thu, 31 May 2012 17:08:01 +0000 (UTC) Received: from DB3PRD0702HT001.eurprd07.prod.outlook.com (157.55.224.141) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 31 May 2012 17:08:01 +0000 Received: from BL2PRD0610HT003.namprd06.prod.outlook.com (157.56.240.117) by pod51017.outlook.com (10.3.4.141) with Microsoft SMTP Server (TLS) id 14.15.74.2; Thu, 31 May 2012 17:08:17 +0000 Message-ID: <014001cd3f4f$8fc91a20$4001a8c0@gateway.2wire.net> From: t.petch To: , Thomas Narten References: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com><4A95BA014132FF49AE685FAB4B9F17F633936092@dfweml506-mbx><201205241955.q4OJtreh030888@cichlid.raleigh.ibm.com><4A95BA014132FF49AE685FAB4B9F17F633936288@dfweml506-mbx> <201205251020.q4PAKIlA013751@cichlid.raleigh.ibm.com> Date: Thu, 31 May 2012 18:04:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.117] X-OriginatorOrg: btconnect.com Subject: Re: [OPSAWG] definitions of continuity and connectivity X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 17:08:34 -0000 ----- Original Message ----- From: "Thomas Narten" To: Sent: Friday, May 25, 2012 11:20 AM > Some more background. > > In defining terms like continuity/connectivity, I'm looking for a > definition that isn't operational. When we give a definition in terms > of packets and responses to packets, that is like having C code be the > definition of something. We shouldn't need a detailed algorithm to > define terms. > > What is driving this discussion is that the TRILL OAM document > (draft-tissa-trill-oam-req-01.txt) says things like : > > > 4.2.1. Unicast > > > > OAM MUST have the ability to verify connectivity from an RBridge RB1 > > to a specific RBridge RB2. > > and > > > 4.3. Continuity Check > > > > [RFC5860] defines Continuity Check as the ability of end points to > > monitor liveliness of a path or a section of a path [RFC5860]. We > > use similar semantics in this document where end points are the > > ingress or egress RBridges. > > > > OAM MUST provide functions that allow an RBridge to perform a > > Continuity Check to any other RBridge. > > I have a very practical question. Are the two MUST requirements above > the same, or are they different? I can't tell without knowing what the > difference between continuity and connectivity is. Different. This was hammered out in MPLS but RFC5860 is sloppy in this regard. Continuity Check is proactive, at a rate commensurate with the time within which failures should be detected, which could be mS or could be seconds. Thus it must be low cost, simple, basic. Connectivity Verification is on demand, run when it is needed, perhaps as a result of an alarm; it may not be run for months, so can afford to be heavyweight, gathering everything that might be needed. In a sense, both are solutions, not requirements. RFC5951 talks of on demand and proactive modes, which I think better. I think that the authors of draft-tissa-trill have rather missed the point, and need to read their Normative References more carefully. And their I-D will be easier to read once the author list on the front page is cut down to size, as it must before it ever makes it to RFC. Tom Petch > > Thomas > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From narten@us.ibm.com Thu May 31 12:38:14 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179AB21F86D7 for ; Thu, 31 May 2012 12:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7V7zJRt8nSM for ; Thu, 31 May 2012 12:38:13 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCA621F86D3 for ; Thu, 31 May 2012 12:38:13 -0700 (PDT) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 31 May 2012 13:38:11 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 31 May 2012 13:38:06 -0600 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 921CEC9006D for ; Thu, 31 May 2012 15:38:03 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4VJc2Xv117384 for ; Thu, 31 May 2012 15:38:02 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q5118rJ5011019 for ; Thu, 31 May 2012 21:08:54 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-240-102.mts.ibm.com [9.65.240.102]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q5118qQ1010931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 May 2012 21:08:53 -0400 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q4VJbwmk009602; Thu, 31 May 2012 15:37:59 -0400 Message-Id: <201205311937.q4VJbwmk009602@cichlid.raleigh.ibm.com> To: "t.petch" In-reply-to: <014001cd3f4f$8fc91a20$4001a8c0@gateway.2wire.net> References: <201205241613.q4OGDXrj028911@cichlid.raleigh.ibm.com><4A95BA014132FF49AE685FAB4B9F17F633936092@dfweml506-mbx><201205241955.q4OJtreh030888@cichlid.raleigh.ibm.com><4A95BA014132FF49AE685FAB4B9F17F633936288@dfweml506-mbx> <201205251020.q4PAKIlA013751@cichlid.raleigh.ibm.com> <014001cd3f4f$8fc91a20$4001a8c0@gateway.2wire.net> Comments: In-reply-to "t.petch" message dated "Thu, 31 May 2012 18:04:08 +0100." Date: Thu, 31 May 2012 15:37:53 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12053119-7606-0000-0000-000000C35003 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] definitions of continuity and connectivity X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 19:38:14 -0000 Hi Tom. > > I have a very practical question. Are the two MUST requirements above > > the same, or are they different? I can't tell without knowing what the > > difference between continuity and connectivity is. > Different. > This was hammered out in MPLS but RFC5860 is sloppy in this regard. > Continuity Check is proactive, at a rate commensurate with the time > within which failures should be detected, which could be mS or could be > seconds. Thus it must be low cost, simple, basic. Does this also imply multiple messages sent, and getting a percentage of packets lost? As opposed to a single request/response? > Connectivity Verification is on demand, run when it is needed, perhaps > as a result of an alarm; it may not be run for months, so can afford to > be heavyweight, gathering everything that might be needed. Does this also imply a single message/response transaction? Or can this also imply something more sophisticated, involving multiple messages? What I'm trying to do is separate what "continuity" and "connectivity" are intended to achieve, vs. mechanics for acheiving the desired semantics. But a lot of the discussion about the terms seems to be implying a solution rather than what the solution is required to achieve. And while I understand that on-demand vs. proactive is an important distinction for when/how to invoke functionality, I'd like to understand the distinction between the two in terms of what they are supposed to achieve (independently of whether invoked proactively or on-demand). Thomas