From bertietf@bwijnen.net Thu Jan 2 00:55:16 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145071AE3F4 for ; Thu, 2 Jan 2014 00:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP0fKgT7A273 for ; Thu, 2 Jan 2014 00:55:14 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD921AE3F5 for ; Thu, 2 Jan 2014 00:55:14 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vye3V-0005M5-Vn for opsawg@ietf.org; Thu, 02 Jan 2014 09:55:06 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Vye3V-0001oM-Qv for opsawg@ietf.org; Thu, 02 Jan 2014 09:55:05 +0100 Message-ID: <52C52968.7050404@bwijnen.net> Date: Thu, 02 Jan 2014 09:55:04 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "opsawg >> \"opsawg@ietf.org\"" References: <52C32AF3.3040103@bwijnen.net> In-Reply-To: <52C32AF3.3040103@bwijnen.net> X-Forwarded-Message-Id: <52C32AF3.3040103@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40e1d2ff96c09fd9947376daf58bcb200 Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 08:55:16 -0000 My review of the coman documents. I am not well versed in these spaces, so take that into account. Reading the use cases I got a bit annoyed by the military discussion. I am a pacifist, so don't really want to review/discuss military needs or requirements. Oh well.... I am also not very familiar with the uses cases of intelligent meters, factory automation/monitoring, health care devices monitoring and being remotely managed. It is interesting reading, and I learned a lot, but I cannot evaluate if they represent real scenarios or are detailed anough. Also can I not evaluate if they are exhaustive. So I focused on the requirements. Good list of requirements to start with I think. I have some questions: - for requirement 4.2.0001 I wonder why a C0 device would have to implement in a modular fashion. I could see that a C0 device (Maybe even C1) does the minimal modular-function-set implementation, but that the impleementation is in fact monolythic. It often save memory and possibly cpu cycles. - for requirement 4.9.001 It might be good to add a refereence to RFC2914 ?? Just thinking aloud. - for requirement 4.9.003 is that more or less an "implementation" suggestion for requirement 4.9.001 ?? See you all in the neaw year, which I hope is prosperous for you all. Bert From lhotka@nic.cz Fri Jan 3 07:55:35 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2901ADF0F for ; Fri, 3 Jan 2014 07:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.705 X-Spam-Level: * X-Spam-Status: No, score=1.705 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HOST_EQ_CZ=0.904, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeqNsIpO9pC3 for ; Fri, 3 Jan 2014 07:55:33 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id DED0E1ADED6 for ; Fri, 3 Jan 2014 07:55:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BD39454063C; Fri, 3 Jan 2014 16:55:23 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KCWbK78g+3c; Fri, 3 Jan 2014 16:55:16 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 02A9F540157; Fri, 3 Jan 2014 16:55:11 +0100 (CET) From: Ladislav Lhotka To: Stefan Winter , opsawg@ietf.org In-Reply-To: <52B15E82.4090709@restena.lu> References: <52B15E82.4090709@restena.lu> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Fri, 03 Jan 2014 16:55:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [OPSAWG] Upcoming I-D: EAP metadata format X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 15:55:35 -0000 Hi Stefan, in my view, this is a useful work. My (user's) experience from eduroam is t= hat configuring the authentication has often been the most difficult step. I think though you should consider using YANG (RFC 6020) for the configurat= ion data model specification. Lada Stefan Winter writes: > Hello, > > I'm currently in the process of writing an -00 I-D on an aspect of > network management which has IMHO been neglected standards-wise so far: > Configuration of EAP authentication, particularly in the IEEE > 802.1X/WiFi space (but also relevant for other EAP-based network access > control and ABFAB) - on the end-user device (i.e. EAP peer). > > The issue is that the IETF has produced EAP and EAP methods; they have > many properties which need to be setup on the EAP server and matched as > configuration items on the EAP peer. Deploying EAP is a complex task > both for an EAP server operator *and for the users who have to setup > everything correctly on their machine*. > > EAP is being used for WiFi, and there in an increasing manner in the > buzzwordy "BYOD" scenarios; and a further use case comes up in "Hotspot > 2.0" where the user does not have any particular relationship to the EAP > server operator besides the desire for internet connectivity. > > In these scenarios, the EAP server operator does not have full > administrative control over the end-user device; yet, a complex > configuration task needs to be carried out on that device to make the > EAP setup > * functional (i.e. the end user must have set up enough parameters > correctly to be able to authenticate to an EAP server at all) > * secure (i.e. the end user must have set up all the parameters which > ensure unambiguous mutual authentication to *only* his EAP server) > * privacy-preserving (i.e. the end user is able to conceal his username > from the EAP pass-through authenticator) > > In our EAP-based "eduroam" WiFi roaming consortium, we meanwhile have > millions of users, thousands of EAP servers and thus just as many > different EAP settings for users of those EAP servers. IOW, we have the > operational capacity and enough real-life experience to credibly assert > that initial EAP setup is a tough job if having to be done manually by > the user. To alleviate the problem, it would be desirable to be able to > convey the configuration information in a machine parseable way so that > all the gory details need not be known/understood by the user. > > There is currently no standard way of communicating configuration > parameters about an EAP setup to the EAP peer. > > Device manufacturers sometimes have developed their own proprietary > configuration formats, e.g. Apple's "mobileconfig" (MIME type > application/x-apple-aspen-config). > Other devices at least provide an API for such configuration; if there > were a standard way to communicate the settings to such a device, an > application could consume the configuration information and create the > necessary settings automatically. Android 4.3+ (API level 18) is one > such example. > Yet other devices do not have an API nor good UI for a manual setup. At > least one device type developer base has communicated to us that if > there were a standard way of getting EAP configuration data for WiFi > OTA, they would likely make use of it. > > To overcome this proprietary/mixed-capability situation, we would like > to propose that the IETF develops a metadata format which can > communicate EAP settings and EAP method deployment details; with the > eventual goal that EAP peer devices would be enabled to consume the > file, act on it, and set up EAP in a complete, secure and (if so > desired) privacy-preserving way. > > I have talked to the OPS ADs in Berlin, who encouraged me to go ahead > with the specification and gave the advice that the place to take this > to is opsarea/opsawg - hence this mail. > > We have already developed a preliminary XML specification which is rich > enough to convey most if not all EAP deployment details, and which I > hope serves as a good starting point for IETF work. I'll assemble an > accompanying I-D which explains the current schema and documents the > design decisions we've taken so far. > > I would appreciate discussion on the topic here in opsawg; and as soon > as I've pushed out the draft itself, I'll be more than happy to receive > comments and bashing ;-) > > (And if discussion does happen on the list, I'd also like to request a > talking slot in the London meeting) > > Greetings, > > Stefan Winter > > --=20 > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > recipient's key is known to me > > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Fri Jan 3 08:41:12 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DD21ADF0F for ; Fri, 3 Jan 2014 08:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzhpt3PDuRC7 for ; Fri, 3 Jan 2014 08:41:10 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 10A1D1ADEBF for ; Fri, 3 Jan 2014 08:41:09 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s03Gf1ae020683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Jan 2014 17:41:01 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s03Gf0kM013330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jan 2014 17:41:01 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 3 Jan 2014 17:41:00 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Fri, 3 Jan 2014 17:41:00 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert Wijnen (IETF)" , "opsawg >> \"opsawg@ietf.org\"" Thread-Topic: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* Thread-Index: AQHPB5hTXASYx/AkA0mvvcW3JIGoM5py+qUA Date: Fri, 3 Jan 2014 16:41:00 +0000 Message-ID: References: <52C32AF3.3040103@bwijnen.net> <52C52968.7050404@bwijnen.net> In-Reply-To: <52C52968.7050404@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 2539 X-purgate-ID: 151667::1388767261-000025D0-21497A69/0-0/0-0 Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 16:41:12 -0000 Hi Bert, thank you for your kind review. See below. Cheers,=20 Mehmet=20 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of ext Bert Wijne= n > (IETF) > Sent: Thursday, January 02, 2014 9:55 AM > To: opsawg >> "opsawg@ietf.org" > Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* >=20 > My review of the coman documents. >=20 > I am not well versed in these spaces, so take that into account. >=20 > Reading the use cases I got a bit annoyed by the military discussion. > I am a pacifist, so don't really want to review/discuss military needs > or requirements. Oh well.... >=20 > I am also not very familiar with the uses cases of intelligent meters, > factory automation/monitoring, health care devices monitoring and being > remotely managed. > It is interesting reading, and I learned a lot, but I cannot evaluate > if they represent real scenarios or are detailed anough. Also can I not > evaluate if they are exhaustive. >=20 > So I focused on the requirements. > Good list of requirements to start with I think. I have some questions: >=20 > - for requirement 4.2.0001 > I wonder why a C0 device would have to implement in a modular fashion. > I could see that a C0 device (Maybe even C1) does the minimal > modular-function-set implementation, but that the impleementation is i= n > fact monolythic. It often save memory and possibly cpu cycles. I wonder how you define the "minimal modular-function-set". Isn't this alre= ady a decision? The draft avoids defining function sets to be used. I assume different vend= ors will provide=20 different monolithic devices.=20 >=20 > - for requirement 4.9.001 > It might be good to add a refereence to RFC2914 ?? > Just thinking aloud. Yes, RFC2914 is indeed interesting reference to add. >=20 > - for requirement 4.9.003 > is that more or less an "implementation" suggestion for requirement 4.= 9.001 ?? You are right. It could be seen as such. However, there might be different reasons why people would want to reduce t= he amount of traffic in the network. Congestion is one of them. One can also begin acting before congestion happ= ens. WDYT? >=20 > See you all in the neaw year, which I hope is prosperous for you all. > See you!!! Happy New Year!! Cheers, Mehmet >=20 > Bert > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From mehmet.ersue@nsn.com Fri Jan 3 09:55:31 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27A61ADFFC for ; Fri, 3 Jan 2014 09:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YVtfjz6sJeL for ; Fri, 3 Jan 2014 09:55:28 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 66C731ADFC2 for ; Fri, 3 Jan 2014 09:55:28 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s03HtFmu018418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Jan 2014 18:55:15 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s03HtEia022870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jan 2014 18:55:14 +0100 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 3 Jan 2014 18:55:14 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Fri, 3 Jan 2014 18:55:14 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , Warren Kumari , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* Thread-Index: AQHO8RDEXASYx/AkA0mvvcW3JIGoM5pQjfnQgCLichA= Date: Fri, 3 Jan 2014 17:55:13 +0000 Message-ID: References: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> <9904FB1B0159DA42B0B887B7FA8119CA129E249A@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129E249A@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 5891 X-purgate-ID: 151667::1388771716-00001A6F-A96C3A31/0-0/0-0 Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 17:55:31 -0000 Hi Dan, thank you for your review and comments. See below. Cheers,=20 Mehmet=20 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of ext Romascanu,= Dan > (Dan) > Sent: Thursday, December 12, 2013 2:23 PM > To: Warren Kumari; opsawg@ietf.org > Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* >=20 > Hi, >=20 > I do not know if I really should be included in the reviewers count, as I= am a participant > in the coman work since it started, and my name shows up on the list of a= uthors, > although in all sincerity most of the credits go to Mehmet, who hold the = pen for most > of the time, including this latest wound which split the original documen= t into two > separate documents - one for use cases, the other for problem statement a= nd > requirements. Anyway, FWIW I obviously believe this work is useful and I = support > doing it in the OPSAWG. I have a few comments recorded below: >=20 > draft-ersue-opsawg-coman-use-cases >=20 > 1. I do not believe that we can get away with a zero-content security con= siderations > section. The described use cases mention the need to secure information c= ollected by > constrained devices, some other (like security cameras) carry information= related to > personal or public security that needs to be protected by robust mechanis= ms. These > kind of threats need to be mentioned IMO. You are right a dummy security considerations section is not sufficient. Coman was not planning to address security exhaustively. Solace, now ACE, h= as been started where security for constrained devices will be discussed.=20 We discussed the security requirements in section 3.6 of the problem statem= ent draft. I agree, a discussion of the security threads should be provided in a secur= ity considerations section. > draft-ersue-opsawg-coman-probstate-reqs >=20 > 1. The draft uses the 'adjective' small device in association with constr= ained device in a > few place. I suggest to remove this. There is no automatic association of= a device > being small implying that it is also constrained. Nor are all constrained= devices small in > size. Agree. We should be more precise with the terminology. =20 > 2. We have made an effort in the last few versions and especially in this= one to > distinguish between the constrained devices and constrained networks, but= the clean-up > on this issue is not complete. For example section 1.6 still has text abo= ut constrained > networks - this section and other in which constrained networks are menti= oned should > be carefully examined to make sure that the focus of the document stays w= ith > constrained devices, and that if constrained networks are mentioned at al= l this is in the > context of their relationship with the constrained devices. Why strictly devices? We also have requirements discussing the organization= of constrained networks from management pov. in section 3.1.=20 =20 > 3. I do not believe that we can get away with a zero-content security con= siderations > section here either. The document even says: >=20 > If specific requirements for > security will be identified, they will be described in future > versions of this document. >=20 > This is not accurate - section 3.6 already speaks about requirments for s= ecurity and > access control, and section 1.6 mentions limitations that would prevent t= he > implementation of strong scryptographic algorythms. The text needs to be = reviewed > and revised from this perspective. I think the "future" is now and the current text in the security considerat= ions section needs to be replaced. I would suggest to provide a security co= nsiderations section by listing and discussing threads in the problem state= ment draft and refer to it from the use cases draft.=20 Comments? >=20 > Regards, >=20 > Dan >=20 > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumar= i > > Sent: Wednesday, December 04, 2013 6:49 PM > > To: opsawg@ietf.org > > Subject: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* > > > > Hi all, > > > > Hopefully you all had a good Thanksgiving -- if you are in the US, > > hopefully you had good turkey, stuffing / whatever. > > If you are not US based, hopefully you enjoyed the decrease in email > > volume while everyone recovered form eating too much. :-) > > > > One of the action items from Vancouver was for us to call for reviewers > > for: > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs= / > > and > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-use-cases/ > > > > So, can we get some volunteers please? According to our new guidelines > > we require sufficient reviewers before adopting new work. > > > > The documents are (IMO) interesting and easy to read. Constrained > > devices have some interesting requirements and limitations. > > If you would like a quick reminder / refresher from the meeting, slides > > are here: http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pd= f > > > > Juergen Schoenwaelder indicated > > that one of his Ph.D. students had read the draft a couple of weeks ago= . > > So they just have to review the changes to the latest version. > > > > > > W > > -- > > "I think it would be a good idea." > > - Mahatma Ghandi, when asked what he thought of Western civilization > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From bertietf@bwijnen.net Fri Jan 3 09:55:37 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6631AE00D for ; Fri, 3 Jan 2014 09:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUzz_tuBj5hW for ; Fri, 3 Jan 2014 09:55:35 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 50D361AE034 for ; Fri, 3 Jan 2014 09:55:35 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vz8xy-0004Ti-Bu; Fri, 03 Jan 2014 18:55:27 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Vz8xy-0000PJ-7l; Fri, 03 Jan 2014 18:55:26 +0100 Message-ID: <52C6F98E.5050805@bwijnen.net> Date: Fri, 03 Jan 2014 18:55:26 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , "opsawg >> \"opsawg@ietf.org\"" References: <52C32AF3.3040103@bwijnen.net> <52C52968.7050404@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd406751f5db9cba140cec2538133d7cd8b Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 17:55:38 -0000 inline On 03/01/14 17:41, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Bert, > > thank you for your kind review. See below. > > Cheers, > Mehmet > >> -----Original Message----- >> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of ext Bert Wijnen >> (IETF) >> Sent: Thursday, January 02, 2014 9:55 AM >> To: opsawg >> "opsawg@ietf.org" >> Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* >> >> My review of the coman documents. >> >> I am not well versed in these spaces, so take that into account. >> >> Reading the use cases I got a bit annoyed by the military discussion. >> I am a pacifist, so don't really want to review/discuss military needs >> or requirements. Oh well.... >> >> I am also not very familiar with the uses cases of intelligent meters, >> factory automation/monitoring, health care devices monitoring and being >> remotely managed. >> It is interesting reading, and I learned a lot, but I cannot evaluate >> if they represent real scenarios or are detailed anough. Also can I not >> evaluate if they are exhaustive. >> >> So I focused on the requirements. >> Good list of requirements to start with I think. I have some questions: >> >> - for requirement 4.2.0001 >> I wonder why a C0 device would have to implement in a modular fashion. >> I could see that a C0 device (Maybe even C1) does the minimal >> modular-function-set implementation, but that the impleementation is in >> fact monolythic. It often save memory and possibly cpu cycles. > > I wonder how you define the "minimal modular-function-set". Isn't this already a decision? > The draft avoids defining function sets to be used. I assume different vendors will provide > different monolithic devices. > There is two things that (in my view are/can be modular: - the implementation - the specification EVen if the specification is "modular", even then someone can chose to implement it as a monolythic program/process I would think. And often that can save memory usage. >> >> - for requirement 4.9.001 >> It might be good to add a refereence to RFC2914 ?? >> Just thinking aloud. > Yes, RFC2914 is indeed interesting reference to add. > >> >> - for requirement 4.9.003 >> is that more or less an "implementation" suggestion for requirement 4.9.001 ?? > > You are right. It could be seen as such. > However, there might be different reasons why people would want to reduce the amount of traffic in the network. > Congestion is one of them. One can also begin acting before congestion happens. WDYT? > OK, maybe add a line of text about that then. IN my view it looked like basically twice the same requirement. But if you define it this way, then it can be seen as a different requirement may be. Bert >> >> See you all in the neaw year, which I hope is prosperous for you all. >> > > See you!!! Happy New Year!! > > Cheers, > Mehmet > >> >> Bert >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > From andy@yumaworks.com Fri Jan 3 10:23:21 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B971ADFC8 for ; Fri, 3 Jan 2014 10:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr8xvlDia5xN for ; Fri, 3 Jan 2014 10:23:17 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id C28C81ADFB1 for ; Fri, 3 Jan 2014 10:23:17 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id e9so15141771qcy.34 for ; Fri, 03 Jan 2014 10:23:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nYlQSlkvrrIlSuel4BhGhIw/r3Y+5G6v7gdpBww4clo=; b=I0Ommal4cFfWDdkLCaK8mhccBeLLnUwVLVQTao/3/Vq4opylDj2q77wSifHulxxIMe sZ6d13TtIVdJTQFiXHu8xZMR88ZM0wo1IsiaOeS8IZCCbxyh/s8+pvC3pOQDjRj9R+8I sgMolMFQnBsmAzdzmenfRmPNsnItF8YOOSpJq0fEo8fW48iyRGi5m1rdaBdjxEWSgsTM rAuKE1qLrdpaNeZj6P5j/7U2HPYC1k31HO6QUbwjDoznGS1vczWCtfNNHkzMEAi3H3UE K0TJJNmTpOgetvfR5ZKK/8ZfS3lPnuCfxAZVXE/x4pC8JfDcb+7GUr4lf0ZjoLI+tgw/ GZaw== X-Gm-Message-State: ALoCoQkAhMf4tMYna7sWqU8m6BIfvd/O4MMa+IU57L/zlj5VmBNzwmVv8acozBZi+HFQ6BfMENf1 MIME-Version: 1.0 X-Received: by 10.224.71.143 with SMTP id h15mr51289792qaj.88.1388773389515; Fri, 03 Jan 2014 10:23:09 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 3 Jan 2014 10:23:09 -0800 (PST) In-Reply-To: <52C6F98E.5050805@bwijnen.net> References: <52C32AF3.3040103@bwijnen.net> <52C52968.7050404@bwijnen.net> <52C6F98E.5050805@bwijnen.net> Date: Fri, 3 Jan 2014 10:23:09 -0800 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=047d7bdc8aa48e663d04ef1500bc Cc: "opsawg >> opsawg@ietf.org" Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 18:23:21 -0000 --047d7bdc8aa48e663d04ef1500bc Content-Type: text/plain; charset=ISO-8859-1 Hi, On Fri, Jan 3, 2014 at 9:55 AM, Bert Wijnen (IETF) wrote: > .... >>> >> >> I wonder how you define the "minimal modular-function-set". Isn't this >> already a decision? >> The draft avoids defining function sets to be used. I assume different >> vendors will provide >> different monolithic devices. >> >> > There is two things that (in my view are/can be modular: > - the implementation > - the specification > > EVen if the specification is "modular", even then someone can chose to > implement it as a monolythic program/process I would think. And often that > can > save memory usage. > > I think this refers to the issues left unresolved by the "NETCONF Lite" discussions. The current NETCONF approach consists of a base protocol + several purely optional capabilities. This is a modular approach. The problem is that the base protocol is way too heavyweight for constrained devices. Another way to create modular functionality would look more like a hierarchy, not 1 mandatory blob + N optional blobs. NMS applications should be written so they can fall-back to lower functionality levels, in order to work with constrained devices. E.g. (not a complete list) Level 0: pre-configured; able to push pre-defined monitoring data Level 1: pre-configured; able to pull pre-defined monitoring data Level 2: pre-configured; able to pull user-defined filtered subsets of monitoring data Level 3: has config objects; requires a restart for new values to take affect Level 4: entire config (or pre-determined subset) can be replaced in bulk Level 5: ability to patch objects without replacing entire config Level 6: ability to lock datastores for write access Level 7: has transaction (all-or-none) capability Level 8: has recoverable transaction (confirmed-commit) capability Andy > > >>> - for requirement 4.9.001 >>> It might be good to add a refereence to RFC2914 ?? >>> Just thinking aloud. >>> >> Yes, RFC2914 is indeed interesting reference to add. >> >> >>> - for requirement 4.9.003 >>> is that more or less an "implementation" suggestion for requirement >>> 4.9.001 ?? >>> >> >> You are right. It could be seen as such. >> However, there might be different reasons why people would want to reduce >> the amount of traffic in the network. >> Congestion is one of them. One can also begin acting before congestion >> happens. WDYT? >> >> OK, maybe add a line of text about that then. IN my view it looked like > basically twice the > same requirement. But if you define it this way, then it can be seen as a > different requirement > may be. > > Bert > >> >>> See you all in the neaw year, which I hope is prosperous for you all. >>> >>> >> See you!!! Happy New Year!! >> >> Cheers, >> Mehmet >> >> >>> Bert >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>> >> >> _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --047d7bdc8aa48e663d04ef1500bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Fri, Jan 3, 2014 at 9:55 AM, Bert Wijnen (IETF) <bertietf= @bwijnen.net> wrote:
.... =A0=A0

I wonder how you define the "minimal modular-function-set". Isn&#= 39;t this already a decision?
The draft avoids defining function sets to be used. I assume different vend= ors will provide
different monolithic devices.


There is two things that (in my view are/can be modular:
- the implementation
- the specification

EVen if the specification is "modular", even then someone can cho= se to
implement it as a monolythic program/process I would think. And often that = can
save memory usage.



I think this refers to = the issues left unresolved by the "NETCONF Lite" discussions.
The current NETCONF approach consists of a base protocol + several p= urely optional
capabilities. =A0This is a modular approach. =A0The problem is that th= e base protocol
is way too heavyweight for constrained devices.

Another way to create modular functionality would l= ook more like a hierarchy,
not 1 mandatory blob + N optional blobs. =A0NMS applications should be= written
so they can fall-back to lower functionality levels, in = order to work with constrained devices.

E.g. (not = a complete list)

=A0 Level 0: pre-configured; able to push pre-defined m= onitoring data
=A0 Level 1: pre-configured; able to pull pre-defi= ned monitoring data
=A0 Level 2: pre-configured; able to pull use= r-defined filtered subsets of monitoring data
=A0 Level 3: has config objects; requires a restart for new values to = take affect
=A0 Level 4: entire config (or pre-determined subset)= can be replaced in bulk
=A0 Level 5: ability to patch objects wi= thout replacing entire config
=A0 Level 6: ability to lock datastores for write access
=A0= Level 7: has transaction (all-or-none) capability
=A0 Level 8: h= as recoverable transaction (confirmed-commit) capability


Andy

=A0


- for requirement 4.9.001
=A0 =A0 It might be good to add a refereence to RFC2914 ??
=A0 =A0 Just thinking aloud.
Yes, RFC2914 is indeed interesting reference to add.


- for requirement 4.9.003
=A0 =A0 is that more or less an "implementation" suggestion for r= equirement 4.9.001 ??

You are right. It could be seen as such.
However, there might be different reasons why people would want to reduce t= he amount of traffic in the network.
Congestion is one of them. One can also begin acting before congestion happ= ens. WDYT?

OK, maybe add a line of text about that then. IN my view it looked like bas= ically twice the
same requirement. But if you define it this way, then it can be seen as a d= ifferent requirement
may be.

Bert

See you all in the neaw year, which I hope is prosperous for you all.


See you!!! Happy New Year!!

Cheers,
Mehmet


Bert
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org = https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org = https://www.ietf.org/mailman/listinfo/opsawg

--047d7bdc8aa48e663d04ef1500bc-- From s.anuj@jacobs-university.de Fri Jan 3 18:28:17 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BF61AE048 for ; Fri, 3 Jan 2014 18:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUZHbIneLRcK for ; Fri, 3 Jan 2014 18:28:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C877F1AE043 for ; Fri, 3 Jan 2014 18:28:12 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 240492006B; Sat, 4 Jan 2014 03:28:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id boD_qFda1zZO; Sat, 4 Jan 2014 03:28:04 +0100 (CET) Received: from exchange.jacobs-university.de (unknown [10.70.0.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id E07F320066; Sat, 4 Jan 2014 03:28:04 +0100 (CET) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS04.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0174.001; Sat, 4 Jan 2014 03:28:03 +0100 From: "Sehgal, Anuj" To: "opsawg@ietf.org" Thread-Topic: Review of draft-opsawg-ersue-coman-*-00 Thread-Index: AQHPCPQUUpCF90h8akmQ3jJMfsFs2ZpzxoIA Date: Sat, 4 Jan 2014 02:28:02 +0000 Message-ID: <4B92C175-DBEC-492B-B4B1-FEC68522D9A2@jacobs-university.de> References: <4BBB7BFA-A744-40F2-803E-83ADB957F198@jacobs-university.de> In-Reply-To: <4BBB7BFA-A744-40F2-803E-83ADB957F198@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [217.239.4.62] Content-Type: multipart/mixed; boundary="_005_4B92C175DBEC492BB4B1FEC68522D9A2jacobsuniversityde_" MIME-Version: 1.0 Subject: Re: [OPSAWG] Review of draft-opsawg-ersue-coman-*-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 02:28:17 -0000 --_005_4B92C175DBEC492BB4B1FEC68522D9A2jacobsuniversityde_ Content-Type: text/plain; charset="iso-8859-1" Content-ID: <77413D861423F34EAFC45B4C4D5C1915@jacobs.jacobs-university.de> Content-Transfer-Encoding: quoted-printable Hi, As per the call for reviewing the COMAN documents, I have taken a look at t= he latest versions and have a few comments/recommendations for both. The re= views, along with suggestions on fixing them, are attached to this email in= appropriate files. Regards, Anuj Sehgal --_005_4B92C175DBEC492BB4B1FEC68522D9A2jacobsuniversityde_ Content-Type: text/plain; name="draft-ersue-opsawg-coman-use-cases-00.txt" Content-Description: draft-ersue-opsawg-coman-use-cases-00.txt Content-Disposition: attachment; filename="draft-ersue-opsawg-coman-use-cases-00.txt"; size=23186; creation-date="Sat, 04 Jan 2014 02:28:02 GMT"; modification-date="Sat, 04 Jan 2014 02:28:02 GMT" Content-ID: Content-Transfer-Encoding: base64 Mi4zIEluZHVzdHJpYWwgQXBwbGljYXRpb25zDQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQ0KDQ0KKGEpIE1ha2UgdGhlIHNlY3Rpb24gb24gQnVpbGRpbmcgQXV0b21hdGlvbiBzZWN0aW9u IDIuMywgdGhlcmVieQ0NCiAgICBtb3ZpbmcgSW5kdXN0cmlhbCBhcHBsaWNhdGlvbnMgdG8gMi41 IGFuZCBIb21lIGF1dG9tYXRpb24gdG8gMi41LA0NCiAgICBzaW5jZSBhIHJlZmVyZW5jZSB0byBC dWlsZGluZyBBdXRvbWF0aW9uIGxpa2Ugc2NlbmFyaW9zIGV4aXN0IGluDQ0KICAgIGJvdGggb2Yg dGhlc2UgYXJlYXMgYXMgd2VsbC4NDQoNDQooYikgSSBiZWxpZXZlIHRoYXQgc2VwYXJhdGluZyBC dWlsZGluZyBBdXRvbWF0aW9uIGZyb20gSW5kdXN0cmlhbA0NCiAgICBBcHBsaWNhdGlvbnMgaXMg aW1wb3J0YW50LiBJbmR1c3RyaWFsIEFwcGxpY2F0aW9ucywgaW4gbXkgdmlldywNDQogICAgYXJl IHR5cGljYWxseSB0aG9zZSBzeXN0ZW1zIHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGFkYXB0IHRo ZQ0NCiAgICBvcGVyYXRpbmcgY29uZGl0aW9ucyBvZiBhIG1hbnVmYWN0dXJpbmcgcGxhbnQsIG1v bml0b3IgdGhlDQ0KICAgIHByb2R1Y3Rpb24gc3lzdGVtcyBhbmQgdHJpZ2dlciBzcGVjaWZpYyBk ZWNpc2lvbiBtYWtpbmcgcHJvY2Vzc2VzDQ0KICAgIChlLmcuIG9yZGVyaW5nIGNvbXBvbmVudHMs IHRyaWdnZXIgc2FmZXR5IG1lY2hhbmlzbXMgYW5kIGV0Yy4pLg0NCg0NCiAgICBBcyBzdWNoLCBJ IHByb3Bvc2UgdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhlIGZpcnN0IGZldyBzZW50ZW5jZXMN DQogICAgb2YgdGhlIGZpcnN0IHBhcmFncmFwaDoNDQoNDQogICAgICAgIkluZHVzdHJpYWwgQXBw bGljYXRpb25zIGFuZCBzbWFydCBtYW51ZmFjdHVyaW5nIHJlZmVyIHRvDQ0KICAgICAgIG5ldHdv cmtlZCBjb250cm9sIGFuZCBtb25pdG9yaW5nIG9mIHRhc2tzIHN1Y2ggYXMgZXF1aXBtZW50DQ0K ICAgICAgIHJlbGF0ZWQgdG8gbWFudWZhY3R1cmluZywgYXNzZXQgYW5kIHNpdHVhdGlvbiBtYW5h Z2VtZW50IG9yDQ0KICAgICAgIHByb2Nlc3MgY29udHJvbC4gIEZvciB0aGUgbWFuYWdlbWVudCBv ZiBhIGZhY3RvcnkgaXQgaXMNDQogICAgICAgYmVjb21pbmcgZXNzZW50aWFsIHRvIGltcGxlbWVu dCBzbWFydCBjYXBhYmlsaXRpZXMuICBGcm9tIGFuDQ0KICAgICAgIGVuZ2luZWVyaW5nIHN0YW5k cG9pbnQsIGluZHVzdHJpYWwgYXBwbGljYXRpb25zIGFyZSBpbnRlbGxpZ2VudA0NCiAgICAgICBz eXN0ZW1zIGVuYWJsaW5nIHJhcGlkIG1hbnVmYWN0dXJpbmcgb2YgbmV3IHByb2R1Y3RzLCBkeW5h bWljDQ0KICAgICAgIHJlc3BvbnNlIHRvIHByb2R1Y3QgZGVtYW5kLCBhbmQgcmVhbC10aW1lIG9w dGltaXphdGlvbiBvZg0NCiAgICAgICBtYW51ZmFjdHVyaW5nIHByb2R1Y3Rpb24gYW5kIHN1cHBs eSBjaGFpbiBuZXR3b3Jrcy4gIFBvdGVudGlhbA0NCiAgICAgICBpbmR1c3RyaWFsIGFwcGxpY2F0 aW9ucyBlLmcuIGZvciBzbWFydCBmYWN0b3JpZXMgYW5kIHNtYXJ0DQ0KICAgICAgIG1hbnVmYWN0 dXJpbmcgYXJlOiINDQoNDQooYykgT2YgY291cnNlLCBpdCBpcyBzdGlsbCBwb3NzaWJsZSB0aGF0 IEJ1aWxkaW5nIEF1dG9tYXRpb24gbWF5IGJlDQ0KICAgIHBlcmZvcm1lZCBvciBpbnRlcmZhY2Vk IHdpdGggaW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGUgZ29hbHMgb2YgYW4NDQogICAgSW5kdXN0cmlh bCBBcHBsaWNhdGlvbi4gRm9yIGV4YW1wbGUsIGEgc3RlZWwgbWFudWZhY3R1cmluZyBwbGFudA0N CiAgICBtYXkgdXNlIGEgYnVpbGRpbmcgbWFuYWdlbWVudCBzeXN0ZW0gdG8gY29udHJvbCB0aGUg dGVtcGVyYXR1cmUgb2YNDQogICAgYSBmdXJuYWNlIGluIG9yZGVyIHRvIGNoYW5nZSB0aGUgZ3Jh ZGUgb2Ygc3RlZWwgcHJvZHVjZWQuDQ0KDQ0KICAgIEl0IGlzIGxpa2VseSBpbXBvcnRhbnQgdG8g aGlnaGxpZ2h0IHRoYXQgZXZlbiB0aG91Z2ggdGhlcmUgbWlnaHQNDQogICAgYmUgc29tZSBkaWZm ZXJlbmNlcyBiZXR3ZWVuIHRoZSBhcHBsaWNhdGlvbiBzY2VuYXJpb3MsIGluIHNvbWUNDQogICAg c2l0dWF0aW9ucyB0aGUgYm91bmRhcmllcyBtaWdodCBiZSBibHVycmVkLCBzbyB0aGF0IHRoZSBy ZWFkZXINDQogICAgdW5kZXJzdGFuZHMgdGhhdCBzb21lIGFwcGxpY2F0aW9ucyBzY2VuYXJpb3Mg YXJlIGNsb3NlbHkNDQogICAgY291cGxlZC4gQW5vdGhlciBleGFtcGxlIG9mIGludGVyc2VjdCBp cyB0aGF0IGJldHdlZW4gSW5kdXN0cmlhbA0NCiAgICBBcHBsaWNhdGlvbnMgYW5kIEVudmlyb25t ZW50YWwgTW9uaXRvcmluZywgZXNwZWNpYWxseSB3aGVuIGl0DQ0KICAgIGNvbWVzIHRvIE51Y2xl YXIgRW5lcmd5IFBsYW50cy4NDQoNDQogICAgQXMgc3VjaCwgSSBwcm9wb3NlIGFkZGluZyBhIG5l dyBzZWNvbmQgcGFyYWdyYXBoIHRvIGNsYXJpZnkgdGhpcw0NCiAgICBpbnRlcnNlY3QgdGhhdCBt YXkgb2NjdXIsIGJ1dCBzdGlsbCBrZWVwIEJ1aWxkaW5nIEF1dG9tYXRpb24NDQogICAgc2VwYXJh dGUgZnJvbSBJbmR1c3RyaWFsIEFwcGxpY2F0aW9ucyBpbiBnZW5lcmFsOg0NCg0NCiAgICAgICAi TWFuYWdlbWVudCBvZiBJbmR1c3RyaWFsIEFwcGxpY2F0aW9ucyBhbmQgc21hcnQgbWFudWZhY3R1 cmluZw0NCiAgICAgICBtYXkgaW4gc29tZSBzaXR1YXRpb25zIGJlIGFjaGlldmVkIGJ5IGludGVy ZmFjaW5nIHdpdGggYW5kDQ0KICAgICAgIGNvbXBsZXRpbmcgQnVpbGRpbmcgQXV0b21hdGlvbiB0 YXNrcyBzdWNoIGFzIGNvbnRyb2wgb2YgZW5lcmd5LA0NCiAgICAgICBIVkFDIChoZWF0aW5nLCB2 ZW50aWxhdGlvbiwgYW5kIGFpciBjb25kaXRpb25pbmcpLCBsaWdodGluZywNDQogICAgICAgYWNj ZXNzIGNvbnRyb2wsIGFuZCBldGMuIEludGVyYWN0aW5nIHdpdGggbWFuYWdlbWVudCBzeXN0ZW1z DQ0KICAgICAgIGZyb20gb3RoZXIgYXBwbGljYXRpb24gYXJlYXMgbWlnaHQgYWxzbyBiZSBpbXBv cnRhbnQgaW4gc29tZQ0NCiAgICAgICBjYXNlcyAoZS5nLiBlbnZpcm9ubWVudGFsIG1vbml0b3Jp bmcgZm9yIG51Y2xlYXIgZW5lcmd5DQ0KICAgICAgIHByb2R1Y3Rpb24sIGVuZXJneSBtYW5hZ2Vt ZW50IGZvciBkeW5hbWljYWxseSBzY2FsaW5nDQ0KICAgICAgIG1hbnVmYWN0dXJpbmcsIHZlaGlj dWxhciBuZXR3b3JrcyBmb3IgbW9iaWxlIGFzc2V0IHRyYWNraW5nIGFuZA0NCiAgICAgICBldGMu KS4iDQ0KDQ0KICAgIEluIGNhc2UgYW4gZXhhbXBsZSBvZiBzdWNoIGEgc2NlbmFyaW8gaXMgcmVx dWlyZWQsIGl0IGNvdWxkIGJlDQ0KICAgIGFkZGVkIGFzIHdlbGwuDQ0KDQ0KKGQpIEFzIHN1Y2gs IGluIHRvdGFsaXR5IHRoZSBuZXcgZmlyc3QgdHdvIHBhcmFncmFwaHMgb2YgdGhpcyBzZWN0aW9u DQ0KICAgIHdvdWxkIHJlYWQ6DQ0KDQ0KICAgICAgICJJbmR1c3RyaWFsIEFwcGxpY2F0aW9ucyBh bmQgc21hcnQgbWFudWZhY3R1cmluZyByZWZlciB0bw0NCiAgICAgICBuZXR3b3JrZWQgY29udHJv bCBhbmQgbW9uaXRvcmluZyBvZiB0YXNrcyBzdWNoIGFzIGVxdWlwbWVudA0NCiAgICAgICByZWxh dGVkIHRvIG1hbnVmYWN0dXJpbmcsIGFzc2V0IGFuZCBzaXR1YXRpb24gbWFuYWdlbWVudCBvcg0N CiAgICAgICBwcm9jZXNzIGNvbnRyb2wuICBGb3IgdGhlIG1hbmFnZW1lbnQgb2YgYSBmYWN0b3J5 IGl0IGlzDQ0KICAgICAgIGJlY29taW5nIGVzc2VudGlhbCB0byBpbXBsZW1lbnQgc21hcnQgY2Fw YWJpbGl0aWVzLiAgRnJvbSBhbg0NCiAgICAgICBlbmdpbmVlcmluZyBzdGFuZHBvaW50LCBpbmR1 c3RyaWFsIGFwcGxpY2F0aW9ucyBhcmUgaW50ZWxsaWdlbnQNDQogICAgICAgc3lzdGVtcyBlbmFi bGluZyByYXBpZCBtYW51ZmFjdHVyaW5nIG9mIG5ldyBwcm9kdWN0cywgZHluYW1pYw0NCiAgICAg ICByZXNwb25zZSB0byBwcm9kdWN0IGRlbWFuZCwgYW5kIHJlYWwtdGltZSBvcHRpbWl6YXRpb24g b2YNDQogICAgICAgbWFudWZhY3R1cmluZyBwcm9kdWN0aW9uIGFuZCBzdXBwbHkgY2hhaW4gbmV0 d29ya3MuICBQb3RlbnRpYWwNDQogICAgICAgaW5kdXN0cmlhbCBhcHBsaWNhdGlvbnMgZS5nLiBm b3Igc21hcnQgZmFjdG9yaWVzIGFuZCBzbWFydA0NCiAgICAgICBtYW51ZmFjdHVyaW5nIGFyZToN DQoNDQogICAgICAgICAqIGJ1bGxldCBwb2ludHMgZm9sbG93DQ0KDQ0KICAgICAgIE1hbmFnZW1l bnQgb2YgSW5kdXN0cmlhbCBBcHBsaWNhdGlvbnMgYW5kIHNtYXJ0IG1hbnVmYWN0dXJpbmcNDQog ICAgICAgbWF5IGluIHNvbWUgc2l0dWF0aW9ucyBiZSBhY2hpZXZlZCBieSBpbnRlcmZhY2luZyB3 aXRoIGFuZA0NCiAgICAgICBjb21wbGV0aW5nIEJ1aWxkaW5nIEF1dG9tYXRpb24gdGFza3Mgc3Vj aCBhcyBjb250cm9sIG9mIGVuZXJneSwNDQogICAgICAgSFZBQyAoaGVhdGluZywgdmVudGlsYXRp b24sIGFuZCBhaXIgY29uZGl0aW9uaW5nKSwgbGlnaHRpbmcsDQ0KICAgICAgIGFjY2VzcyBjb250 cm9sLCBhbmQgZXRjLiBJbnRlcmFjdGluZyB3aXRoIG1hbmFnZW1lbnQgc3lzdGVtcw0NCiAgICAg ICBmcm9tIG90aGVyIGFwcGxpY2F0aW9uIGFyZWFzIG1pZ2h0IGFsc28gYmUgaW1wb3J0YW50IGlu IHNvbWUNDQogICAgICAgY2FzZXMgKGUuZy4gZW52aXJvbm1lbnRhbCBtb25pdG9yaW5nIGZvciBu dWNsZWFyIGVuZXJneQ0NCiAgICAgICBwcm9kdWN0aW9uLCBlbmVyZ3kgbWFuYWdlbWVudCBmb3Ig ZHluYW1pY2FsbHkgc2NhbGluZw0NCiAgICAgICBtYW51ZmFjdHVyaW5nLCB2ZWhpY3VsYXIgbmV0 d29ya3MgZm9yIG1vYmlsZSBhc3NldCB0cmFja2luZyBhbmQNDQogICAgICAgZXRjLikuIg0NCg0N CihlKSBEaWZmIG9mIHRoZSBuZXcgYW5kIG9sZCB0ZXh0IGlzIGF0dGFjaGVkLg0NCg0NCg0NCjIu NCBIb21lIEF1dG9tYXRpb24NDQotLS0tLS0tLS0tLS0tLS0tLS0tDQ0KDQ0KKGEpIE1ha2UgdGhl IHNlY3Rpb24gb24gQnVpbGRpbmcgQXV0b21hdGlvbiBzZWN0aW9uIDIuMywgdGhlcmVieQ0NCiAg ICBtb3ZpbmcgSW5kdXN0cmlhbCBhcHBsaWNhdGlvbnMgdG8gMi41IGFuZCBIb21lIGF1dG9tYXRp b24gdG8gMi41LA0NCiAgICBzaW5jZSBhIHJlZmVyZW5jZSB0byBCdWlsZGluZyBBdXRvbWF0aW9u IGxpa2Ugc2NlbmFyaW9zIGV4aXN0IGluDQ0KICAgIGJvdGggb2YgdGhlc2UgYXJlYXMgYXMgd2Vs bC4NDQoNDQooYikgSSBwcm9wb3NlIGluY2x1ZGluZyBzZWN1cml0eSBpbmZyYXN0cnVjdHVyZSBp bnRvIGhvbWUgYXV0b21hdGlvbg0NCiAgICBhcyB3ZWxsLCBzaW5jZSB0aGlzIGlzIGFscmVhZHkg YSBzaWduaWZpY2FudCBtYXJrZXQgdGhhdCBpcw0NCiAgICBvcGVyYXRlZCBhbmQgbWFpbnRhaW5l ZCBieSBlaXRoZXIgaG9tZSB1c2Vycywgb3IgY29udHJhY3RpbmcNDQogICAgYWdlbmNpZXMgbGlr ZSBBRFQuIEZ1cnRoZXJtb3JlLCBzZWN1cml0eSBzZXJ2aWNlcyBhbHNvIGNvbnNpc3Qgb2YNDQog ICAgY29uc3RyYWluZWQgZGV2aWNlcywgZXNwZWNpYWxseSBpbiB0aGUgZm9ybSBvZiBzZW5zb3Jz Lg0NCg0NCiAgICBBcyBzdWNoLCB0aGUgZmlyc3QgcGFyYWdyYXBoIGNvdWxkIGJlIGNoYW5nZWQg dG8gdGhlIGZvbGxvd2luZzoNDQoNDQogICAgICAgIkhvbWUgYXV0b21hdGlvbiBpbmNsdWRlcyB0 aGUgY29udHJvbCBvZiBsaWdodGluZywgaGVhdGluZywNDQogICAgICAgdmVudGlsYXRpb24sIGFp ciBjb25kaXRpb25pbmcsIGFwcGxpYW5jZXMsIGVudGVydGFpbm1lbnQgYW5kDQ0KICAgICAgIGhv bWUgc2VjdXJpdHkgZGV2aWNlcyB0byBpbXByb3ZlIGNvbnZlbmllbmNlLCBjb21mb3J0LCBlbmVy Z3kNDQogICAgICAgZWZmaWNpZW5jeSwgYW5kIHNlY3VyaXR5LiBJdCBjYW4gYmUgc2VlbiBhcyBh IHJlc2lkZW50aWFsDQ0KICAgICAgIGV4dGVuc2lvbiBvZiBidWlsZGluZyBhdXRvbWF0aW9uLiIN DQoNDQooYykgVGhlIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIGhvbWUgYXV0b21hdGlvbiBhbmQg YnVpbGRpbmcNDQogICAgYXV0b21hdGlvbiBpcyBub3QgdmVyeSBjbGVhciBhdCB0aGlzIHBvaW50 LiBBbiBleHRlbnNpb24gdG8gdGhlDQ0KICAgIGZpcnN0IHBhcmFncmFwaCBjYW4gYmUgbWFkZSBp biB0aGUgZm9sbG93aW5nIHdheToNDQoNDQogICAgICAgIkl0IGNhbiBiZSBzZWVuIGFzIGEgcmVz aWRlbnRpYWwgZXh0ZW5zaW9uIG9mIGJ1aWxkaW5nDQ0KICAgICAgIGF1dG9tYXRpb24uIEhvd2V2 ZXIsIGl0IGlzIGV4cGVjdGVkIHRoYXQgdW5saWtlIGEgYnVpbGRpbmcNDQogICAgICAgYXV0b21h dGlvbiBzeXN0ZW0gdGhlIGluZnJhc3RydWN0dXJlIGluIGEgaG9tZSBpcyBvcGVyYXRlZCBpbiBh DQ0KICAgICAgIGNvbnNpZGVyYWJseSBtb3JlIGFkLWhvYyBuYXR1cmUsIHdpdGggbm8gY2VudHJh bGl6ZWQgbWFuYWdlbWVudA0NCiAgICAgICBzeXN0ZW0gYWtpbiB0byBhIEJ1aWxkaW5nIEF1dG9t YXRpb24gU3lzdGVtIChCQVMpIGF2YWlsYWJsZSB0bw0NCiAgICAgICBjb25jZW50cmF0ZSB2YXJp b3VzIGZ1bmN0aW9ucyB0b2dldGhlci4iDQ0KDQ0KKGQpIEN1cnJlbnRseSB0aGUgZHJhZnQgc3Vn Z2VzdHMgdGhhdCBob21lIGF1dG9tYXRpb24gY29uZmlndXJhdGlvbg0NCiAgICBzZXJ2aWNlcyBt YXkgYmUgcHJvdmlkZWQgYnkgZWxlY3RyaWNpYW5zLiBCdXQsIGluIHRpbWUsIHRoZXJlDQ0KICAg IG1pZ2h0IGJlIG90aGVyIHBsYXllcnMgdGhhdCBlbWVyZ2UgaW4gdGhpcyBtYXJrZXQgYXMgd2Vs bCAoSVNQcywNDQogICAgc21hbGwgcHJpdmF0ZSBjb21wYW5pZXMsIGRldmljZSBtYW51ZmFjdHVy ZXJzIGFuZCBldGMuKS4gVGhpcw0NCiAgICBtYWtlcyBpdCBsaWtlbHkgdGhhdCBjb25maWd1cmF0 aW9uIGFuZCBtYW5hZ2VtZW50IHNlcnZpY2VzIG1heSBiZQ0NCiAgICBwcm92aWRlZCB0byBob21l IHVzZXJzLCBzaW1pbGFyIHRvIHRoZSB3YXkgaXQgaXMgb2ZmZXJlZCBpbiB0aGUNDQogICAgaG9t ZSBzZWN1cml0eSBzcGhlcmUgdG9kYXkuDQ0KDQ0KICAgIEFzIHN1Y2gsIEkgcmVjb21tZW5kIHRo ZSBmb2xsb3dpbmcgbW9kaWZpY2F0aW9uIHRvIHRoZSBzZWNvbmQNDQogICAgcGFyYWdyYXBoOg0N Cg0NCiAgICAgICAiSG9tZSBhdXRvbWF0aW9uIG5ldHdvcmtzIG5lZWQgYSBjZXJ0YWluIGFtb3Vu dCBvZg0NCiAgICAgICBjb25maWd1cmF0aW9uIChhc3NvY2lhdGluZyBzd2l0Y2hlcyBvciBzZW5z b3JzIHRvIGFjdG9ycykgdGhhdA0NCiAgICAgICBpcyBlaXRoZXIgcHJvdmlkZWQgYnkgZWxlY3Ry aWNpYW5zIGRlcGxveWluZyBob21lIGF1dG9tYXRpb24NDQogICAgICAgc29sdXRpb25zLCB0aGly ZCBwYXJ0eSBzZXJ2aWNlIHByb3ZpZGVycyAoSVNQcywgc21hbGwNDQogICAgICAgb3V0c291cmNp bmcgZmlybXMsIGRldmljZSBtYW51ZmFjdHVyZXJzLCBvbmxpbmUgcG9ydGFscyBhbmQNDQogICAg ICAgZXRjLikgb3IgZG9uZSBieSByZXNpZGVudHMgYnkgdXNpbmcgdGhlIGFwcGxpY2F0aW9uIHVz ZXINDQogICAgICAgaW50ZXJmYWNlIHRvIGNvbmZpZ3VyZSAocGFydHMgb2YpIHRoZSBob21lIGF1 dG9tYXRpb24NDQogICAgICAgc29sdXRpb24uIFNpbWlsYXJseSwgZmFpbHVyZXMgbWF5IGJlIHJl cG9ydGVkIHZpYSBzdWl0YWJsZQ0NCiAgICAgICBpbnRlcmZhY2VzIHRvIHJlc2lkZW50cyBvciB0 aGV5IG1pZ2h0IGJlIHJlY29yZGVkIGFuZCBtYWRlDQ0KICAgICAgIGF2YWlsYWJsZSB0byBzZXJ2 aWNlIHByb3ZpZGVycyBpbiBjaGFyZ2Ugb2YgdGhlIG1haW50ZW5hbmNlIG9mDQ0KICAgICAgIHRo ZSBob21lIGF1dG9tYXRpb24gaW5mcmFzdHJ1Y3R1cmUuIg0NCg0NCihlKSBCYXNlZCBvbiB0aGUg YWRkaXRpb24gb2YgdGhpcmQgcGFydHkgc2VydmljZSBwcm92aWRlcnMsIHRoZSBsYXN0DQ0KICAg IHBhcmFncmFwaCBjb3VsZCBiZSBleHRlbmRlZCBhcyB3ZWxsOg0NCg0NCiAgICAgICAiVGhlIG1h bmFnZW1lbnQgcmVzcG9uc2liaWxpdHkgbGllcyBlaXRoZXIgd2l0aCB0aGUgcmVzaWRlbnRzDQ0K ICAgICAgIG9yIGl0IG1heSBiZSBvdXRzb3VyY2VkIHRvIGVsZWN0cmljaWFucyBhbmQvb3IgdGhp cmQgcGFydGllcw0NCiAgICAgICBwcm92aWRpbmcgbWFuYWdlbWVudCBvZiBob21lIGF1dG9tYXRp b24gc29sdXRpb25zIGFzIGEgc2VydmljZS4NDQogICAgICAgQSB2YXJ5aW5nIGNvbWJpbmF0aW9u IG9mIGVsZWN0cmljaWFucywgc2VydmljZSBwcm92aWRlcnMgb3IgdGhlDQ0KICAgICAgIHJlc2lk ZW50cyBtYXkgYmUgcmVzcG9uc2libGUgZm9yIGRpZmZlcmVudCBhc3BlY3RzIG9mIG1hbmFnaW5n DQ0KICAgICAgIHRoZSBpbmZyYXN0cnVjdHVyZS4gIFRoZSB0aW1lIHNjYWxlIGZvciBmYWlsdXJl IGRldGVjdGlvbiBhbmQNDQogICAgICAgcmVzb2x1dGlvbiBpcyBpbiBtYW55IGNhc2VzIGxpa2Vs eSBjb3VudGVkIGluIGhvdXJzIHRvIGRheXMuIg0NCg0NCihmKSBUaGlzIGNhdXNlcyB0aGUgbmV3 IHRleHQgb2YgdGhlIHNlY3Rpb24gb24gSG9tZSBBdXRvbWF0aW9uIHRvIHJlYWQNDQogICAgYXMg YmVsb3c6DQ0KDQ0KICAgICAgICJIb21lIGF1dG9tYXRpb24gaW5jbHVkZXMgdGhlIGNvbnRyb2wg b2YgbGlnaHRpbmcsIGhlYXRpbmcsDQ0KICAgICAgIHZlbnRpbGF0aW9uLCBhaXIgY29uZGl0aW9u aW5nLCBhcHBsaWFuY2VzLCBlbnRlcnRhaW5tZW50IGFuZA0NCiAgICAgICBob21lIHNlY3VyaXR5 IGRldmljZXMgdG8gaW1wcm92ZSBjb252ZW5pZW5jZSwgY29tZm9ydCwgZW5lcmd5DQ0KICAgICAg IGVmZmljaWVuY3ksIGFuZCBzZWN1cml0eS4gDQ0KDQ0KICAgICAgIEl0IGNhbiBiZSBzZWVuIGFz IGEgcmVzaWRlbnRpYWwgZXh0ZW5zaW9uIG9mIGJ1aWxkaW5nDQ0KICAgICAgIGF1dG9tYXRpb24u IEhvd2V2ZXIsIGl0IGlzIGV4cGVjdGVkIHRoYXQgdW5saWtlIGEgYnVpbGRpbmcNDQogICAgICAg YXV0b21hdGlvbiBzeXN0ZW0gdGhlIGluZnJhc3RydWN0dXJlIGluIGEgaG9tZSBpcyBvcGVyYXRl ZCBpbiBhDQ0KICAgICAgIGNvbnNpZGVyYWJseSBtb3JlIGFkLWhvYyBuYXR1cmUsIHdpdGggbm8g Y2VudHJhbGl6ZWQgbWFuYWdlbWVudA0NCiAgICAgICBzeXN0ZW0gYWtpbiB0byBhIEJ1aWxkaW5n IEF1dG9tYXRpb24gU3lzdGVtIChCQVMpIGF2YWlsYWJsZSB0bw0NCiAgICAgICBjb25jZW50cmF0 ZSB2YXJpb3VzIGZ1bmN0aW9ucyB0b2dldGhlci4NDQoNDQogICAgICAgSG9tZSBhdXRvbWF0aW9u IG5ldHdvcmtzIG5lZWQgYSBjZXJ0YWluIGFtb3VudCBvZiBjb25maWd1cmF0aW9uDQ0KICAgICAg IChhc3NvY2lhdGluZyBzd2l0Y2hlcyBvciBzZW5zb3JzIHRvIGFjdG9ycykgdGhhdCBpcyBlaXRo ZXINDQogICAgICAgcHJvdmlkZWQgYnkgZWxlY3RyaWNpYW5zIGRlcGxveWluZyBob21lIGF1dG9t YXRpb24gc29sdXRpb25zLA0NCiAgICAgICB0aGlyZCBwYXJ0eSBzZXJ2aWNlIHByb3ZpZGVycyAo SVNQcywgc21hbGwgb3V0c291cmNpbmcgZmlybXMsDQ0KICAgICAgIGRldmljZSBtYW51ZmFjdHVy ZXJzLCBvbmxpbmUgcG9ydGFscyBhbmQgZXRjLikgb3IgZG9uZSBieQ0NCiAgICAgICByZXNpZGVu dHMgYnkgdXNpbmcgdGhlIGFwcGxpY2F0aW9uIHVzZXIgaW50ZXJmYWNlIHRvIGNvbmZpZ3VyZQ0N CiAgICAgICAocGFydHMgb2YpIHRoZSBob21lIGF1dG9tYXRpb24gc29sdXRpb24uIFNpbWlsYXJs eSwgZmFpbHVyZXMNDQogICAgICAgbWF5IGJlIHJlcG9ydGVkIHZpYSBzdWl0YWJsZSBpbnRlcmZh Y2VzIHRvIHJlc2lkZW50cyBvciB0aGV5DQ0KICAgICAgIG1pZ2h0IGJlIHJlY29yZGVkIGFuZCBt YWRlIGF2YWlsYWJsZSB0byBzZXJ2aWNlIHByb3ZpZGVycyBpbg0NCiAgICAgICBjaGFyZ2Ugb2Yg dGhlIG1haW50ZW5hbmNlIG9mIHRoZSBob21lIGF1dG9tYXRpb24NDQogICAgICAgaW5mcmFzdHJ1 Y3R1cmUuDQ0KDQ0KICAgICAgIFRoZSBtYW5hZ2VtZW50IHJlc3BvbnNpYmlsaXR5IGxpZXMgZWl0 aGVyIHdpdGggdGhlIHJlc2lkZW50cyBvcg0NCiAgICAgICBpdCBtYXkgYmUgb3V0c291cmNlZCB0 byBlbGVjdHJpY2lhbnMgYW5kL29yIHRoaXJkIHBhcnRpZXMNDQogICAgICAgcHJvdmlkaW5nIG1h bmFnZW1lbnQgb2YgaG9tZSBhdXRvbWF0aW9uIHNvbHV0aW9ucyBhcyBhIHNlcnZpY2UuDQ0KICAg ICAgIEEgdmFyeWluZyBjb21iaW5hdGlvbiBvZiBlbGVjdHJpY2lhbnMsIHNlcnZpY2UgcHJvdmlk ZXJzIG9yIHRoZQ0NCiAgICAgICByZXNpZGVudHMgbWF5IGJlIHJlc3BvbnNpYmxlIGZvciBkaWZm ZXJlbnQgYXNwZWN0cyBvZiBtYW5hZ2luZw0NCiAgICAgICB0aGUgaW5mcmFzdHJ1Y3R1cmUuICBU aGUgdGltZSBzY2FsZSBmb3IgZmFpbHVyZSBkZXRlY3Rpb24gYW5kDQ0KICAgICAgIHJlc29sdXRp b24gaXMgaW4gbWFueSBjYXNlcyBsaWtlbHkgY291bnRlZCBpbiBob3VycyB0byBkYXlzLiINDQoN DQogICBBIGRpZmYgb2YgdGhlIHNlY3Rpb24gaXMgYXR0YWNoZWQuDQ0KDQ0KDQ0KMi4xMCBNb2Jp bGUgQXBwbGljYXRpb25zDQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ0KDQ0KKGEpIFRoZSB3 aG9sZSB1c2UgY2FzZSBvZiBNb2JpbGUgQXBwbGljYXRpb25zIGluIFNlY3Rpb24gMi4xMCBzZWVt cyB0bw0NCiAgICBiZSBub3QgcmVhbGx5IGEgdXNlIGNhc2UsIGJ1dCByYXRoZXIgc3BlY2lhbCBj YXNlcyByZWxhdGVkIHRvDQ0KICAgIGFjY2VzcyB0ZWNobm9sb2dpZXMuIA0NCg0NCiAgICBBbGwg dGhlIGlzc3VlcyBkaXNjdXNzZWQgaGVyZSBzZWVtIHRvIGJlIHVzZSBjYXNlIGlzc3VlcyB0aGF0 DQ0KICAgIHNob3VsZCBiZSBwYXJ0IG9mIG90aGVyIHVzZSBjYXNlIHN1Yi1zZWN0aW9ucy4gQXMg c3VjaCwgb25lDQ0KICAgIGFwcHJvYWNoIHRvIG92ZXJjb21pbmcgdGhpcyBwcm9ibGVtIHdvdWxk IGJlIHRvIG1lcmdlIHRoaXMNDQogICAgc3ViLXNlY3Rpb24gaW50byB0aGUgcHJldmlvdXMgc3Vi LXNlY3Rpb25zLiBBbm90aGVyIHBvc3NpYmlsaXR5IGlzDQ0KICAgIHRvIGNyZWF0ZSBhIG5ldyBz ZWN0aW9uIHRoYXQgZGlzY3Vzc2VzIG9ubHkgYWNjZXNzIHRlY2hub2xvZ2llcw0NCiAgICByYXRo ZXIgdGhhbiBhcHBsaWNhdGlvbiBzY2VuYXJpb3MuDQ0KDQ0KKGIpIEZvciB0aGUgc2FrZSBvZiBz aW1wbGljaXR5LCBJIHByb3Bvc2UgY3JlYXRpbmcgYSBuZXcgc2VjdGlvbiBmb3INDQogICAgYWNj ZXNzIHRlY2hub2xvZ2llczoNDQoNDQogICAgICAgIjMuIEFjY2VzcyBUZWNobm9sb2dpZXMNDQog ICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NDQoJDQ0KCUJlc2lkZXMgdGhlIG1hbmFnZW1l bnQgcmVxdWlyZW1lbnRzIGltcG9zZWQgYnkgdGhlIGRpZmZlcmVudA0NCgl1c2UgY2FzZXMsIHRo ZSBhY2Nlc3MgdGVjaG5vbG9naWVzIHVzZWQgYnkgdGhlIGNvbnN0cmFpbmVkDQ0KCWRldmljZXMg bWlnaHQgYWxzbyBpbXBvc2UgcmVzdHJpY3Rpb25zIGFuZCByZXF1aXJlbWVudHMgdXBvbg0NCgl0 aGUgTmV0d29yayBNYW5hZ2VtZW50IFN5c3RlbSAoTk1TKSBhbmQgcHJvdG9jb2wgb2YgY2hvaWNl Lg0NCg0NCglJdCBpcyBwb3NzaWJsZSB0aGF0IHNvbWUgbmV0d29ya3Mgb2YgY29uc3RyYWluZWQg ZGV2aWNlcyBtaWdodA0NCgl1dGlsaXplIHRyYWRpdGlvbmFsIG5vbi1jb25zdHJhaW5lZCBhY2Nl c3MgdGVjaG5vbG9naWVzLA0NCgllLmcuIExBTiwgZm9yIG5ldHdvcmsgYWNjZXNzLiBJbiBzdWNo IHNjZW5hcmlvcywgdGhlDQ0KCWNvbnN0cmFpbmVkbmVzcyBvZiB0aGUgZGV2aWNlIHByZXNlbnRz IHNwZWNpYWwgbWFuYWdlbWVudA0NCglyZXN0cmljdGlvbnMgYW5kIHJlcXVpcmVtZW50cyByYXRo ZXIgdGhhbiB0aGUgYWNjZXNzDQ0KCXRlY2hub2xvZ3kgdXRpbGl6ZWQuDQ0KDQ0KCUhvd2V2ZXIs IGluIG90aGVyIHNpdHVhdGlvbnMgY29uc3RyYWluZWQgb3IgbW9iaWxlIGFjY2Vzcw0NCgl0ZWNo bm9sb2dpZXMgbWlnaHQgYmUgdXNlZCBmb3IgbmV0d29yayBhY2Nlc3MsIHRoZXJlYnkgY2F1c2lu Zw0NCgltYW5hZ2VtZW50IHJlc3RyaWN0aW9ucyBhbmQgcmVxdWlyZW1lbnRzIHRvIGFyaXNlIGFz IGEgcmVzdWx0DQ0KCW9mIHRoZSB1bmRlcmx5aW5nIGFjY2VzcyB0ZWNobm9sb2dpZXMuDQ0KDQ0K CTMuMSBDb25zdHJhaW5lZCBBY2Nlc3MgVGVjaG5vbG9naWVzDQ0KCS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQ0KDQ0KCUR1ZSB0byByZXNvdXJjZSByZXN0cmljdGlvbnMsIGVt YmVkZGVkIGRldmljZXMgZGVwbG95ZWQgYXMNDQoJc2Vuc29ycyBhbmQgYWN0dWF0b3JzIGluIHRo ZSBhZm9yZW1lbnRpb25lZCB1c2UgY2FzZXMgY2FuDQ0KCXV0aWxpemUgbG93LXBvd2VyIGxvdyBk YXRhLXJhdGUgYWNjZXNzIHRlY2hub2xvZ2llcyBzdWNoIGFzDQ0KCUlFRUUgODAyLjE1LjQsIERF Q1QgVUxFIG9yIEJULUxFIGZvciBuZXR3b3JrIGNvbm5lY3Rpdml0eS4NDQoNDQoJSW4gc3VjaCBz aXR1YXRpb25zIGl0IGlzIGltcG9ydGFudCBmb3IgdGhlIE5NUyB0byBiZSBhd2FyZSBvZg0NCgl0 aGUgcmVzdHJpY3Rpb25zIGltcG9zZWQgYnkgdGhlc2UgdGVjaG5vbG9naWVzIGVmZmljaWVudGx5 DQ0KCW1hbmFnZSB0aGVzZSBjb25zdHJhaW5lZCBkZXZpY2VzLiBTcGVjaWZpY2FsbHksIHN1Y2gg bG93LXBvd2VyDQ0KCWxvdyBkYXRhLXJhdGUgYWNjZXNzIHRlY2hub2xvZ2llcyB0eXBpY2FsbHkg aGF2ZSBzbWFsbCBmcmFtZQ0NCglzaXplcy4gU28gaXQgd291bGQgYmUgaW1wb3J0YW50IGZvciB0 aGUgTk1TIGFuZCBtYW5hZ2VtZW50DQ0KCXByb3RvY29sIG9mIGNob2ljZSB0byBjcmFmdCBwYWNr ZXRzIGluIGEgd2F5IHRoYXQgYXZvaWRzDQ0KCWZyYWdtZW50YXRpb24gYW5kIHJlYXNzZW1ibHkg b2YgcGFja2V0cyBzaW5jZSB0aGlzIGNhbiB1c2UNDQoJdmFsdWFibGUgbWVtb3J5IG9uIGNvbnN0 cmFpbmVkIGRldmljZXMuDQ0KDQ0KCURldmljZXMgdXNpbmcgc3VjaCBhY2Nlc3MgdGVjaG5vbG9n aWVzIG1pZ2h0IG9wZXJhdGUgdmlhIGENDQoJZ2F0ZXdheSB0aGF0IHRyYW5zbGF0ZXMgYmV0d2Vl biB0aGVzZSBhY2Nlc3MgdGVjaG5vbG9naWVzIGFuZA0NCgltb3JlIHRyYWRpdGlvbmFsIEludGVy bmV0IHByb3RvY29scy4gQSBoaWVyYXJjaGljYWwgYXBwcm9hY2gNDQoJdG8gZGV2aWNlIG1hbmFn ZW1lbnQgaW4gc3VjaCBhIHNpdHVhdGlvbiBtaWdodCBiZSB1c2VmdWwsDQ0KCXdoZXJlaW4gdGhl IGdhdGV3YXkgZGV2aWNlIGlzIGluLWNoYXJnZSBvZiBkZXZpY2VzIGNvbm5lY3RlZA0NCgl0byBp dCwgd2hpbGUgdGhlIE5NUyBjb25kdWN0cyBtYW5hZ2VtZW50IG9wZXJhdGlvbnMgb25seSB0bw0N Cgl0aGUgZ2F0ZXdheS4NDQoNDQoJTW9iaWxlIEFjY2VzcyBUZWNobm9sb2dpZXMNDQoJLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NDQoNDQoJTTJNIHNlcnZpY2VzIGFyZSBpbmNyZWFzaW5nbHkg cHJvdmlkZWQgYnkgbW9iaWxlIHNlcnZpY2UNDQoJcHJvdmlkZXJzIGFzIG51bWVyb3VzIGRldmlj ZXMsIGhvbWUgYXBwbGlhbmNlcywgdXRpbGl0eQ0NCgltZXRlcnMsIGNhcnMsIHZpZGVvIHN1cnZl aWxsYW5jZSBjYW1lcmFzLCBhbmQgaGVhbHRoIG1vbml0b3JzLA0NCglhcmUgY29ubmVjdGVkIHdp dGggbW9iaWxlIGJyb2FkYmFuZCB0ZWNobm9sb2dpZXMuIERpZmZlcmVudA0NCglhcHBsaWNhdGlv bnMgZS5nLiBpbiBhIGhvbWUgYXBwbGlhbmNlIG9yIGluLWNhciBuZXR3b3JrIHVzZQ0NCglCbHVl dG9vdGgsIFdpLUZpIG9yIFppZ2JlZSBhbmQgY29ubmVjdCB0byBhIGNlbGx1bGFyIG1vZHVsZQ0N CglhY3RpbmcgYXMgYSBnYXRld2F5IGJldHdlZW4gdGhlIGNvbnN0cmFpbmVkIGVudmlyb25tZW50 IGFuZA0NCgl0aGUgbW9iaWxlIGNlbGx1bGFyIG5ldHdvcmsuDQ0KDQ0KCVN1Y2ggYSBnYXRld2F5 IG1pZ2h0IHByb3ZpZGUgZGlmZmVyZW50IG9wdGlvbnMgZm9yIHRoZQ0NCgljb25uZWN0aXZpdHkg b2YgbW9iaWxlIG5ldHdvcmtzIGFuZCBjb25zdHJhaW5lZCBkZXZpY2VzLCBlLmcuOg0NCg0NCglv IGEgc21hcnQgcGhvbmUgd2l0aCAzRy80RyBhbmQgV0xBTiByYWRpbyBtaWdodCB1c2UgQlQtTEUg dG8NDQoJICBjb25uZWN0IHRvIHRoZSBkZXZpY2VzIGluIGEgaG9tZSBhcmVhIG5ldHdvcmssDQ0K CQ0NCglvIGEgZmVtdG9jZWxsIG1pZ2h0IGJlIGNvbWJpbmVkIHdpdGggaG9tZSBnYXRld2F5DQ0K CSAgZnVuY3Rpb25hbGl0eSBhY3RpbmcgYXMgYSBsb3ctcG93ZXIgY2VsbHVsYXIgYmFzZSBzdGF0 aW9uDQ0KCSAgY29ubmVjdGluZyBzbWFydCBkZXZpY2VzIHRvIHRoZSBhcHBsaWNhdGlvbiBzZXJ2 ZXIgb2YgYQ0NCgkgIG1vYmlsZSBzZXJ2aWNlIHByb3ZpZGVyLA0NCg0NCglvIGFuIGVtYmVkZGVk IGNlbGx1bGFyIG1vZHVsZSB3aXRoIExURSByYWRpbyBjb25uZWN0aW5nIHRoZQ0NCgkgIGRldmlj ZXMgaW4gdGhlIGNhciBuZXR3b3JrIHdpdGggdGhlIHNlcnZlciBydW5uaW5nIHRoZQ0NCgkgIHRl bGVtYXRpY3Mgc2VydmljZSwNDQoNDQoJbyBhbiBNMk0gZ2F0ZXdheSBjb25uZWN0ZWQgdG8gdGhl IG1vYmlsZSBvcGVyYXRvciBuZXR3b3JrDQ0KCSAgc3VwcG9ydGluZyBkaXZlcnNlIElvVCBjb25u ZWN0aXZpdHkgdGVjaG5vbG9naWVzIGluY2x1ZGluZw0NCgkgIFppZ0JlZSBhbmQgQ29BUCBvdmVy IDZMb1dQQU4gb3ZlciBJRUVFIDgwMi4xNS40Lg0NCg0NCglDb21tb24gdG8gYWxsIHNjZW5hcmlv cyBhYm92ZSBpcyB0aGF0IHRoZXkgYXJlIGVtYmVkZGVkIGluIGENDQoJc2VydmljZSBhbmQgY29u bmVjdGVkIHRvIGEgbmV0d29yayBwcm92aWRlZCBieSBhIG1vYmlsZQ0NCglzZXJ2aWNlIHByb3Zp ZGVyLiBVc3VhbGx5IHRoZXJlIGlzIGEgaGllcmFyY2hpY2FsIGRlcGxveW1lbnQNDQoJYW5kIG1h bmFnZW1lbnQgdG9wb2xvZ3kgaW4gcGxhY2Ugd2hlcmUgZGlmZmVyZW50IHBhcnRzIG9mIHRoZQ0N CgluZXR3b3JrIGFyZSBtYW5hZ2VkIGJ5IGRpZmZlcmVudCBtYW5hZ2VtZW50IGVudGl0aWVzIGFu ZCB0aGUNDQoJY291bnQgb2YgZGV2aWNlcyB0byBtYW5hZ2UgaXMgaGlnaCAoZS5nLiAgbWFueSB0 aG91c2FuZHMpLiAgSW4NDQoJZ2VuZXJhbCwgdGhlIG5ldHdvcmsgaXMgY29tcHJpc2VkIGJ5IG1h bmlmb2xkIHR5cGUgYW5kIHNpemUgb2YNDQoJZGV2aWNlcyBtYXRjaGluZyB0byBkaWZmZXJlbnQg ZGV2aWNlIGNsYXNzZXMuICBBcyBzdWNoLCB0aGUNDQoJbWFuYWdpbmcgZW50aXR5IG5lZWRzIHRv IGJlIHByZXBhcmVkIHRvIG1hbmFnZSBkZXZpY2VzIHdpdGgNDQoJZGl2ZXJzZSBjYXBhYmlsaXRp ZXMgdXNpbmcgZGlmZmVyZW50IGNvbW11bmljYXRpb24gb3INDQoJbWFuYWdlbWVudCBwcm90b2Nv bHMuICBJbiBjYXNlIHRoZSBkZXZpY2VzIGFyZSBkaXJlY3RseQ0NCgljb25uZWN0ZWQgdG8gYSBn YXRld2F5IHRoZXkgbW9zdCBsaWtlbHkgYXJlIG1hbmFnZWQgYnkgYQ0NCgltYW5hZ2VtZW50IGVu dGl0eSBpbnRlZ3JhdGVkIHdpdGggdGhlIGdhdGV3YXksIHdoaWNoIGl0c2VsZiBpcw0NCglwYXJ0 IG9mIHRoZSBOZXR3b3JrIE1hbmFnZW1lbnQgU3lzdGVtIChOTVMpIHJ1biBieSB0aGUgbW9iaWxl DQ0KCW9wZXJhdG9yLiAgU21hcnQgcGhvbmVzIG9yIGVtYmVkZGVkIG1vZHVsZXMgY29ubmVjdGVk IHRvIGENDQoJZ2F0ZXdheSBtaWdodCBiZSB0aGVtc2VsdmVzIGluIGNoYXJnZSB0byBtYW5hZ2Ug dGhlIGRldmljZXMgb24NDQoJdGhlaXIgbGV2ZWwuICBUaGUgaW5pdGlhbCBhbmQgc3Vic2VxdWVu dCBjb25maWd1cmF0aW9uIG9mIHN1Y2gNDQoJYSBkZXZpY2UgaXMgbWFpbmx5IGJhc2VkIG9uIHNl bGYtY29uZmlndXJhdGlvbiBhbmQgaXMNDQoJdHJpZ2dlcmVkIGJ5IHRoZSBkZXZpY2UgaXRzZWxm Lg0NCg0NCglUaGUgZ2F0ZXdheSBtaWdodCBiZSBpbiBjaGFyZ2Ugb2YgZmlsdGVyaW5nIGFuZCBh Z2dyZWdhdGluZw0NCiAgIAl0aGUgZGF0YSByZWNlaXZlZCBmcm9tIHRoZSBkZXZpY2UgYXMgdGhl IGluZm9ybWF0aW9uIHNlbnQgYnkNDQogICAJdGhlIGRldmljZSBtaWdodCBiZSBtb3N0bHkgcmVk dW5kYW50LiINDQoNDQogICAgVGFsayBvZiBtb2JpbGl0eSBvZiBub2RlcyBoYXMgYmVlbiByZW1v dmVkIGZyb20gdGhpcyBzZWN0aW9uDQ0KICAgIGJlY2F1c2UgdGhpcyBzaG91bGQgZWl0aGVyIGJl IG1lcmdlZCBiYWNrIGludG8gaW5kaXZpZHVhbCB1c2UNDQogICAgY2FzZXMgd2hlcmVpbiBtb2Jp bGl0eSBpcyBleHBlY3RlZCwgb3IgYmUgbWVyZ2VkIGludG8gYSBzZWN0aW9uIG9uDQ0KICAgIFZl aGljdWxhciBOZXR3b3JrcyBhbmQgYSByZWZlcmVuY2UgbWFkZSB0byB0aGlzLCBhcyBuZWNlc3Nh cnkuDQ0KDQ0KDQ0KMi4xMiBNQU5FVCBDb25jZXB0IG9mIE9wZXJhdGlvbnMgKENPTk9QUykgaW4g TWlsaXRhcnkNDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0NCg0NCihhKSBTZWN0aW9uIDIuMTIsIE1BTkVUIENvbmNlcHQgb2YgT3BlcmF0aW9u cyAoQ09OT1BTKSBpbiBNaWxpdGFyeSwgaXMNDQogICAgY29uc2lkZXJhYmx5IG1vcmUgZGV0YWls ZWQgdGhhbiBhbnkgb2YgdGhlIG90aGVyIHVzZSBjYXNlDQ0KICAgIHNlY3Rpb25zLiBJbiBmYWN0 LCBhIGxvdCBvZiB0aGUgdGV4dCBoZXJlIGZvY3VzZXMgb24gdGhpbmdzIGxpa2UNDQogICAgaGll cmFyY2hpY2FsIG1hbmFnZW1lbnQsIHNwZWNpYWwgYWNjZXNzIHRlY2hub2xvZ2llcyBhbmQNDQog ICAgbW9iaWxpdHkuIFRoaXMgd2FzIGFsbCBjb3ZlcmVkIGluIG90aGVyIHVzZSBjYXNlcy4gDQ0K DQ0KICAgIEl0IHdvdWxkLCBhcyBzdWNoLCBtYWtlIG1vcmUgc2Vuc2UgdG8gcmUtd3JpdGUgdGhp cyBzZWN0aW9uIGluDQ0KICAgIGtlZXBpbmcgd2l0aCB0aGUgbGV2ZWwgb2YgZGV0YWlsIHByb3Zp ZGVkIGluIG90aGVyIHVzZSBjYXNlcywNDQogICAgd2hpbGUgc2hpZnRpbmcgdGhlIGZvY3VzIHRv IHB1cmVseSBtaWxpdGFyeSBhcHBsaWNhdGlvbnMgYW5kIHRoZQ0NCiAgICBzcGVjaWFsIGNvbmRp dGlvbnMgdGhhdCBjb21lIHdpdGggbWlsaXRhcnkgb3BlcmF0aW9ucy4NDQoNDQogICAgVGhpcyBj b3VsZCBjb3ZlciB0aGluZ3MgbGlrZSBpbmNyZWFzZWQgaW50ZXJuYXRpb25hbCBtaWxpdGFyeSB1 bml0DQ0KICAgIGNvb3BlcmF0aW9uIHRoYXQgYnJpbmcgYWxvbmcgd2l0aCBpdCBtdWx0aXBsZSBk aWZmZXJlbnQgc3RhbmRhcmRzLA0NCiAgICBiZXN0IHByYWN0aWNlcyBhbmQgY29uZmxpY3Rpbmcv Y29udHJhZGljdGluZyBpbXBsZW1lbnRhdGlvbg0NCiAgICBhcHByb2FjaGVzLg0NCg0NCiAgICBB cyBzdWNoLCBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBuZXcgdGV4dCBmb3IgdGhpcyBzZWN0aW9u Og0NCg0NCiAgICAiMi4xMiBNaWxpdGFyeSBPcGVyYXRpb25zDQ0KICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NDQoNDQogICAgVGhlIGNoYWxsZW5nZXMgb2YgY29uZmlndXJhdGlvbiBhbmQg bW9uaXRvcmluZyBvZiBuZXR3b3JrcyBmYWNlZA0NCiAgICBieSBtaWxpdGFyeSBhZ2VuY2llcyBj YW4gYmUgZGlmZmVyZW50IGZyb20gdGhlIG90aGVyIHVzZSBjYXNlcw0NCiAgICBzaW5jZSB0aGUg cmVxdWlyZW1lbnRzIGFuZCBvcGVyYXRpbmcgY29uZGl0aW9ucyBvZiBtaWxpdGFyeQ0NCiAgICBu ZXR3b3JrcyBhcmUgcXVpdGUgZGlmZmVyZW50Lg0NCiAgICANDQogICAgV2l0aCB0ZWNobm9sb2d5 IGFkdmFuY2VtZW50cywgbWlsaXRhcnkgbmV0d29ya3Mgbm93YWRheXMgaGF2ZQ0NCiAgICBiZWNv bWUgbGFyZ2UgYW5kIGNvbnNpc3Qgb2YgdmFyaWV0aWVzIG9mIGRpZmZlcmVudCB0eXBlcyBvZg0N CiAgICBlcXVpcG1lbnQgdGhhdCBydW4gZGlmZmVyZW50IHByb3RvY29scyBhbmQgdG9vbHMgdGhh dCBvYnZpb3VzbHkNDQogICAgaW5jcmVhc2UgY29tcGxleGl0eSBvZiB0aGUgdGFjdGljYWwgbmV0 d29ya3MuIEluIG1hbnkgc2NlbmFyaW9zLA0NCiAgICBjb25maWd1cmF0aW9ucyBhcmUsIG1vc3Qg bGlrZWx5LCBtYW51YWxseSBwZXJmb3JtZWQuIEZ1cnRoZXJtb3JlLA0NCiAgICBzb21lIGxlZ2Fj eSBhbmQgZXZlbiBtb2Rlcm4gZGV2aWNlcyBkbyBub3QgZXZlbiBzdXBwb3J0IElQDQ0KICAgIG5l dHdvcmtpbmcuIE1ham9yaXR5IG9mIHByb3RvY29scyBhbmQgdG9vbHMgZGV2ZWxvcGVkIGJ5IHZl bmRvcnMNDQogICAgdGhhdCBhcmUgYmVpbmcgdXNlZCBhcmUgcHJvcHJpZXRhcnkgd2hpY2ggbWFr ZXMgaW50ZWdyYXRpb24gbW9yZQ0NCiAgICBkaWZmaWN1bHQuDQ0KDQ0KICAgIFRoZSBtYWluIHJl YXNvbiBmb3IgdGhpcyBkaXNqb2ludCBvcGVyYXRpb24gc2NlbmFyaW8gaXMgdGhhdA0NCiAgICBt b3N0IG1pbGl0YXJ5IGVxdWlwbWVudCBpcyBkZXZlbG9wZWQgd2l0aCBzcGVjaWZpYyB0YXNrcw0N CiAgICByZXF1aXJlbWVudHMgaW4gbWluZCwgcmF0aGVyIHRoYW4gaW50ZXJvcGVyYWJpbGl0eSBv ZiB0aGUgdmFyaWVkDQ0KICAgIGVxdWlwbWVudCB0eXBlcy4gRm9yIGV4YW1wbGUsIHRoZSBvcGVy YXRpbmcgY29uZGl0aW9ucyBleHBlcmllbmNlZA0NCiAgICBieSBoaWdoIGFsdGl0dWRlIGVxdWlw bWVudCBpcyBzaWduaWZpY2FudGx5IGRpZmZlcmVudCBmcm9tIHRoYXQNDQogICAgdXNlZCBpbiBk ZXNlcnQgY29uZGl0aW9ucyBhbmQgaW50ZXJvcGVyYXRpb24gb2YgdGFjdGljYWwgZXF1aXBtZW50 DQ0KICAgIHdpdGggdGVsZWNvbW11bmljYXRpb24gZXF1aXBtZW50IHdhcyBub3QgYW4gZXhwZWN0 ZWQgb3V0Y29tZS4NDQoNDQogICAgQ3VycmVudGx5LCBtb3N0IG1pbGl0YXJ5IG5ldHdvcmtzIG9w ZXJhdGUgd2l0aCBhIGZpeGVkIE5ldHdvcmsNDQogICAgT3BlcmF0aW9ucyBDZW50ZXIgKE5PQykg dGhhdCBwaHlzaWNhbGx5IG1hbmFnZXMgdGhlIGNvbmZpZ3VyYXRpb24NDQogICAgYW5kIGV2YWx1 YXRpb24gb2YgYWxsIGZpZWxkIGRldmljZXMuIE9uY2UgY29uZmlndXJlZCwgdGhlIGRldmljZXMN DQogICAgbWlnaHQgYmUgZGVwbG95ZWQgaW4gZml4ZWQgb3IgbW9iaWxlIHNjZW5hcmlvcy4gQW55 IGNvbmZpZ3VyYXRpb24NDQogICAgY2hhbmdlcyByZXF1aXJlZCB3b3VsZCBuZWVkIHRvIGJlIGFw cHJvcHJpYXRlbHkgZW5jcnlwdGVkIGFuZA0NCiAgICBhdXRoZW50aWNhdGVkIHRvIHByZXZlbnQg dW5hdXRob3JpemVkIGFjY2Vzcy4NDQoNDQogICAgSGllcmFyY2hpY2FsIG1hbmFnZW1lbnQgb2Yg ZGV2aWNlcyBpcyBhIGNvbW1vbiByZXF1aXJlbWVudCBvZg0NCiAgICBtaWxpdGFyeSBvcGVyYXRp b25zIGFzIHdlbGwgc2luY2UgbG9jYWwgbWFuYWdlcnMgbWF5IG5lZWQgdG8NDQogICAgcmVzcG9u ZCB0byBjaGFuZ2luZyBjb25kaXRpb25zIHdpdGhpbiB0aGVpciBwbGF0b29uLCByZWdpbWVudCwN DQogICAgYnJpZ2FkZSwgZGl2aXNpb24gb3IgY29ycHMuIFRoZSBsZXZlbCBvZiBjb25maWd1cmF0 aW9uIG1hbmFnZW1lbnQNDQogICAgYXZhaWxhYmxlIGF0IGVhY2ggaGllcmFyY2h5IG11c3QgYWxz byBiZSBjbG9zZWx5IGdvdmVybmVkLg0NCiAgICANDQogICAgU2luY2UgbW9zdCBtaWxpdGFyeSBu ZXR3b3JrcyBvcGVyYXRlIGluIGhvc3RpbGUgZW52aXJvbm1lbnRzLCBhDQ0KICAgIGhpZ2ggZmFp bHVyZSByYXRlIGFuZCBkaXNjb25uZWN0aW9uIHJhdGUgc2hvdWxkIGJlIHRvbGVyYXRlZCBieQ0N CiAgICB0aGUgTmV0d29yayBNYW5hZ2VtZW50IFN5c3RlbSAoTk1TKSwgd2hpY2ggbXVzdCBhbHNv IGJlIGFibGUgdG8NDQogICAgZGVhbCB3aXRoIG11bHRpcGxlIGdhdGV3YXlzIGFuZCBkaXNqb2lu dCBtYW5hZ2VtZW50IHByb3RvY29scy4NDQoNDQogICAgTXVsdGktbmF0aW9uYWwgbWlsaXRhcnkg b3BlcmF0aW9ucyBhcmUgYmVjb21pbmcgaW5jcmVhc2luZ2x5DQ0KICAgIGNvbW1vbiwgcmVxdWly aW5nIHRoZSBpbnRlcm9wZXJhdGlvbiBvZiBhIGRpdmVyc2Ugc2V0IG9mIGVxdWlwbWVudA0NCiAg ICBkZXNpZ25lZCB3aXRoIGRpZmZlcmVudCBvcGVyYXRpbmcgY29uZGl0aW9ucyBpbiBtaW5kLiBG dXJ0aGVybW9yZSwNDQogICAgZGlmZmVyZW50IG1pbGl0YXJpZXMgYXJlIGxpa2VseSB0byBoYXZl IGEgZGlmZmVyZW50IHNldCBvZg0NCiAgICBzdGFuZGFyZHMsIGJlc3QgcHJhY3RpY2VzLCBydWxl cyBhbmQgcmVndWxhdGlvbiwgYW5kDQ0KICAgIGltcGxlbWVudGF0aW9uIGFwcHJvYWNoZXMgdGhh dCBtYXkgY29udHJhZGljdCBvciBjb25mbGljdCB3aXRoDQ0KICAgIGVhY2ggb3RoZXIuIFRoZSBO TVMgc2hvdWxkIGJlIGFibGUgdG8gZGV0ZWN0IHRoZXNlIGFuZCBoYW5kbGUgdGhlbQ0NCiAgICBp biBhbiBhY2NlcHRhYmxlIG1hbm5lciwgd2hpY2ggbWF5IHJlcXVpcmUgaHVtYW4gaW50ZXJ2ZW50 aW9uLiINDQoNDQoyLlRCRCBWZWhpY3VsYXIgTmV0d29ya3MNDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NDQoNDQooYSkgU2luY2UgdGhlcmUgYXJlIG1hbmFnZW1lbnQgcmVxdWlyZW1lbnRzIGFu ZCByZXN0cmljdGlvbnMgdGhhdA0NCiAgICBhcmlzZSBvdXQgb2YgbW9iaWxpdHkgb2Ygbm9kZXMs IGFuZCB2ZWhpY3VsYXIgbmV0d29ya3MgaXMgYSBjYXNlDQ0KICAgIHRoYXQgaGlnaGxpZ2h0cyB0 aGVzZSB3ZWxsLCBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIGluY2x1ZGUgdGhpcw0NCiAgICB1c2Ug Y2FzZSB3aXRoaW4gdGhlIGRvY3VtZW50IGFzIHdlbGwuDQ0KDQ0KICAgIEFzIGEgc3RhcnRpbmcg cG9pbnQsIEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQ6DQ0KDQ0KICAgICIyLlRCRCBWZWhp Y3VsYXIgTmV0d29ya3MNDQogICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0NCg0NCiAgICAg TmV0d29ya3MgaW52b2x2aW5nIG1vYmlsZSBub2RlcywgZXNwZWNpYWxseSB0cmFuc3BvcnQgdmVo aWNsZXMsDQ0KICAgICBhcmUgZW1lcmdpbmcgYXMgYSBuZXcgYXJlYS4gU3VjaCBuZXR3b3JrcyBh cmUgdXNlZCB0byBwcm92aWRlDQ0KICAgICBpbnRlci12ZWhpY2xlIGNvbW11bmljYXRpb24gc2Vy dmljZXMsIG9yIGV2ZW4gdHJhY2tpbmcgb2YgbW9iaWxlDQ0KICAgICBhc3NldHMsIHRvIGRldmVs b3AgaW50ZWxsaWdlbnQgdHJhbnNwb3J0YXRpb24gc3lzdGVtcyBhbmQgZHJpdmVycw0NCiAgICAg YW5kIHBhc3NlbmdlcnMgYXNzaXN0YW5jZSBzZXJ2aWNlcy4gQ29uc3RyYWluZWQgZGV2aWNlcyBh cmUNDQogICAgIGRlcGxveWVkIHdpdGhpbiBhIGxhcmdlciBzaW5nbGUgZW50aXR5LCB0aGUgdmVo aWNsZSwgYW5kIG11c3QgYmUNDQogICAgIGluZGl2aWR1YWxseSBtYW5hZ2VkIGluIHRoaXMgc2Nl bmFyaW8uDQ0KDQ0KICAgICBWZWhpY2xlcyBjYW4gYmUgZWl0aGVyIHByaXZhdGUsIGJlbG9uZ2lu ZyB0byBpbmRpdmlkdWFscyBvcg0NCiAgICAgcHJpdmF0ZSBjb21wYW5pZXMsIG9yIHB1YmxpYyB0 cmFuc3BvcnRhdGlvbi4gU2NlbmFyaW9zIGNvbnNpc3RpbmcNDQogICAgIG9mIHZlaGljbGUtdG8t dmVoaWNsZSBhZC1ob2MgbmV0d29ya3MsIGEgd2lyZWQgYmFja2JvbmUgd2l0aA0NCiAgICAgd2ly ZWxlc3MgbGFzdCBob3BzLCBhbmQgaHlicmlkIHZlaGljbGUtdG8tcm9hZCBjb21tdW5pY2F0aW9u cyBhcmUNDQogICAgIGV4cGVjdGVkIHRvIGJlIGNvbW1vbi4NDQoNDQogICAgIEJlc2lkZXMgdGhl IGFjY2VzcyBjb250cm9sIGFuZCBzZWN1cml0eSwgZGVwZW5kaW5nIG9uIHRoZSB0eXBlIG9mDQ0K ICAgICB2ZWhpY2xlIGFuZCBzZXJ2aWNlIGJlaW5nIHByb3ZpZGVkLCBpdCB3b3VsZCBiZSBpbXBv cnRhbnQgZm9yIGENDQogICAgIE5ldHdvcmsgTWFuYWdlbWVudCBTeXN0ZW0gKE5NUykgdG8gYmUg YWJsZSB0byBmdW5jdGlvbiB3aXRoDQ0KICAgICBkaWZmZXJlbnQgYXJjaGl0ZWN0dXJlcywgc2lu Y2UgZGlmZmVyZW50IG1hbnVmYWN0dXJlcnMgbWlnaHQgaGF2ZQ0NCiAgICAgdGhlaXIgb3duIHBy b3ByaWV0YXJ5IHN5c3RlbXMuDQ0KDQ0KICAgICBVbmxpa2Ugc29tZSBtb2JpbGUgbmV0d29ya3Ms IG1vc3QgdmVoaWN1bGFyIG5ldHdvcmtzIGFyZSBleHBlY3RlZA0NCiAgICAgdG8gaGF2ZSBzcGVj aWZpYyBwYXR0ZXJucyBpbiB0aGUgbW9iaWxpdHkgb2YgdGhlIG5vZGVzLiBTdWNoDQ0KICAgICBw YXR0ZXJucyBjb3VsZCBwb3NzaWJseSBiZSBleHBsb2l0ZWQsIG1hbmFnZWQgYW5kIG1vbml0b3Jl ZCBieQ0NCiAgICAgdGhlIE5NUy4NDQoNDQogICAgIFRoZSBjaGFsbGVuZ2VzIGluIHRoZSBtYW5h Z2VtZW50IG9mIHZlaGljbGVzIGluIGEgbW9iaWxlDQ0KICAgICBhcHBsaWNhdGlvbiBhcmUgbWFu aWZvbGQuIEZpcnN0bHksIHRoZSBpc3N1ZXMgY2F1c2VkIHRocm91Z2ggdGhlDQ0KICAgICBkZXZp Y2UgbW9iaWxpdHkgbmVlZCB0byBiZSB0YWtlbiBpbnRvIGNvbnNpZGVyYXRpb24uIFRoZQ0NCiAg ICAgdXAtdG8tZGF0ZSBwb3NpdGlvbiBvZiBlYWNoIG5vZGUgaW4gdGhlIG5ldHdvcmsgc2hvdWxk IGJlDQ0KICAgICByZXBvcnRlZCB0byB0aGUgY29ycmVzcG9uZGluZyBtYW5hZ2VtZW50IGVudGl0 aWVzLCBzaW5jZSB0aGUNDQogICAgIG5vZGVzIGNvdWxkIGJlIG1vdmluZyB3aXRoaW4gb3Igcm9h bWluZyBiZXR3ZWVuIGRpZmZlcmVudA0NCiAgICAgbmV0d29ya3MuIFNlY29uZGx5LCBhIHZhcmll dHkgb2YgdHJvdWJsZXNob290aW5nIGluZm9ybWF0aW9uLA0NCiAgICAgaW5jbHVkaW5nIHNlbnNp dGl2ZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiwgbmVlZHMgdG8gYmUgcmVwb3J0ZWQgdG8NDQogICAg IHRoZSBtYW5hZ2VtZW50IHN5c3RlbSBpbiBvcmRlciB0byBwcm92aWRlIGFjY3VyYXRlIHNlcnZp Y2UgdG8gdGhlDQ0KICAgICBjdXN0b21lci4NDQoNDQogICAgIFRoZSBOTVMgbXVzdCBhbHNvIGJl IGFibGUgdG8gaGFuZGxlIHBhcnRpdGlvbmVkIG5ldHdvcmtzLCB3aGljaA0NCiAgICAgd291bGQg YXJpc2UgZHVlIHRvIHRoZSBkeW5hbWljIG5hdHVyZSBvZiB0cmFmZmljIHJlc3VsdGluZyBpbg0N CiAgICAgbGFyZ2UgaW50ZXItdmVoaWNsZSBnYXBzIGluIHNwYXJzZWx5IHBvcHVsYXRlZCBzY2Vu YXJpb3MuIENvbnN0YW50DQ0KICAgICBjaGFuZ2VzIGluIHRvcG9sb2d5IG11c3QgYWxzbyBiZSBj b250ZW5kZWQgd2l0aC4NDQoNDQogICAgIEF1dG8tY29uZmlndXJhdGlvbiBvZiBub2RlcyBpbiBh IHZlaGljdWxhciBuZXR3b3JrIHJlbWFpbnMgYQ0NCiAgICAgY2hhbGxlbmdlIHNpbmNlIGJhc2Vk IG9uIGxvY2F0aW9uLCBhbmQgYWNjZXNzIG5ldHdvcmssIHRoZQ0NCiAgICAgdmVoaWNsZSBtaWdo dCBoYXZlIGRpZmZlcmVudCBjb25maWd1cmF0aW9ucyB0aGF0IG11c3QgYmUgb2J0YWluZWQNDQog ICAgIGZyb20gaXRzIG1hbmFnZW1lbnQgc3lzdGVtLiBPcGVyYXRpbmcgY29uZmlndXJhdGlvbiB1 cGRhdGVzLA0NCiAgICAgd2hpbGUgaW4gcmVtb3RlIG5ldHdvcmtzIGFsc28gbmVlZHMgdG8gYmUg Y29uc2lkZXJlZCBpbiB0aGUNDQogICAgIGRlc2lnbiBvZiBhIE5NUy7igJ0= --_005_4B92C175DBEC492BB4B1FEC68522D9A2jacobsuniversityde_ Content-Type: text/plain; name="use-cases-section-2.4.diff.txt" Content-Description: use-cases-section-2.4.diff.txt Content-Disposition: attachment; filename="use-cases-section-2.4.diff.txt"; size=2307; creation-date="Sat, 04 Jan 2014 02:28:02 GMT"; modification-date="Sat, 04 Jan 2014 02:28:02 GMT" Content-ID: <4FBDBADC0F59AB448D26F41A0BDBB379@jacobs.jacobs-university.de> Content-Transfer-Encoding: base64 Miw0YzIsMTENDQo8IHZlbnRpbGF0aW9uLCBhaXIgY29uZGl0aW9uaW5nLCBhcHBsaWFuY2VzLCBh bmQgZW50ZXJ0YWlubWVudCBkZXZpY2VzDQ0KPCB0byBpbXByb3ZlIGNvbnZlbmllbmNlLCBjb21m b3J0LCBlbmVyZ3kgZWZmaWNpZW5jeSwgYW5kIHNlY3VyaXR5LiAgSXQNDQo8IGNhbiBiZSBzZWVu IGFzIGEgcmVzaWRlbnRpYWwgZXh0ZW5zaW9uIG9mIGJ1aWxkaW5nIGF1dG9tYXRpb24uDQ0KLS0t DQ0KPiB2ZW50aWxhdGlvbiwgYWlyIGNvbmRpdGlvbmluZywgYXBwbGlhbmNlcywgZW50ZXJ0YWlu bWVudCBhbmQgaG9tZQ0NCj4gc2VjdXJpdHkgZGV2aWNlcyB0byBpbXByb3ZlIGNvbnZlbmllbmNl LCBjb21mb3J0LCBlbmVyZ3kgZWZmaWNpZW5jeSwNDQo+IGFuZCBzZWN1cml0eS4NDQo+IA0NCj4g SXQgY2FuIGJlIHNlZW4gYXMgYSByZXNpZGVudGlhbCBleHRlbnNpb24gb2YgYnVpbGRpbmcNDQo+ IGF1dG9tYXRpb24uIEhvd2V2ZXIsIGl0IGlzIGV4cGVjdGVkIHRoYXQgdW5saWtlIGEgYnVpbGRp bmcgYXV0b21hdGlvbg0NCj4gc3lzdGVtIHRoZSBpbmZyYXN0cnVjdXRyZSBpbiBhIGhvbWUgaXMg b3BlcmF0ZWQgaW4gYSBjb25zaWRlcmFibHkgbW9yZQ0NCj4gYWQtaG9jIG5hdHVyZSwgd2l0aCBu byBjZW50cmFsaXplZCBtYW5hZ2VtZW50IHN5c3RlbSBha2luIHRvIGENDQo+IEJ1aWxkaW5nIEF1 dG9tYXRpb24gU3lzdGVtIChCQVMpIGF2YWlsYWJsZSB0byBjb25jZW50cmF0ZSB2YXJpb3VzDQ0K PiBmdW5jdGlvbnMgdG9nZXRoZXIuDQ0KOCwxM2MxNSwyMg0NCjwgZWxlY3RyaWNpYW5zIGRlcGxv eWluZyBob21lIGF1dG9tYXRpb24gc29sdXRpb25zIG9yIGRvbmUgYnkgcmVzaWRlbnRzDQ0KPCBi eSB1c2luZyB0aGUgYXBwbGljYXRpb24gdXNlciBpbnRlcmZhY2UgdG8gY29uZmlndXJlIChwYXJ0 cyBvZikgdGhlDQ0KPCBob21lIGF1dG9tYXRpb24gc29sdXRpb24uICBTaW1pbGFybHksIGZhaWx1 cmVzIG1heSBiZSByZXBvcnRlZCB2aWENDQo8IHN1aXRhYmxlIGludGVyZmFjZXMgdG8gcmVzaWRl bnRzIG9yIHRoZXkgbWlnaHQgYmUgcmVjb3JkZWQgYW5kIG1hZGUNDQo8IGF2YWlsYWJsZSB0byBl bGVjdHJpY2lhbnMgaW4gY2hhcmdlIG9mIHRoZSBtYWludGVuYW5jZSBvZiB0aGUgaG9tZQ0NCjwg YXV0b21hdGlvbiBpbmZyYXN0cnVjdHVyZS4NDQotLS0NDQo+IGVsZWN0cmljaWFucyBkZXBsb3lp bmcgaG9tZSBhdXRvbWF0aW9uIHNvbHV0aW9ucywgdGhpcmQgcGFydHkgc2VydmljZQ0NCj4gcHJv dmlkZXJzIChJU1BzLCBzbWFsbCBvdXRzb3VyY2luZyBmaXJtcywgZGV2aWNlIG1hbnVmYWN0dXJl cnMsIG9ubGluZQ0NCj4gcG9ydGFscyBhbmQgZXRjLikgb3IgZG9uZSBieSByZXNpZGVudHMgYnkg dXNpbmcgdGhlIGFwcGxpY2F0aW9uIHVzZXINDQo+IGludGVyZmFjZSB0byBjb25maWd1cmUgKHBh cnRzIG9mKSB0aGUgaG9tZSBhdXRvbWF0aW9uDQ0KPiBzb2x1dGlvbi4gU2ltaWxhcmx5LCBmYWls dXJlcyBtYXkgYmUgcmVwb3J0ZWQgdmlhIHN1aXRhYmxlIGludGVyZmFjZXMNDQo+IHRvIHJlc2lk ZW50cyBvciB0aGV5IG1pZ2h0IGJlIHJlY29yZGVkIGFuZCBtYWRlIGF2YWlsYWJsZSB0byBzZXJ2 aWNlDQ0KPiBwcm92aWRlcnMgaW4gY2hhcmdlIG9mIHRoZSBtYWludGVuYW5jZSBvZiB0aGUgaG9t ZSBhdXRvbWF0aW9uDQ0KPiBpbmZyYXN0cnVjdHVyZS4NDQoxNiwxOGMyNSwzMA0NCjwgYmUgb3V0 c291cmNlZCB0byBlbGVjdHJpY2lhbnMgcHJvdmlkaW5nIG1hbmFnZW1lbnQgb2YgaG9tZSBhdXRv bWF0aW9uDQ0KPCBzb2x1dGlvbnMgYXMgYSBzZXJ2aWNlLiAgVGhlIHRpbWUgc2NhbGUgZm9yIGZh aWx1cmUgZGV0ZWN0aW9uIGFuZA0NCjwgcmVzb2x1dGlvbiBpcyBpbiBtYW55IGNhc2VzIGxpa2Vs eSBjb3VudGVkIGluIGhvdXJzIHRvIGRheXMuDQ0KLS0tDQ0KPiBiZSBvdXRzb3VyY2VkIHRvIGVs ZWN0cmljaWFucyBhbmQvb3IgdGhpcmQgcGFydGllcyBwcm92aWRpbmcNDQo+IG1hbmFnZW1lbnQg b2YgaG9tZSBhdXRvbWF0aW9uIHNvbHV0aW9ucyBhcyBhIHNlcnZpY2UuICBBIHZhcnlpbmcNDQo+ IGNvbWJpbmF0aW9uIG9mIGVsZWN0cmljaWFucywgc2VydmljZSBwcm92aWRlcnMgb3IgdGhlIHJl c2lkZW50cyBtYXkgYmUNDQo+IHJlc3BvbnNpYmxlIGZvciBkaWZmZXJlbnQgYXNwZWN0cyBvZiBt YW5hZ2luZyB0aGUgaW5mcmFzdHJ1Y3V0cmUuICBUaGUNDQo+IHRpbWUgc2NhbGUgZm9yIGZhaWx1 cmUgZGV0ZWN0aW9uIGFuZCByZXNvbHV0aW9uIGlzIGluIG1hbnkgY2FzZXMNDQo+IGxpa2VseSBj b3VudGVkIGluIGhvdXJzIHRvIGRheXMuDQ0K --_005_4B92C175DBEC492BB4B1FEC68522D9A2jacobsuniversityde_ Content-Type: text/plain; name="use-cases-section-2.3.diff.txt" Content-Description: use-cases-section-2.3.diff.txt Content-Disposition: attachment; filename="use-cases-section-2.3.diff.txt"; size=2244; creation-date="Sat, 04 Jan 2014 02:28:02 GMT"; modification-date="Sat, 04 Jan 2014 02:28:02 GMT" Content-ID: Content-Transfer-Encoding: base64 MSwxMGMxLDkNDQo8IEluZHVzdHJpYWwgQXBwbGljYXRpb25zIGFuZCBzbWFydCBtYW51ZmFjdHVy aW5nIHJlZmVyIG5vdCBvbmx5IHRvDQ0KPCBwcm9kdWN0aW9uIGVxdWlwbWVudCwgYnV0IGFsc28g dG8gYSBmYWN0b3J5IHRoYXQgY2FycmllcyBvdXQNDQo8IGNlbnRyYWxpemVkIGNvbnRyb2wgb2Yg ZW5lcmd5LCBIVkFDIChoZWF0aW5nLCB2ZW50aWxhdGlvbiwgYW5kIGFpcg0NCjwgY29uZGl0aW9u aW5nKSwgbGlnaHRpbmcsIGFjY2VzcyBjb250cm9sLCBldGMuIHZpYSBhIG5ldHdvcmsuICBGb3Ig dGhlDQ0KPCBtYW5hZ2VtZW50IG9mIGEgZmFjdG9yeSBpdCBpcyBiZWNvbWluZyBlc3NlbnRpYWwg dG8gaW1wbGVtZW50IHNtYXJ0DQ0KPCBjYXBhYmlsaXRpZXMuICBGcm9tIGFuIGVuZ2luZWVyaW5n IHN0YW5kcG9pbnQsIGluZHVzdHJpYWwgYXBwbGljYXRpb25zDQ0KPCBhcmUgaW50ZWxsaWdlbnQg c3lzdGVtcyBlbmFibGluZyByYXBpZCBtYW51ZmFjdHVyaW5nIG9mIG5ldyBwcm9kdWN0cywNDQo8 IGR5bmFtaWMgcmVzcG9uc2UgdG8gcHJvZHVjdCBkZW1hbmQsIGFuZCByZWFsLXRpbWUgb3B0aW1p emF0aW9uIG9mDQ0KPCBtYW51ZmFjdHVyaW5nIHByb2R1Y3Rpb24gYW5kIHN1cHBseSBjaGFpbiBu ZXR3b3Jrcy4gIFBvdGVudGlhbA0NCjwgaW5kdXN0cmlhbCBhcHBsaWNhdGlvbnMgZS5nLiBmb3Ig c21hcnQgZmFjdG9yaWVzIGFuZCBzbWFydA0NCi0tLQ0NCj4gSW5kdXN0cmlhbCBBcHBsaWNhdGlv bnMgYW5kIHNtYXJ0IG1hbnVmYWN0dXJpbmcgcmVmZXIgdG8gbmV0d29ya2VkDQ0KPiBjb250cm9s IGFuZCBtb25pdG9yaW5nIG9mIHRhc2tzIHN1Y2ggYXMgZXF1aXBtZW50IHJlbGF0ZWQgdG8NDQo+ IG1hbnVmYWN0dXJpbmcsIGFzc2V0IGFuZCBzaXR1YXRpb24gbWFuYWdlbWVudCBvciBwcm9jZXNz IGNvbnRyb2wuICBGb3INDQo+IHRoZSBtYW5hZ2VtZW50IG9mIGEgZmFjdG9yeSBpdCBpcyBiZWNv bWluZyBlc3NlbnRpYWwgdG8gaW1wbGVtZW50DQ0KPiBzbWFydCBjYXBhYmlsaXRpZXMuICBGcm9t IGFuIGVuZ2luZWVyaW5nIHN0YW5kcG9pbnQsIGluZHVzdHJpYWwNDQo+IGFwcGxpY2F0aW9ucyBh cmUgaW50ZWxsaWdlbnQgc3lzdGVtcyBlbmFibGluZyByYXBpZCBtYW51ZmFjdHVyaW5nIG9mDQ0K PiBuZXcgcHJvZHVjdHMsIGR5bmFtaWMgcmVzcG9uc2UgdG8gcHJvZHVjdCBkZW1hbmQsIGFuZCBy ZWFsLXRpbWUNDQo+IG9wdGltaXphdGlvbiBvZiBtYW51ZmFjdHVyaW5nIHByb2R1Y3Rpb24gYW5k IHN1cHBseSBjaGFpbiBuZXR3b3Jrcy4NDQo+IFBvdGVudGlhbCBpbmR1c3RyaWFsIGFwcGxpY2F0 aW9ucyBlLmcuIGZvciBzbWFydCBmYWN0b3JpZXMgYW5kIHNtYXJ0DQ0KMjBjMTkNDQo8IG8gIFNt YXJ0IHNlbnNvcnMgZGV0ZWN0aW5nIGFub21hbGllcyB0byBhdm9pZCBhYm5vcm1hbCBvcg0NCi0t LQ0NCj4gbyAgU21hcnQgc2Vuc29ycyBkZXRlY3RpbmcgYW5vbWFsaWVzIHRvIGF2b2lkIGFibm9y bWFsIG9yIA0NCjI0YzIzDQ0KPCAgICBzeXN0ZW0gYW5kIGV4dGVybmFsbHkgd2l0aCB0aGUgc21h cnQgZ3JpZCBlbmFibGluZyByZWFsLXRpbWUNDQotLS0NDQo+ICAgIHN5c3RlbSBhbmQgZXh0ZXJu YWxseSB3aXRoIHRoZSBzbWFydCBncmlkIGVuYWJsaW5nIHJlYWwtdGltZSANDQoyNmEyNiwzNQ0N Cj4gTWFuYWdlbWVudCBvZiBJbmR1c3RyaWFsIEFwcGxpY2F0aW9ucyBhbmQgc21hcnQgbWFudWZh Y3R1cmluZyBtYXkgaW4NDQo+IHNvbWUgc2l0dWF0aW9ucyBiZSBhY2hpZXZlZCBieSBpbnRlcmZh Y2luZyB3aXRoIGFuZCBjb21wbGV0aW5nDQ0KPiBCdWlsZGluZyBBdXRvbWF0aW9uIHRhc2tzIHN1 Y2ggYXMgY29udHJvbCBvZiBlbmVyZ3ksIEhWQUMgKGhlYXRpbmcsDQ0KPiB2ZW50aWxhdGlvbiwg YW5kIGFpciBjb25kaXRpb25pbmcpLCBsaWdodGluZywgYWNjZXNzIGNvbnRyb2wsIGFuZA0NCj4g ZXRjLiBJbnRlcmFjdGluZyB3aXRoIG1hbmFnZW1lbnQgc3lzdGVtcyBmcm9tIG90aGVyIGFwcGxp Y2F0aW9uIGFyZWFzDQ0KPiBtaWdodCBhbHNvIGJlIGltcG9ydGFudCBpbiBzb21lIGNhc2VzIChl LmcuIGVudmlyb25tZW50YWwgbW9uaXRvcmluZw0NCj4gZm9yIG51Y2xlYXIgZW5lcmd5IHByb2R1 Y3Rpb24sIGVuZXJneSBtYW5hZ2VtZW50IGZvciBkeW5hbWljYWxseQ0NCj4gc2NhbGluZyBtYW51 ZmFjdHVyaW5nLCB2ZWhpY3VsYXIgbmV0d29ya3MgZm9yIG1vYmlsZSBhc3NldCB0cmFja2luZw0N Cj4gYW5kIGV0Yy4pLg0NCj4gDQ0K --_005_4B92C175DBEC492BB4B1FEC68522D9A2jacobsuniversityde_ Content-Type: text/plain; name="draft-ersue-opsawg-coman-probstate-reqs-00.txt" Content-Description: draft-ersue-opsawg-coman-probstate-reqs-00.txt Content-Disposition: attachment; filename="draft-ersue-opsawg-coman-probstate-reqs-00.txt"; size=2834; creation-date="Sat, 04 Jan 2014 02:28:02 GMT"; modification-date="Sat, 04 Jan 2014 02:28:02 GMT" Content-ID: Content-Transfer-Encoding: base64 MS4zIE5ldHdvcmsgVHlwZXMgYW5kIENoYXJhY3RlcmlzdGljcyBpbiBGb2N1cw0NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NDQoNDQooYSkgIk1vYmlsZSBB ZGhvYyBuZXR3b3JrcyAoTUFORVQpIGFyZSBzZWxmLWNvbmZpZ3VyaW5nDQ0KICAgIF9pbmZyYXN0 cnVjdHVyZWxlc3NfIG5ldHdvcmtzIG9mIG1vYmlsZSBkZXZpY2VzIGNvbm5lY3RlZCBieQ0NCiAg ICB3aXJlbGVzcyB0ZWNobm9sb2dpZXMuIg0NCg0NCiAgICAtLT4gV2h5IGlzIGEgZGlmZmVyZW50 aWF0aW9uIGJlaW5nIG1hZGUgYmV0d2VlbiBNQU5FVHMgYW5kIG90aGVyDQ0KICAgICAgICB0eXBl cyBvZiB3aXJlbGVzcyBuZXR3b3Jrcz8gQ291bGRuJ3QgbW9ibGllIHBob25lcyB0ZWNobmljYWxs eQ0NCiAgICAgICAgZml0IGludG8gdGhlIElvVCBhcyB3ZWxsPyBJcyB0aGUgZGlmZmVyZW50aWF0 aW9uIG9ubHkgbWFkZQ0NCiAgICAgICAgYmFzZWQgb24gdGhlIF9pbmZyYXN0cnVjdHVyZWxlc3Nf IHBhcnQgb2YgaXQ/IElmIHNvLCBkb2VzIGl0DQ0KICAgICAgICBtYWtlIHNlbnNlIHRvIGhhdmUg Y2F0ZWdvcmllcyBvZiBpbmZyYXN0cnVjdHVyZSBhbmQNDQogICAgICAgIGluZnJhc3RydWN0dXJl bGVzcywgcmF0aGVyIHRoYW4gTUFORVQgYW5kIG5vbi1NQU5FVCBuZXR3b3Jrcz8NDQogICAgDQ0K KGIpICJXaXJlbGluZSBub24tY29uc3RyYWluZWQgbmV0d29ya3MgYXJlIG1haW5seSB1c2VkIGZv ciBzcGVjaWZpYw0NCiAgICBhcHBsaWNhdGlvbnMgbGlrZSBCdWlsZGluZyBBdXRvbWF0aW9uIG9y IEluZnJhc3RydWN0dXJlDQ0KICAgIE1vbml0b3JpbmcuICBIb3dldmVyLCB3aXJlbGluZSBhbmQg d2lyZWxlc3MgbmV0d29ya3Mgd2l0aA0NCiAgICBtdWx0aS1ob3Agb3IgcG9pbnQtdG8tIG11bHRp cG9pbnQgY29ubmVjdGl2aXR5IGFyZSBlc3BlY2lhbGx5IGluDQ0KICAgIHRoZSBpbnRlcmVzdCBv ZiB0aGUgYW5hbHlzaXMgb24gdGhlIG1hbmFnZW1lbnQgb2YgY29uc3RyYWluZWQNDQogICAgZGV2 aWNlcyBpbiB0aGlzIGRvY3VtZW50LiINDQoNDQogICAgLS0+IFRoaXMgcGFyYWdyYXBoIGlzIHVu Y2xlYXIuIFdoYXQgaXMgaXQgdHJ5aW5nIHRvIGNvbnZleT8gSXMgaXQNDQogICAgICAgIHNheWlu ZyB0aGF0IG9ubHkgd2lyZWxpbmUgbXVsdGktaG9wIGFuZCBwb2ludC10by1tdWx0aXBvaW50DQ0K ICAgICAgICBhcmUgd2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50PyBXaHkgbm90IHJl Z3VsYXINDQogICAgICAgIHdpcmVsaW5lIG5ldHdvcmtzIHRoYXQgbWF5IGhhdmUgY29uc3RyYWlu ZWQgZGV2aWNlcyBhcyBwYXJ0IG9mDQ0KICAgICAgICBhIG5vbi1jb25zdHJhaW5lZCBuZXR3b3Jr Pw0NCiAgICANDQogICAgLS0+IFRoZXJlIGlzIHRhbGsgYWJvdXQgYmFuZHdpZHRoLCBidXQgbm90 IGZyYW1lIHNpemUsIHdoaWNoIGlzDQ0KICAgICAgICBsaWtlbHkgdG8gaGF2ZSBhIGJpZ2dlciBp bXBhY3QgdGhhbiB0aGUgb3ZlcmFsbCBiYW5kd2lkdGgNDQogICAgICAgIGF2YWlsYWJsZSBpbiBh IGNoYW5uZWwuIE1heWJlIHRoaXMgc2hvdWxkIGJlIG1lbnRpb25lZD8NDQoNDQoNDQoxLjYuICBN YW5hZ2luZyB0aGUgQ29uc3RyYWluZWRuZXNzIG9mIGEgRGV2aWNlIG9yIE5ldHdvcmsNDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NDQoN DQooYSkgIm1pZ2h0IG9ubHkgYmUgYWJsZSB0byBzdXBwb3J0IG9uZSBzaW1wbGUgY29tbXVuaWNh dGlvbiBwcm90b2NvbCwNDQogICAgaS5lLiB0aGUgbWFuYWdlbWVudCBwcm90b2NvbCBuZWVkcyB0 byBiZSBwb3NzaWJsZSB0byBkb3duc2NhbGUNDQogICAgZnJvbSBjb25zdHJhaW5lZCAoQzIpIHRv IHZlcnkgY29uc3RyYWluZWQgKEMwKSBkZXZpY2VzIg0NCg0NCiAgICAtLT4gSXMgaXQgaW1wb3J0 YW50IHRoYXQgdGhlIHNhbWUgbWFuYWdlbWVudCBwcm90b2NvbCBiZQ0NCiAgICAgICAgYXBwbGlj YWJsZSB0byB0aGUgZW50aXJlIHJhbmdlIG9mIGNvbnN0cmFpbmVkIGRldmljZXM/IFdoeSBub3QN DQogICAgICAgIGFsbG93IHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIG1hbmFnZW1lbnQgcHJvdG9j b2wgdG8gc2NhbGUgdXANDQogICAgICAgIGFuZCBkb3duIHdpdGggdGhlIHR5cGUvY2FwYWJpbGl0 aWVzIG9mIHRoZSBkZXZpY2UgYXQgaGFuZD8NDQoNDQoJU09MVVRJT046IEEgbmV3IGJ1bGxldCBw b2ludCBzdGF0aW5nIHRoYXQgZGlmZmVyZW50IG1hbmFnZW1lbnQNDQoJcHJvdG9jb2xzIHdvcmsg b24gZGlmZmVyZW50IGNsYXNzIG9mIGRldmljZXMuDQ0KDQ0KKGIpICJtaWdodCBvbmx5IGJlIGFi bGUgdG8gc3VwcG9ydCBsaW1pdGVkIG9yIG5vIHVzZXIgYW5kL29yIHRyYW5zcG9ydA0NCiAgICBz ZWN1cml0eSIgQU5EICJtaWdodCBvbmx5IGJlIGFibGUgdG8gc3VwcG9ydCB2ZXJ5IHNpbXBsZQ0N CiAgICBlbmNyeXB0aW9uIg0NCg0NCiAgICAtLT4gU2ltcGxlIGVuY3J5cHRpb24gZG9lc24ndCBt YWtlIHNlbnNlLCBtYXliZSBpdCBzaG91bGQgYmUNDQogICAgICAgIGVmZmljaWVudCBlbmNyeXB0 aW9uIGluc3RlYWQ/DQ0KDQ0KKGMpICJtaWdodCBhbHNvIG5lZWQgZW5lcmd5LWVmZmljaWVudCBr ZXkgbWFuYWdlbWVudCBhbGdvcml0aG1zIGZvcg0NCiAgICBzZWN1cml0eS4iDQ0KDQ0KICAgIC0t PiBOb3QganVzdCBlbmVyZ3ktZWZmaWNpZW50LCBidXQgYWxzbyBtZW1vcnksIHByb2Nlc3Npbmcg YW5kDQ0KICAgICAgICBldGMuIGVmZmljaWVudC4gTm8/DQ0KDQ0KCVNPTFVUSU9OOiBDaGFuZ2Ug dGV4dCB0byBvbmx5IGVmZmljaWVudCBrZXkgbWFuYWdlbWVudC4NDQo= --_005_4B92C175DBEC492BB4B1FEC68522D9A2jacobsuniversityde_-- From mehmet.ersue@nsn.com Sat Jan 4 04:06:42 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC871ADF44 for ; Sat, 4 Jan 2014 04:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk3-Whk0vSxA for ; Sat, 4 Jan 2014 04:06:40 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2D53D1ADF43 for ; Sat, 4 Jan 2014 04:06:39 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s04C6Ta9006058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 4 Jan 2014 13:06:29 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s04C6SG9015041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Jan 2014 13:06:29 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 4 Jan 2014 13:06:28 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Sat, 4 Jan 2014 13:06:28 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert Wijnen (IETF)" , "opsawg >> \"opsawg@ietf.org\"" Thread-Topic: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* Thread-Index: AQHPB5hTXASYx/AkA0mvvcW3JIGoM5py+qUAgAA/XQCAAUDzAA== Date: Sat, 4 Jan 2014 12:06:27 +0000 Message-ID: References: <52C32AF3.3040103@bwijnen.net> <52C52968.7050404@bwijnen.net> <52C6F98E.5050805@bwijnen.net> In-Reply-To: <52C6F98E.5050805@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 1273 X-purgate-ID: 151667::1388837189-00001A6F-3C6663A3/0-0/0-0 Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 12:06:42 -0000 ...=20 > > I wonder how you define the "minimal modular-function-set". Isn't this = already a > decision? > > The draft avoids defining function sets to be used. I assume different = vendors will > provide > > different monolithic devices. >=20 > There is two things that (in my view are/can be modular: > - the implementation > - the specification >=20 > EVen if the specification is "modular", even then someone can chose to > implement it as a monolythic program/process I would think. And often tha= t can > save memory usage. Agree. =20 ...=20 > >> - for requirement 4.9.003 > >> is that more or less an "implementation" suggestion for requiremen= t 4.9.001 ?? > > > > You are right. It could be seen as such. > > However, there might be different reasons why people would want to redu= ce the > amount of traffic in the network. > > Congestion is one of them. One can also begin acting before congestion = happens. > WDYT? > > > OK, maybe add a line of text about that then. IN my view it looked like b= asically twice > the > same requirement. But if you define it this way, then it can be seen as a= different > requirement > may be. I think the requirements can be justified. Will add text.=20 Cheers, Mehmet From zehn.cao@gmail.com Sun Jan 5 23:39:31 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56F91ADFB7 for ; Sun, 5 Jan 2014 23:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q26tgK8Y5a5h for ; Sun, 5 Jan 2014 23:39:29 -0800 (PST) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 57A321ADFC8 for ; Sun, 5 Jan 2014 23:39:29 -0800 (PST) Received: by mail-qe0-f52.google.com with SMTP id ne12so18138256qeb.39 for ; Sun, 05 Jan 2014 23:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MhcJ7iHrlOJdBrL6pV1xmTL1QiQ84RW4w5dy1oXvtb0=; b=aWQ2h7JDW4kfboxZTtD5cEjdlCxIRvIC23V4d+vIlx4t8etLOMQwELJEygR74cKfFl +wLbo5xoytofS64cmNQGaNQ+WD8xPgO5fJc4dY+2o0maHeryWU1oCA30E+bRRsFItc11 rfsEe2Dl7yq47JsJbkbmy2XUDBSTo0JBLkrMosuz8dazAg0VOgAHPNhGQkCk6HeBYOZp D+FWFdWKhQC+Tfj4MxJu7J6B+liyfHjfS2PRwjIKguS3Kiy/xbmVXstrAjImumuXzwC1 x8jD2oQjepzmYtfWtyj1BOiYiP2aN32HFJZGsldxGZ/mfA0fb4NtxfjFGaXftOq7+0Tc ZqqQ== MIME-Version: 1.0 X-Received: by 10.224.161.75 with SMTP id q11mr97370253qax.69.1388993960899; Sun, 05 Jan 2014 23:39:20 -0800 (PST) Received: by 10.96.58.101 with HTTP; Sun, 5 Jan 2014 23:39:20 -0800 (PST) In-Reply-To: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> References: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> Date: Mon, 6 Jan 2014 15:39:20 +0800 Message-ID: From: "Cao,Zhen" To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 07:39:32 -0000 Dear authors and all, I read through the two drafts, and believe the two documents are useful for operators and SPs that manage a constrained device network. Thank you for the work. a) http://tools.ietf.org/html/draft-ersue-opsawg-coman-use-cases-00 This draft is pretty sufficient at the time of writing. But i do not know how to act for new use cases coming up. For example, vehicle communication networks. There are many use case documents in IETF, but how sufficient they should be. I believe the issue will be raised up during IESG review. b) http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs/ This document is also pretty sufficient. The requirement template is very good practice. One cent to the document is, shall we consider the management of sleepy nodes in section 3? There are many discussions in coap/lwig for these sleepy nodes. The management of these devices is rather challenging. Although there are some discussion in 'Energy management', the scope of sleepy nodes management should be broader than that. Best regards, caozhen@chinamobile On Thu, Dec 5, 2013 at 12:49 AM, Warren Kumari wrote: > Hi all, > > Hopefully you all had a good Thanksgiving -- if you are in the US, hopefully you had good turkey, stuffing / whatever. > If you are not US based, hopefully you enjoyed the decrease in email volume while everyone recovered form eating too much. :-) > > One of the action items from Vancouver was for us to call for reviewers for: > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs/ > and > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-use-cases/ > > So, can we get some volunteers please? According to our new guidelines we require sufficient reviewers before adopting new work. > > The documents are (IMO) interesting and easy to read. Constrained devices have some interesting requirements and limitations. > If you would like a quick reminder / refresher from the meeting, slides are here: http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pdf > > Juergen Schoenwaelder indicated that one of his Ph.D. students had read the draft a couple of weeks ago. So they just have to review the changes to the latest version. > > > W > -- > "I think it would be a good idea." > - Mahatma Ghandi, when asked what he thought of Western civilization > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From denghui02@gmail.com Sun Jan 5 23:48:47 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B760A1AC4C1 for ; Sun, 5 Jan 2014 23:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb1E-5obgnro for ; Sun, 5 Jan 2014 23:48:42 -0800 (PST) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9431AC4AB for ; Sun, 5 Jan 2014 23:48:42 -0800 (PST) Received: by mail-qe0-f42.google.com with SMTP id b4so18074063qen.15 for ; Sun, 05 Jan 2014 23:48:34 -0800 (PST) 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=xah1t3ieP1KZDLIMOGBgSCFwnNfowsZFtL/LqQ7IZ/s=; b=iaisnjCkRO/Q4s04brf1BoN/LTSgi7XIYKyEiynoxJl17JxaGsCsYuT5KzGbidNwlq QOXvqIWbXTgHN8p98erY/fLqdwhbC1XE+c0EpaUSv44md17ixp7NMwA1X6K4USzEVNww 6382YDbkquUUfggFFYk1S5hpSU8Opd8D70ux+C++YWSENrUdHWtycYMjzrGFGslbGQrd ccE23V2nJYdYW7dAkEEB0aqGquf/HEsuJRdd7q4sUX31Z/0hKBj5tOst3bx5rDl5EziI g0PLWdEnUciIrtSutPvpxAlFoHXCVXPyPg8HU9DPMu/sMeyCZmQG2vkeZ9fkFwkYliZK 8bEQ== MIME-Version: 1.0 X-Received: by 10.224.46.196 with SMTP id k4mr39906312qaf.43.1388994514166; Sun, 05 Jan 2014 23:48:34 -0800 (PST) Received: by 10.96.194.197 with HTTP; Sun, 5 Jan 2014 23:48:34 -0800 (PST) Date: Mon, 6 Jan 2014 15:48:34 +0800 Message-ID: From: Hui Deng To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1f1509ca7ae04ef487cf1 Subject: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 07:48:47 -0000 --001a11c1f1509ca7ae04ef487cf1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Authors, This document is very useful for service providers and operators that are managing their constrained devices. Two cents for authors to consider, 1. in section 3., a section of =91IPv4/v6 address management=92 could be helpful, including the discussion of different types of ip addresses on devices, link-local, global, private, etc.. 2. in Appendix A, any relevant discussion in =91oneM2M=92? Regards, -Hui 2014/1/4 Ersue, Mehmet (NSN - DE/Munich) > Hi Dan, > > thank you for your review and comments. See below. > > Cheers, > Mehmet > > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of ext > Romascanu, Dan > > (Dan) > > Sent: Thursday, December 12, 2013 2:23 PM > > To: Warren Kumari; opsawg@ietf.org > > Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* > > > > Hi, > > > > I do not know if I really should be included in the reviewers count, as > I am a participant > > in the coman work since it started, and my name shows up on the list of > authors, > > although in all sincerity most of the credits go to Mehmet, who hold th= e > pen for most > > of the time, including this latest wound which split the original > document into two > > separate documents - one for use cases, the other for problem statement > and > > requirements. Anyway, FWIW I obviously believe this work is useful and = I > support > > doing it in the OPSAWG. I have a few comments recorded below: > > > > draft-ersue-opsawg-coman-use-cases > > > > 1. I do not believe that we can get away with a zero-content security > considerations > > section. The described use cases mention the need to secure information > collected by > > constrained devices, some other (like security cameras) carry > information related to > > personal or public security that needs to be protected by robust > mechanisms. These > > kind of threats need to be mentioned IMO. > > You are right a dummy security considerations section is not sufficient. > Coman was not planning to address security exhaustively. Solace, now ACE, > has > been started where security for constrained devices will be discussed. > We discussed the security requirements in section 3.6 of the problem > statement draft. > > I agree, a discussion of the security threads should be provided in a > security considerations section. > > > draft-ersue-opsawg-coman-probstate-reqs > > > > 1. The draft uses the 'adjective' small device in association with > constrained device in a > > few place. I suggest to remove this. There is no automatic association > of a device > > being small implying that it is also constrained. Nor are all > constrained devices small in > > size. > > Agree. We should be more precise with the terminology. > > > 2. We have made an effort in the last few versions and especially in > this one to > > distinguish between the constrained devices and constrained networks, > but the clean-up > > on this issue is not complete. For example section 1.6 still has text > about constrained > > networks - this section and other in which constrained networks are > mentioned should > > be carefully examined to make sure that the focus of the document stays > with > > constrained devices, and that if constrained networks are mentioned at > all this is in the > > context of their relationship with the constrained devices. > > Why strictly devices? We also have requirements discussing the > organization of constrained networks from management pov. in section 3.1. > > > 3. I do not believe that we can get away with a zero-content security > considerations > > section here either. The document even says: > > > > If specific requirements for > > security will be identified, they will be described in future > > versions of this document. > > > > This is not accurate - section 3.6 already speaks about requirments for > security and > > access control, and section 1.6 mentions limitations that would prevent > the > > implementation of strong scryptographic algorythms. The text needs to b= e > reviewed > > and revised from this perspective. > > I think the "future" is now and the current text in the security > considerations section needs to be replaced. I would suggest to provide a > security considerations section by listing and discussing threads in the > problem statement draft and refer to it from the use cases draft. > Comments? > > > > > Regards, > > > > Dan > > > > > -----Original Message----- > > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren > Kumari > > > Sent: Wednesday, December 04, 2013 6:49 PM > > > To: opsawg@ietf.org > > > Subject: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* > > > > > > Hi all, > > > > > > Hopefully you all had a good Thanksgiving -- if you are in the US, > > > hopefully you had good turkey, stuffing / whatever. > > > If you are not US based, hopefully you enjoyed the decrease in email > > > volume while everyone recovered form eating too much. :-) > > > > > > One of the action items from Vancouver was for us to call for reviewe= rs > > > for: > > > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs/ > > > and > > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-use-cases/ > > > > > > So, can we get some volunteers please? According to our new guideline= s > > > we require sufficient reviewers before adopting new work. > > > > > > The documents are (IMO) interesting and easy to read. Constrained > > > devices have some interesting requirements and limitations. > > > If you would like a quick reminder / refresher from the meeting, slid= es > > > are here: > http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pdf > > > > > > Juergen Schoenwaelder indicate= d > > > that one of his Ph.D. students had read the draft a couple of weeks > ago. > > > So they just have to review the changes to the latest version. > > > > > > > > > W > > > -- > > > "I think it would be a good idea." > > > - Mahatma Ghandi, when asked what he thought of Western civilization > > > > > > > > > > > > _______________________________________________ > > > OPSAWG mailing list > > > OPSAWG@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a11c1f1509ca7ae04ef487cf1 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Authors,
 

This document is very useful for service pro= viders and operators that are managing their constrained devices.

 

Two cents for authors to consider,

1. in section 3., a section of ‘IPv4/v= 6 address management’ could be helpful, including the discussion of different types of ip address= es on devices, link-local, global, private, etc..

2. in Appendix A, any relevant discussion in= ‘oneM2M’?


Regards,
 
-Hui

 
2014/1/4 Ersue, Mehme= t (NSN - DE/Munich) <mehmet.ersue@nsn.com>
Hi Dan,

thank you for your review and comments. See below.

Cheers,
Mehmet

> -----Original Message-----
> From: OPSAWG [mailto:opsawg= -bounces@ietf.org] On Behalf Of ext Romascanu, Dan
> (Dan)
> Sent: Thursday, December 12, 2013 2:23 PM
> To: Warren Kumari; opsawg@ietf.org<= /a>
> Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*=
>
> Hi,
>
> I do not know if I really should be included in the reviewers count, a= s I am a participant
> in the coman work since it started, and my name shows up on the list o= f authors,
> although in all sincerity most of the credits go to Mehmet, who hold t= he pen for most
> of the time, including this latest wound which split the original docu= ment into two
> separate documents - one for use cases, the other for problem statemen= t and
> requirements. Anyway, FWIW I obviously believe this work is useful and= I support
> doing it in the OPSAWG. I have a few comments recorded below:
>
>  draft-ersue-opsawg-coman-use-cases
>
> 1. I do not believe that we can get away with a zero-content security = considerations
> section. The described use cases mention the need to secure informatio= n collected by
> constrained devices, some other (like security cameras) carry informat= ion related to
> personal or public security that needs to be protected by robust mecha= nisms. These
> kind of threats need to be mentioned IMO.

You are right a dummy security considerations section is not sufficient. Coman was not planning to address security exhaustively. Solace, now ACE, h= as
been started where security for constrained devices will be discussed.
We discussed the security requirements in section 3.6 of the problem statem= ent draft.

I agree, a discussion of the security threads should be provided in a secur= ity considerations section.

> draft-ersue-opsawg-coman-probstate-reqs
>
> 1. The draft uses the 'adjective' small device in association = with constrained device in a
> few place. I suggest to remove this. There is no automatic association= of a device
> being small implying that it is also constrained. Nor are all constrai= ned devices small in
> size.

Agree. We should be more precise with the terminology.

> 2. We have made an effort in the last few versions and especially in t= his one to
> distinguish between the constrained devices and constrained networks, = but the clean-up
> on this issue is not complete. For example section 1.6 still has text = about constrained
> networks - this section and other in which constrained networks are me= ntioned should
> be carefully examined to make sure that the focus of the document stay= s with
> constrained devices, and that if constrained networks are mentioned at= all this is in the
> context of their relationship with the constrained devices.

Why strictly devices? We also have requirements discussing the organization= of constrained networks from management pov. in section 3.1.

> 3. I do not believe that we can get away with a zero-content security = considerations
> section here either. The document even says:
>
>    If specific requirements for
>    security will be identified, they will be described in fu= ture
>    versions of this document.
>
> This is not accurate - section 3.6 already speaks about requirments fo= r security and
> access control, and section 1.6 mentions limitations that would preven= t the
> implementation of strong scryptographic algorythms. The text needs to = be reviewed
> and revised from this perspective.

I think the "future" is now and the current text in the security = considerations section needs to be replaced. I would suggest to provide a s= ecurity considerations section by listing and discussing threads in the pro= blem statement draft and refer to it from the use cases draft.
Comments?

>
> Regards,
>
> Dan
>
> > -----Original Message-----
> > From: OPSAWG [mailto:o= psawg-bounces@ietf.org] On Behalf Of Warren Kumari
> > Sent: Wednesday, December 04, 2013 6:49 PM
> > To: opsawg@ietf.org
> > Subject: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-= *
> >
> > Hi all,
> >
> > Hopefully you all had a good Thanksgiving -- if you are in the US= ,
> > hopefully you had good turkey, stuffing / whatever.
> > If you are not US based, hopefully you enjoyed the decrease in em= ail
> > volume while everyone recovered form eating too much. :-)
> >
> > One of the action items from Vancouver was for us to call for rev= iewers
> > for:
> > http://datatracker.ietf.org/doc/draft= -ersue-opsawg-coman-probstate-reqs/
> > and
> > http://datatracker.ietf.org/doc/draft-ersu= e-opsawg-coman-use-cases/
> >
> > So, can we get some volunteers please? According to our new guide= lines
> > we require sufficient reviewers before adopting new work.
> >
> > The documents are (IMO) interesting and easy to read. Constrained=
> > devices have some interesting requirements and limitations.
> > If you would like a quick reminder / refresher from the meeting, = slides
> > are here: http://tools.ietf.org/agenda/88/slide= s/slides-88-opsawg-11.pdf
> >
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> indicated
> > that one of his Ph.D. students had read the draft a couple of wee= ks ago.
> > So they just have to review the changes to the latest version. > >
> >
> > W
> > --
> > "I think it would be a good idea."
> > - Mahatma Ghandi, when asked what he thought of Western civilizat= ion
> >
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--001a11c1f1509ca7ae04ef487cf1-- From dromasca@avaya.com Mon Jan 6 03:04:34 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F4B1ADF8B for ; Mon, 6 Jan 2014 03:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLaJuuFoBeID for ; Mon, 6 Jan 2014 03:04:33 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id CF5E71ADF63 for ; Mon, 6 Jan 2014 03:04:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOSMylLGmAcV/2dsb2JhbABYgmohgQ25SIEQFnSCJQEBAQEDEgsdOBMEAgEIDQgNFAkHMhQRAgQBEggah2IBn2ekBReOXjiDJIETBJ8DiymDLYIq X-IronPort-AV: E=Sophos;i="4.95,612,1384318800"; d="scan'208";a="37939847" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Jan 2014 06:04:23 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 06 Jan 2014 05:55:13 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 06:04:20 -0500 From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , Warren Kumari , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* Thread-Index: AQHO8RDEIGF0yyADI0m6OYWIUKl8cJpQjfnQgCLichCABEqxkA== Date: Mon, 6 Jan 2014 11:04:20 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129FD648@AZ-FFEXMB04.global.avaya.com> References: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> <9904FB1B0159DA42B0B887B7FA8119CA129E249A@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 11:04:34 -0000 Hi Mehmet, One short reply on one of your answers:=20 > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com] >=20 > > 2. We have made an effort in the last few versions and especially in > > this one to distinguish between the constrained devices and > > constrained networks, but the clean-up on this issue is not complete. > > For example section 1.6 still has text about constrained networks - > > this section and other in which constrained networks are mentioned > > should be carefully examined to make sure that the focus of the > > document stays with constrained devices, and that if constrained > networks are mentioned at all this is in the context of their > relationship with the constrained devices. >=20 > Why strictly devices? We also have requirements discussing the > organization of constrained networks from management pov. in section > 3.1. [[DR]] hmmm ... the titles of both documents in review start by 'Management= of Networks with Constrained Devices'. Is it rather 'Management of Constra= ined Networks and Networks with Constrained Devices'?=20 Dan From j.schoenwaelder@jacobs-university.de Mon Jan 6 03:20:03 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B27F1AE00D for ; Mon, 6 Jan 2014 03:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvxLfjJNIhk2 for ; Mon, 6 Jan 2014 03:20:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCC41ADFFB for ; Mon, 6 Jan 2014 03:20:01 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72EA22004C; Mon, 6 Jan 2014 12:19:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N9s9jlju_yen; Mon, 6 Jan 2014 12:19:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 760602004B; Mon, 6 Jan 2014 12:19:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 78E1A2A78B9A; Mon, 6 Jan 2014 12:19:47 +0100 (CET) Date: Mon, 6 Jan 2014 12:19:46 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20140106111946.GA36246@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Ersue, Mehmet (NSN - DE/Munich)" , Warren Kumari , "opsawg@ietf.org" References: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> <9904FB1B0159DA42B0B887B7FA8119CA129E249A@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA129FD648@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129FD648@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 11:20:03 -0000 On Mon, Jan 06, 2014 at 11:04:20AM +0000, Romascanu, Dan (Dan) wrote: > > [[DR]] hmmm ... the titles of both documents in review start by 'Management of Networks with Constrained Devices'. Is it rather 'Management of Constrained Networks and Networks with Constrained Devices'? > Including management of constrained networks expands the scope considerably. In the past, we preferred to keep the scope narrow, hence the current title. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Mon Jan 6 03:22:07 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8501AE016 for ; Mon, 6 Jan 2014 03:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIlB1PnLW75D for ; Mon, 6 Jan 2014 03:22:03 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4E41ADFFB for ; Mon, 6 Jan 2014 03:22:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgJAH6QylKHCzI1/2dsb2JhbABVA4JqIThVpRiUL4EQFnSCJQEBAQEDEgsdPwwCAgIBCA0BAgEEAQEBChQJBxsXFAkIAgQOBQgah2IBn2mkARcEjlohEAcGC4MTgRMEmUeFPIspgy2CKg X-IronPort-AV: E=Sophos;i="4.95,612,1384318800"; d="scan'208";a="43955910" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Jan 2014 06:21:54 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 06 Jan 2014 06:10:19 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 12:21:52 +0100 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* Thread-Index: AQHO8RDEIGF0yyADI0m6OYWIUKl8cJpQjfnQgCLichCABEqxkP//9GcAgAAQ7KA= Date: Mon, 6 Jan 2014 11:21:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129FD6A1@AZ-FFEXMB04.global.avaya.com> References: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> <9904FB1B0159DA42B0B887B7FA8119CA129E249A@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA129FD648@AZ-FFEXMB04.global.avaya.com> <20140106111946.GA36246@elstar.local> In-Reply-To: <20140106111946.GA36246@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 11:22:07 -0000 Hi, That was my recollection as well. However - see the part of the discussion = that you left out - there are still sections that deal with constrained net= works in text Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, January 06, 2014 1:20 PM > To: Romascanu, Dan (Dan) > Cc: Ersue, Mehmet (NSN - DE/Munich); Warren Kumari; opsawg@ietf.org > Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* >=20 > On Mon, Jan 06, 2014 at 11:04:20AM +0000, Romascanu, Dan (Dan) wrote: > > > > [[DR]] hmmm ... the titles of both documents in review start by > 'Management of Networks with Constrained Devices'. Is it rather > 'Management of Constrained Networks and Networks with Constrained > Devices'? > > >=20 > Including management of constrained networks expands the scope > considerably. In the past, we preferred to keep the scope narrow, hence > the current title. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Jan 6 03:35:22 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E73D1ADFFE for ; Mon, 6 Jan 2014 03:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B05f0WhmwkZi for ; Mon, 6 Jan 2014 03:35:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B12C21ADF93 for ; Mon, 6 Jan 2014 03:35:20 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26AA52004D; Mon, 6 Jan 2014 12:35:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7a7pSVczYysB; Mon, 6 Jan 2014 12:35:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E9712004C; Mon, 6 Jan 2014 12:35:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D63AE2A78CEA; Mon, 6 Jan 2014 12:34:52 +0100 (CET) Date: Mon, 6 Jan 2014 12:34:52 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20140106113452.GD36246@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Ersue, Mehmet (NSN - DE/Munich)" , Warren Kumari , "opsawg@ietf.org" References: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> <9904FB1B0159DA42B0B887B7FA8119CA129E249A@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA129FD648@AZ-FFEXMB04.global.avaya.com> <20140106111946.GA36246@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA129FD6A1@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129FD6A1@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 11:35:22 -0000 On Mon, Jan 06, 2014 at 11:21:51AM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > That was my recollection as well. However - see the part of the discussion that you left out - there are still sections that deal with constrained networks in text > Then either the text needs to go or some of it needs to stay because sometimes (in some application scenarios) constrained nodes to exist on constrained networks. In other words, it needs to be looked at on a case-by-case basis. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Mon Jan 6 06:27:51 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE751ADFFD for ; Mon, 6 Jan 2014 06:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ-VO-vlljLk for ; Mon, 6 Jan 2014 06:27:49 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id E65FA1ADFDB for ; Mon, 6 Jan 2014 06:27:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0HAO68ylLGmAcV/2dsb2JhbABYDoJcIThVpR+TWU+BChZ0giUBAQEBAwEBAQ8oNBcEAgEIDQQEAQELFAkHJwsUCQgCBAESCBqHYgEMnxmkBheOXjgGgx6BEwSZR4U8iymCbj+CKg X-IronPort-AV: E=Sophos;i="4.95,613,1384318800"; d="scan'208";a="43780615" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Jan 2014 09:27:39 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 06 Jan 2014 09:18:29 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 15:27:38 +0100 From: "Romascanu, Dan (Dan)" To: "Bradner, Scott" , "opsawg@ietf.org" Thread-Topic: draft-ietf-opsawg-oam-overview WGLC (again) Thread-Index: AQHO+12eeYMubdkUsUOIKskNjdAp7Jp32oKw Date: Mon, 6 Jan 2014 14:27:37 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129FDC22@AZ-FFEXMB04.global.avaya.com> References: <84657F87-5FC1-43BF-8D63-4367D827A84B@harvard.edu> In-Reply-To: <84657F87-5FC1-43BF-8D63-4367D827A84B@harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] draft-ietf-opsawg-oam-overview WGLC (again) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 14:27:51 -0000 Hi, I reviewed draft-ietf-opsawg-oam-overview-11. I find the content and the st= ructure of the document to be well improved in the last couple of versions.= I believe that it is ready for re-submission to the IESG. The comments bel= ow can further improve the document but none of them is really blocking:=20 1. In the process of re-organizing the document the references have been mi= xed up. Runing id-nits immediately flags some of the problems - for example= that [RFC6291] is used but not defined. It actually hides as [OAM-Def]. Th= e authors used 'descriptive' acronyms for references to IETF documents, but= pointed to non-IETF documents according to their names (e.g. [ITU-T-Y1711]= . This looks inconsistent, not big deal, but at least idnits should run cle= an. 2. I suggest to include a short section about the non-IETF work on OAM some= place in the introduction, for example as Section 1.5. Within the document= there are references to IEEE 802.1ag (in 4.5.2) and to ITU-T Y.1731 in 4.7= .1 and these seem out of context because they are included in sections abou= t the IETF OAM various work. Annex A.2 comes too late for this purpose, at = the end of the document.=20 3. Please add OWAMP and TWAMP to the list of abbreviations in 2.1 4. In Section 2.2.9 I see:=20 Point-to-multipoint (P2MP) A P2MP service delivers data from a single source to a one or more destinations (based on [Signal]). An MP2MP service as a service that delivers data from more than one source to one or more receivers (based on [Signal]). Actually the reference [Signal] a.k.a. RFC 4461 refers to one possible flav= or of P2MP which is MPLS-specific. It should be pointed to as an example, a= nd not as a reference upon which any P2MP OAM service is based, as the curr= ent text seems to indicate.=20 5. Section 5.3: I have a hard time understanding what the guidance to equip= ment vendors 'to enforce fate-sharing between OAM traffic and data place tr= affic' means. What should the vendors do differently?=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Bradner, > Scott > Sent: Tuesday, December 17, 2013 9:25 PM > To: opsawg@ietf.org > Subject: [OPSAWG] draft-ietf-opsawg-oam-overview WGLC (again) >=20 > this message represents the start of a new WGLC for draft-ietf-opsawg- > oam-overview >=20 > please take a look at the document and let the WG know what you think > please do so before Jan 7 >=20 > tnx >=20 > Scott >=20 >=20 > http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-11 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From mehmet.ersue@nsn.com Mon Jan 6 10:44:36 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A37D1AE17E for ; Mon, 6 Jan 2014 10:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAVEGNEba22M for ; Mon, 6 Jan 2014 10:44:33 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E18AE1AE15B for ; Mon, 6 Jan 2014 10:44:32 -0800 (PST) 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 s06IiMVO023579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2014 19:44:22 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s06IiMVh000727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jan 2014 19:44:22 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 6 Jan 2014 19:44:21 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Mon, 6 Jan 2014 19:44:21 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Cao,Zhen" Thread-Topic: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* Thread-Index: AQHPCrJpXASYx/AkA0mvvcW3JIGoM5p4B8sA Date: Mon, 6 Jan 2014 18:44:21 +0000 Message-ID: References: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 3621 X-purgate-ID: 151667::1389033862-000025D0-8B7AB5A3/0-0/0-0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 18:44:36 -0000 Dear Zhen, thank you for your kind review.=20 We mentioned in-car networks as part of Mobile Applications in section 2.10= . Do you think a separate use case should be added or it can be seen as cover= ed under M2M services? I agree management of 'sleepy nodes' might become challenging. I will look = into that in more detail. Would you like to contribute some text? Cheers,=20 Mehmet=20 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of ext Cao,Zhen > Sent: Monday, January 06, 2014 8:39 AM > To: Warren Kumari > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* >=20 > Dear authors and all, >=20 > I read through the two drafts, and believe the two documents are > useful for operators and SPs that manage a constrained device network. > Thank you for the work. >=20 > a) http://tools.ietf.org/html/draft-ersue-opsawg-coman-use-cases-00 >=20 > This draft is pretty sufficient at the time of writing. But i do not > know how to act for new use cases coming up. For example, vehicle > communication networks. There are many use case documents in IETF, but > how sufficient they should be. I believe the issue will be raised up > during IESG review. >=20 > b) http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-req= s/ >=20 > This document is also pretty sufficient. The requirement template is > very good practice. >=20 > One cent to the document is, shall we consider the management of > sleepy nodes in section 3? There are many discussions in coap/lwig for > these sleepy nodes. The management of these devices is rather > challenging. Although there are some discussion in 'Energy > management', the scope of sleepy nodes management should be broader > than that. >=20 > Best regards, > caozhen@chinamobile >=20 >=20 >=20 > On Thu, Dec 5, 2013 at 12:49 AM, Warren Kumari wrote: > > Hi all, > > > > Hopefully you all had a good Thanksgiving -- if you are in the US, hope= fully you had > good turkey, stuffing / whatever. > > If you are not US based, hopefully you enjoyed the decrease in email vo= lume while > everyone recovered form eating too much. :-) > > > > One of the action items from Vancouver was for us to call for reviewers= for: > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs= / > > and > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-use-cases/ > > > > So, can we get some volunteers please? According to our new guidelines = we require > sufficient reviewers before adopting new work. > > > > The documents are (IMO) interesting and easy to read. Constrained devic= es have > some interesting requirements and limitations. > > If you would like a quick reminder / refresher from the meeting, slides= are here: > http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pdf > > > > Juergen Schoenwaelder indicated = that one > of his Ph.D. students had read the draft a couple of weeks ago. So they j= ust have to > review the changes to the latest version. > > > > > > W > > -- > > "I think it would be a good idea." > > - Mahatma Ghandi, when asked what he thought of Western civilization > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From mehmet.ersue@nsn.com Mon Jan 6 10:56:44 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EAF1AE15B for ; Mon, 6 Jan 2014 10:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGF2HgfHaqXW for ; Mon, 6 Jan 2014 10:56:40 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 526B21AE1A3 for ; Mon, 6 Jan 2014 10:56:39 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s06IuTci012311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2014 19:56:29 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s06IuSsF010074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jan 2014 19:56:28 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Mon, 6 Jan 2014 19:56:28 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Hui Deng , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs Thread-Index: AQHPCrO7sUwzrZOCpEa7gRXDKH/j65p4CT0A Date: Mon, 6 Jan 2014 18:56:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.104] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8249B2DDEMUMBX005nsnintr_" MIME-Version: 1.0 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: 22909 X-purgate-ID: 151667::1389034589-00001A6F-9EEE7886/0-0/0-0 Subject: Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 18:56:44 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8249B2DDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hui, thank you for your kind review. > 1. in section 3., a section of 'IPv4/v6 address management' could be help= ful, including the discussion of different types of ip addresses on devices= , link-local, global, private, etc.. Concerning IPv4/v6 addresses which requirements do you have in mind from ma= nagement pov.? > 2. in Appendix A, any relevant discussion in 'oneM2M'? I would need your help for this as I'm not involved in oneM2M. Thanks. Cheers, Mehmet From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of ext Hui Deng Sent: Monday, January 06, 2014 8:49 AM To: opsawg@ietf.org Subject: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs Hi Authors, This document is very useful for service providers and operators that are m= anaging their constrained devices. Two cents for authors to consider, 1. in section 3., a section of 'IPv4/v6 address management' could be helpfu= l, including the discussion of different types of ip addresses on devices, = link-local, global, private, etc.. 2. in Appendix A, any relevant discussion in 'oneM2M'? Regards, -Hui 2014/1/4 Ersue, Mehmet (NSN - DE/Munich) > Hi Dan, thank you for your review and comments. See below. Cheers, Mehmet > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of ext Romascanu, Dan > (Dan) > Sent: Thursday, December 12, 2013 2:23 PM > To: Warren Kumari; opsawg@ietf.org > Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* > > Hi, > > I do not know if I really should be included in the reviewers count, as I= am a participant > in the coman work since it started, and my name shows up on the list of a= uthors, > although in all sincerity most of the credits go to Mehmet, who hold the = pen for most > of the time, including this latest wound which split the original documen= t into two > separate documents - one for use cases, the other for problem statement a= nd > requirements. Anyway, FWIW I obviously believe this work is useful and I = support > doing it in the OPSAWG. I have a few comments recorded below: > > draft-ersue-opsawg-coman-use-cases > > 1. I do not believe that we can get away with a zero-content security con= siderations > section. The described use cases mention the need to secure information c= ollected by > constrained devices, some other (like security cameras) carry information= related to > personal or public security that needs to be protected by robust mechanis= ms. These > kind of threats need to be mentioned IMO. You are right a dummy security considerations section is not sufficient. Coman was not planning to address security exhaustively. Solace, now ACE, h= as been started where security for constrained devices will be discussed. We discussed the security requirements in section 3.6 of the problem statem= ent draft. I agree, a discussion of the security threads should be provided in a secur= ity considerations section. > draft-ersue-opsawg-coman-probstate-reqs > > 1. The draft uses the 'adjective' small device in association with constr= ained device in a > few place. I suggest to remove this. There is no automatic association of= a device > being small implying that it is also constrained. Nor are all constrained= devices small in > size. Agree. We should be more precise with the terminology. > 2. We have made an effort in the last few versions and especially in this= one to > distinguish between the constrained devices and constrained networks, but= the clean-up > on this issue is not complete. For example section 1.6 still has text abo= ut constrained > networks - this section and other in which constrained networks are menti= oned should > be carefully examined to make sure that the focus of the document stays w= ith > constrained devices, and that if constrained networks are mentioned at al= l this is in the > context of their relationship with the constrained devices. Why strictly devices? We also have requirements discussing the organization= of constrained networks from management pov. in section 3.1. > 3. I do not believe that we can get away with a zero-content security con= siderations > section here either. The document even says: > > If specific requirements for > security will be identified, they will be described in future > versions of this document. > > This is not accurate - section 3.6 already speaks about requirments for s= ecurity and > access control, and section 1.6 mentions limitations that would prevent t= he > implementation of strong scryptographic algorythms. The text needs to be = reviewed > and revised from this perspective. I think the "future" is now and the current text in the security considerat= ions section needs to be replaced. I would suggest to provide a security co= nsiderations section by listing and discussing threads in the problem state= ment draft and refer to it from the use cases draft. Comments? > > Regards, > > Dan > > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari > > Sent: Wednesday, December 04, 2013 6:49 PM > > To: opsawg@ietf.org > > Subject: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* > > > > Hi all, > > > > Hopefully you all had a good Thanksgiving -- if you are in the US, > > hopefully you had good turkey, stuffing / whatever. > > If you are not US based, hopefully you enjoyed the decrease in email > > volume while everyone recovered form eating too much. :-) > > > > One of the action items from Vancouver was for us to call for reviewers > > for: > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs= / > > and > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-use-cases/ > > > > So, can we get some volunteers please? According to our new guidelines > > we require sufficient reviewers before adopting new work. > > > > The documents are (IMO) interesting and easy to read. Constrained > > devices have some interesting requirements and limitations. > > If you would like a quick reminder / refresher from the meeting, slides > > are here: http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pd= f > > > > Juergen Schoenwaelder > indicated > > that one of his Ph.D. students had read the draft a couple of weeks ago= . > > So they just have to review the changes to the latest version. > > > > > > W > > -- > > "I think it would be a good idea." > > - Mahatma Ghandi, when asked what he thought of Western civilization > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_E4DE949E6CE3E34993A2FF8AE79131F8249B2DDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hui,

 

thank you for your kind revi= ew.

 

> 1. in section 3., a = section of ‘IPv4/v6 address management’ could be helpful, inclu= ding the discussion of different types of ip addresses on devices, link-loc= al, global, private, etc..

Concerning IPv4/v6 addresses= which requirements do you have in mind from management pov.?

 

> 2. in Appendix A, an= y relevant discussion in ‘oneM2M’?

I would need your help for t= his as I’m not involved in oneM2M. Thanks.

 

Cheers,
Mehmet

 

From: OPSAWG [= mailto:opsawg-bounces@ietf.org] On Behalf Of ext Hui Deng
Sent: Monday, January 06, 2014 8:49 AM
To: opsawg@ietf.org
Subject: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-req= s

 

Hi Authors,

 

This document is very use= ful for service providers and operators that are managing their constrained= devices.

 <= /p>

Two cents for authors to = consider,

1. in section 3., a secti= on of ‘IPv4/v6 address management’ could be helpful, including = the discussion of different types of ip addresses on devices, link-local, global, private, etc..

2. in Appendix A, any rel= evant discussion in ‘oneM2M’?


Regards,

 

-Hui


 

2014/1/4 Ersue, Mehmet (NSN - DE/Munich) <mehmet.ersue@nsn.com= >

Hi Dan,

thank you for your review and comments. See below.

Cheers,
Mehmet

> -----Original Message-----
> From: OPSAWG [mailto:opsawg= -bounces@ietf.org] On Behalf Of ext Romascanu, Dan
> (Dan)
> Sent: Thursday, December 12, 2013 2:23 PM
> To: Warren Kumari; opsawg@ietf.org<= /a>
> Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*=
>
> Hi,
>
> I do not know if I really should be included in the reviewers count, a= s I am a participant
> in the coman work since it started, and my name shows up on the list o= f authors,
> although in all sincerity most of the credits go to Mehmet, who hold t= he pen for most
> of the time, including this latest wound which split the original docu= ment into two
> separate documents - one for use cases, the other for problem statemen= t and
> requirements. Anyway, FWIW I obviously believe this work is useful and= I support
> doing it in the OPSAWG. I have a few comments recorded below:
>
>  draft-ersue-opsawg-coman-use-cases
>
> 1. I do not believe that we can get away with a zero-content security = considerations
> section. The described use cases mention the need to secure informatio= n collected by
> constrained devices, some other (like security cameras) carry informat= ion related to
> personal or public security that needs to be protected by robust mecha= nisms. These
> kind of threats need to be mentioned IMO.

You are right a dummy security considerations section is not sufficient. Coman was not planning to address security exhaustively. Solace, now ACE, h= as
been started where security for constrained devices will be discussed.
We discussed the security requirements in section 3.6 of the problem statem= ent draft.

I agree, a discussion of the security threads should be provided in a secur= ity considerations section.

> draft-ersue-opsawg-coman-probstate-reqs
>
> 1. The draft uses the 'adjective' small device in association with con= strained device in a
> few place. I suggest to remove this. There is no automatic association= of a device
> being small implying that it is also constrained. Nor are all constrai= ned devices small in
> size.

Agree. We should be more precise with the terminology.

> 2. We have made an effort in the last few versions and especially in t= his one to
> distinguish between the constrained devices and constrained networks, = but the clean-up
> on this issue is not complete. For example section 1.6 still has text = about constrained
> networks - this section and other in which constrained networks are me= ntioned should
> be carefully examined to make sure that the focus of the document stay= s with
> constrained devices, and that if constrained networks are mentioned at= all this is in the
> context of their relationship with the constrained devices.

Why strictly devices? We also have requirements discussing the organization= of constrained networks from management pov. in section 3.1.

> 3. I do not believe that we can get away with a zero-content security = considerations
> section here either. The document even says:
>
>    If specific requirements for
>    security will be identified, they will be described in fu= ture
>    versions of this document.
>
> This is not accurate - section 3.6 already speaks about requirments fo= r security and
> access control, and section 1.6 mentions limitations that would preven= t the
> implementation of strong scryptographic algorythms. The text needs to = be reviewed
> and revised from this perspective.

I think the "future" is now and the current text in the security = considerations section needs to be replaced. I would suggest to provide a s= ecurity considerations section by listing and discussing threads in the pro= blem statement draft and refer to it from the use cases draft.
Comments?

>
> Regards,
>
> Dan
>
> > -----Original Message-----
> > From: OPSAWG [mailto:o= psawg-bounces@ietf.org] On Behalf Of Warren Kumari
> > Sent: Wednesday, December 04, 2013 6:49 PM
> > To: opsawg@ietf.org
> > Subject: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-= *
> >
> > Hi all,
> >
> > Hopefully you all had a good Thanksgiving -- if you are in the US= ,
> > hopefully you had good turkey, stuffing / whatever.
> > If you are not US based, hopefully you enjoyed the decrease in em= ail
> > volume while everyone recovered form eating too much. :-)
> >
> > One of the action items from Vancouver was for us to call for rev= iewers
> > for:
> > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs/
> > and
> > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-use-cases/
> >
> > So, can we get some volunteers please? According to our new guide= lines
> > we require sufficient reviewers before adopting new work.
> >
> > The documents are (IMO) interesting and easy to read. Constrained=
> > devices have some interesting requirements and limitations.
> > If you would like a quick reminder / refresher from the meeting, = slides
> > are here: http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pdf
> >
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> indicated
> > that one of his Ph.D. students had read the draft a couple of wee= ks ago.
> > So they just have to review the changes to the latest version. > >
> >
> > W
> > --
> > "I think it would be a good idea."
> > - Mahatma Ghandi, when asked what he thought of Western civilizat= ion
> >
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F8249B2DDEMUMBX005nsnintr_-- From s.anuj@jacobs-university.de Mon Jan 6 10:56:59 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBFF1AE1A3 for ; Mon, 6 Jan 2014 10:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrVHvwj81pNn for ; Mon, 6 Jan 2014 10:56:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 685F71AE1B2 for ; Mon, 6 Jan 2014 10:56:55 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5ED9220037; Mon, 6 Jan 2014 19:56:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id umhLZvL3dXPT; Mon, 6 Jan 2014 19:56:46 +0100 (CET) Received: from exchange.jacobs-university.de (unknown [10.70.0.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id 0CC3F2003E; Mon, 6 Jan 2014 19:56:46 +0100 (CET) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS04.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0174.001; Mon, 6 Jan 2014 19:56:45 +0100 From: "Sehgal, Anuj" To: "Ersue, Mehmet (NSN - DE/Munich)" Thread-Topic: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* Thread-Index: AQHPCrJpXASYx/AkA0mvvcW3JIGoM5p4B8sA///0IgA= Date: Mon, 6 Jan 2014 18:56:45 +0000 Message-ID: References: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.55.113.77] Content-Type: multipart/alternative; boundary="_000_FDF90B1FED984D8C87A03B3E28D6AE72jacobsuniversityde_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 18:56:59 -0000 --_000_FDF90B1FED984D8C87A03B3E28D6AE72jacobsuniversityde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 06 Jan 2014, at 7:44 pm, Ersue, Mehmet (NSN - DE/Munich) > wrote: We mentioned in-car networks as part of Mobile Applications in section 2.10= . Do you think a separate use case should be added or it can be seen as cover= ed under M2M services? I believe it would be better to expand the whole in-car networks part into = a new section on vehicular networking technologies, since this is a part of= emerging networks that will undoubtedly use constrained devices and possib= ly even constrained networks. Logically, in-car networks should be a sub-cl= ass of vehicular networks. Furthermore, it seems that the whole section on mobile applications is most= ly focusing purely on special cases of previous sections, or based on speci= al access technologies. Just this difference does not warrant a whole secti= on, in my opinion. It would seem much better to take the special cases (lik= e in-car networks) and merge them into appropriate sections (maybe new ones= , like on vehicular networks) and discuss limitations posed by access techn= ologies separately, especially since access technology based limitations wo= uld impact not only constrained but, to a slightly lesser degree, regular n= etworking devices within those networks as well. Regards, Anuj Sehgal --_000_FDF90B1FED984D8C87A03B3E28D6AE72jacobsuniversityde_ Content-Type: text/html; charset="us-ascii" Content-ID: <10DE22173DAB624F9ABEC961CCCF62E8@jacobs.jacobs-university.de> Content-Transfer-Encoding: quoted-printable
On 06 Jan 2014, at 7:44 pm, Ersue, Mehmet (NSN - DE/Munich) <mehmet.ersue@nsn.com> wrote:

We mentioned in-car networks as part of Mobile Applications in section 2.10.<= /span>
Do you think a separate use case should be added or it can be seen as covered= under M2M services?

I believe it would be better to expand the whole in-car networks part = into a new section on vehicular networking technologies, since this is a pa= rt of emerging networks that will undoubtedly use constrained devices and p= ossibly even constrained networks. Logically, in-car networks should be a sub-class of vehicular networks.

Furthermore, it seems that the whole section on mobile applications is= mostly focusing purely on special cases of previous sections, or based on = special access technologies. Just this difference does not warrant a whole = section, in my opinion. It would seem much better to take the special cases (like in-car networks) and merg= e them into appropriate sections (maybe new ones, like on vehicular network= s) and discuss limitations posed by access technologies separately, especia= lly since access technology based limitations would impact not only constrained but, to a slightly lesser de= gree, regular networking devices within those networks as well.

Regards,
Anuj Sehgal
--_000_FDF90B1FED984D8C87A03B3E28D6AE72jacobsuniversityde_-- From mehmet.ersue@nsn.com Mon Jan 6 11:13:43 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9701AE1AD for ; Mon, 6 Jan 2014 11:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWcmLbFRmBwb for ; Mon, 6 Jan 2014 11:13:41 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8FC1AE15B for ; Mon, 6 Jan 2014 11:13:41 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s06JDQas023117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2014 20:13:26 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s06JDPsI004895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jan 2014 20:13:25 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 6 Jan 2014 20:13:24 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Mon, 6 Jan 2014 20:13:24 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Juergen Schoenwaelder , "Romascanu, Dan (Dan)" Thread-Topic: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* Thread-Index: AQHO8RDEXASYx/AkA0mvvcW3JIGoM5pQjfnQgCLichCABDrIAIAABFAAgAAAlYCAAAOjAIAAjHdw Date: Mon, 6 Jan 2014 19:13:23 +0000 Message-ID: References: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> <9904FB1B0159DA42B0B887B7FA8119CA129E249A@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA129FD648@AZ-FFEXMB04.global.avaya.com> <20140106111946.GA36246@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA129FD6A1@AZ-FFEXMB04.global.avaya.com> <20140106113452.GD36246@elstar.local> In-Reply-To: <20140106113452.GD36246@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 1453 X-purgate-ID: 151667::1389035607-000025D0-8782CD70/0-0/0-0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 19:13:43 -0000 Hi Dan, Juergen, I agree that we need to keep the document focused on the 'Management of Net= works with Constrained Devices'. The discussion on the networks is because of the management considerations = where constrained devices are connected and need to be managed.=20 This network can be indeed constrained or non-constrained. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university= .de] > Sent: Monday, January 06, 2014 12:35 PM > To: Romascanu, Dan (Dan) > Cc: Ersue, Mehmet (NSN - DE/Munich); Warren Kumari; opsawg@ietf.org > Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* >=20 > On Mon, Jan 06, 2014 at 11:21:51AM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > That was my recollection as well. However - see the part of the discuss= ion that you > left out - there are still sections that deal with constrained networks i= n text > > >=20 > Then either the text needs to go or some of it needs to stay because > sometimes (in some application scenarios) constrained nodes to exist > on constrained networks. In other words, it needs to be looked at on > a case-by-case basis. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Mon Jan 6 11:30:41 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3081AE1AD for ; Mon, 6 Jan 2014 11:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsJlRex4QoT5 for ; Mon, 6 Jan 2014 11:30:38 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C45501AE167 for ; Mon, 6 Jan 2014 11:30:37 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s06JURDG009216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2014 20:30:27 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s06JUROh027124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jan 2014 20:30:27 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 6 Jan 2014 20:30:27 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Mon, 6 Jan 2014 20:30:26 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Sehgal, Anuj" Thread-Topic: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* Thread-Index: AQHPCrJpXASYx/AkA0mvvcW3JIGoM5p4B8sA///0IgCAABV4oA== Date: Mon, 6 Jan 2014 19:30:26 +0000 Message-ID: References: <29CE0400-8D3D-4F51-A7E4-D8816361D6CC@kumari.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.104] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8249BDEDEMUMBX005nsnintr_" MIME-Version: 1.0 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: 9727 X-purgate-ID: 151667::1389036627-000025D0-608E41B1/0-0/0-0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 19:30:41 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8249BDEDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I actually don't see a big coverage of Mobile Applications in other use cas= es. Only the use case Transport Applications is covering the mobility aspec= t (actually it includes also vehicle networks). For example use cases like Environmental Monitoring, Industrial Application= s, Building Automation etc. use a fixed or wireless network but the devices= are mainly non-mobile. May be the sections on Transport Applications and Mobile Applications could= be merged. Though Mobile Applications can have different facets which go b= eyond transport networks. I think Mobile Applications should be kept separa= te as they differ from fixed/wireless non-mobile applications. Cheers, Mehmet From: ext Sehgal, Anuj [mailto:s.anuj@jacobs-university.de] Sent: Monday, January 06, 2014 7:57 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: ext Cao,Zhen; opsawg@ietf.org Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* On 06 Jan 2014, at 7:44 pm, Ersue, Mehmet (NSN - DE/Munich) > wrote: We mentioned in-car networks as part of Mobile Applications in section 2.10= . Do you think a separate use case should be added or it can be seen as cover= ed under M2M services? I believe it would be better to expand the whole in-car networks part into = a new section on vehicular networking technologies, since this is a part of= emerging networks that will undoubtedly use constrained devices and possib= ly even constrained networks. Logically, in-car networks should be a sub-cl= ass of vehicular networks. Furthermore, it seems that the whole section on mobile applications is most= ly focusing purely on special cases of previous sections, or based on speci= al access technologies. Just this difference does not warrant a whole secti= on, in my opinion. It would seem much better to take the special cases (lik= e in-car networks) and merge them into appropriate sections (maybe new ones= , like on vehicular networks) and discuss limitations posed by access techn= ologies separately, especially since access technology based limitations wo= uld impact not only constrained but, to a slightly lesser degree, regular n= etworking devices within those networks as well. Regards, Anuj Sehgal --_000_E4DE949E6CE3E34993A2FF8AE79131F8249BDEDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I actually don’t see a= big coverage of Mobile Applications in other use cases. Only the use case = Transport Applications is covering the mobility aspect (actually it includes also vehicle networks).

 

For example use cases like E= nvironmental Monitoring, Industrial Applications, Building Automation etc. = use a fixed or wireless network but the devices are mainly non-mobile. 

 

May be the sections on Trans= port Applications and Mobile Applications could be merged. Though Mobile Ap= plications can have different facets which go beyond transport networks. I think Mobile Applications should be kept separate as they diff= er from fixed/wireless non-mobile applications.

 

Cheers,
Mehmet

 

From: ext Sehg= al, Anuj [mailto:s.anuj@jacobs-university.de]
Sent: Monday, January 06, 2014 7:57 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: ext Cao,Zhen; opsawg@ietf.org
Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman= -*

 

 

 

I believe it would be better to expand the whole in-= car networks part into a new section on vehicular networking technologies, = since this is a part of emerging networks that will undoubtedly use constra= ined devices and possibly even constrained networks. Logically, in-car networks should be a sub-class of vehicular ne= tworks.

 

Furthermore, it seems that the whole section on mobi= le applications is mostly focusing purely on special cases of previous sect= ions, or based on special access technologies. Just this difference does no= t warrant a whole section, in my opinion. It would seem much better to take the special cases (like in-car networks)= and merge them into appropriate sections (maybe new ones, like on vehicula= r networks) and discuss limitations posed by access technologies separately= , especially since access technology based limitations would impact not only constrained but, to a slightly les= ser degree, regular networking devices within those networks as well.<= /o:p>

 

Regards,

Anuj Sehgal

--_000_E4DE949E6CE3E34993A2FF8AE79131F8249BDEDEMUMBX005nsnintr_-- From Bert.Greevenbosch@huawei.com Thu Jan 9 01:02:19 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCF21ADFE2 for ; Thu, 9 Jan 2014 01:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDoac0IEiUmu for ; Thu, 9 Jan 2014 01:02:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECEA1ADF66 for ; Thu, 9 Jan 2014 01:02:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZT75469; Thu, 09 Jan 2014 09:02:07 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jan 2014 09:01:37 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jan 2014 09:02:03 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 9 Jan 2014 17:02:00 +0800 From: Bert Greevenbosch To: "opsawg@ietf.org" Thread-Topic: Review of draft-ersue-opsawg-coman-probstate-reqs Thread-Index: Ac8NGXQZpLP6/YRJRiSj0GhG8S+cUA== Date: Thu, 9 Jan 2014 09:01:59 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E3D4DF8@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [OPSAWG] Review of draft-ersue-opsawg-coman-probstate-reqs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 09:02:19 -0000 Hi all, I have reviewed the "Management of Networks with Constrained Devices: Probl= em Statement and Requirements" draft. I think it is good work, and look forward to its finalising. I have the following comments, most of them (all?) quite easy to resolve: (BG1) Section 2: "tininess" can be replaced by "contraints" (BG2) Section 2: "constraindness" -> constrainedness", "therefor" -> "there= fore" (BG3) Section 3.1, req 4.1.001: Device type should be "C0, C1 and/or C2" as= described in section 3. (BG4) Section 3.1, req 4.1.002: "This implies that e.g. the managing entity= is able to handle huge amount of device monitoring data and the management= protocol is not sensitive to the decrease of the time between two client r= equests." - I think this would better be a separate requirement. (BG5) Section 3.1, req 4.1.004: "One way to achieve this is to adopt a REST= ful architecture that minimizes the amount of state maintained by managed c= onstrained devices and that makes resources of a device addressable via URI= s." - This is a solution, not a requirement. I think the text can be deleted. (BG6) Section 3.1, req 4.1.006: "Intermediaries may be used that provide in= formation for devices currently inactive or that take responsibility to res= ynchronize devices when they become reachable again after an extended offli= ne period." - This is a solution, not a requirement. I think the text can be deleted. (BG7) Section 3.1, req 4.1.007: "The identification of the relevant subset = of policies to be provisioned is according to the capabilities of each devi= ce and can be obtained from a pre-configured data-repository." - This is a solution, not a requirement. I think the text can be deleted. (BG8) Section 3.2, req 4.2.002: is this a non-functional requirement? If so= , write this in requirement type. (BG9) Section 3.2, req 4.2.003: "As such, this requirement is marked as opt= ional." - I think most requirements are optional at this point, since the draft doe= s not point at a specific solution. Delete the sentence. (BG10) Section 3.2, req 4.2.004: "Hence this requirement is marked optional= for device class C2."=20 - This can be deleted; it should have been device class C0 (most constraine= d) anyway. (BG11) Sentences like those in BG9 and BG10 appear also elsewhere. Propose = to remove. (BG12) Section 3.2, req 4.2.004: "Device type: C2", add "C1". (related to B= G10) (BG12) Section 3.2, req 4.2.006: "Device type: C2", add "C1". (BG13) Section 3.3, req 4.3.003: the description should be more verbose and= explicit. (BG14) Section 3.3, req 4.3.003: why does the requirement not apply to C0 d= evices? They may be sleepy and thus require asynchronous transactions. (BG15) Section 3.4, req 4.4.001: "data caching mechanism" requires a defini= tion or explanation. (BG16) Section 3.4, req 4.4.004 is marked as "low priority". Isn't network = status monitoring a major use-case? (BG17) Section 3.4, req 4.4.006 contains "(TBD)". Remove. (BG18) Section 3.4, req 4.4.011: should C0 (low priority) be mentioned? (BG19) Section 3.6, req 4.6.001: "In certain application scenarios, it is p= ossible that a large number of devices need to be (re)started at about the = same time. Protocols and authentication systems should be designed such tha= t a large number of devices (re)starting simultaneously does not negatively= impact the device authentication process." - I think this should be a requirement on its own. (BG20) Section 3.6, req 4.6.002: propose to change "add them to access cont= rol lists." to "provide them with appropriate access control permissions.",= as "access control lists" are a specific solution. (BG21) Section 3.6, req 4.6.004: "(like some elliptic curve algorithm)" can= be deleted, as it seems unnecessary information. (BG22) Section 3.6, req 4.6.004: why is there a distinction in priority bet= ween hardware-supported algorithms and other algorithms? I propose to set t= he priority of all to "high". (BG23) Section 3.7, req 4.7.003: "The device will support layer 2 energy ma= nagement protocols (e.g. energy-efficient Ethernet IEEE 802.3az) and be abl= e to report on these." - This should be rephrased to "If the device supports layer 2 ..., it shoul= d be able to report on these". (BG24) Section 3.10, req 4.10.001: "not sensitive to the decrease of the ti= me between two client requests." - Propose to change to "not sensitive to a high rate of incoming client req= uests." (BG25) Section 3.10: put a "---" line between reqs 4.10.003 and 4.10.004. (BG26) Section 3.11: put a "---" line between reqs 4.11.001 and 4.11.002. (BG27) Section 5: "If specific requirements for security will be identified= , they will be described in future versions of this document." - There are already security requirements in section 3.6, let's mention tha= t in the security considerations section. (BG28) Appendix A has some overlap with draft-greevenbosch-coman-candidate-= tech, which also describes current available technology. (BG29) Appendix A.3 "OMA" should mention that the OMA LwM2M Technical Speci= fication (TS) has now reached candidate status. The appendix currently only= mentions the LwM2M requirements document. (BG30) Appendix C: "Section 4 on the management requirements ... needs furt= her consolidation." - I think this has already been done. In any case, the appendix can be remo= ved. I hope this helps! Best regards, Bert From internet-drafts@ietf.org Thu Jan 9 06:44:29 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797C1AE32B; Thu, 9 Jan 2014 06:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70UacVkmcHg1; Thu, 9 Jan 2014 06:44:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 286211AE359; Thu, 9 Jan 2014 06:44:27 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140109144426.25252.11511.idtracker@ietfa.amsl.com> Date: Thu, 09 Jan 2014 06:44:26 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-oam-overview-12.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:44:29 -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 Working Gr= oup Working Group of the IETF. Title : An Overview of Operations, Administration, and Ma= intenance (OAM) Tools Authors : Tal Mizrahi Nurit Sprecher Elisa Bellagamba Yaacov Weingarten Filename : draft-ietf-opsawg-oam-overview-12.txt Pages : 48 Date : 2014-01-09 Abstract: Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS for the transport profile (MPLS-TP), pseudowires, and TRILL. This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators and standard development organizations, and can be used as an index to some of the main OAM tools defined in the IETF. This document provides a brief description of each of the OAM tools in the IETF. At the end of the document a list of the OAM toolsets and a list of the OAM functions are presented as a summary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-oam-overview-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From warren@kumari.net Fri Jan 10 08:48:28 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014F51AE09F for ; Fri, 10 Jan 2014 08:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxTtPKGrRdlM for ; Fri, 10 Jan 2014 08:48:26 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 625071AE047 for ; Fri, 10 Jan 2014 08:48:26 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id m15so1358144wgh.26 for ; Fri, 10 Jan 2014 08:48:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=r2Bid91zGKlp2cnKQiQf75WGibfsFi2Xz3uv2bWwe9w=; b=kkeol2/Byinzzc81EEumrpdCEbj2tddrFP3c2+aKX8R6uSvQr1fDvyeO+qRBe8ELvR nWBxMZfsjigRo5HbNUAvRfRoeo424X3zd/8GgS/mdRvBqBEjEk8/hwmpBLF90la0pgN3 GR7hiKK0MdpzTGxUOunjJM7P8EA7H+jL52MUo1z3hLIBdW07OROcEWUZgSqO8/y3dTYJ QXSU6rZ0Gnz49arExIYSSGCuyVYiuChlrfdcfl9UMTI9uzrTvXCFItrWbLGRV7E/CJNc 3Pjf8BDbL156BCRGVkiQwiaycOiCvPxQhWEizwO6oP0L1DGB5Cd/GCb1TgXqSnE/pq/p MrJQ== X-Gm-Message-State: ALoCoQmJ/Ex4/rd2y1wLeWIkHs34qT41sVtimtuZrcnhgufD8uRoghxRU6vLEJMc0uZmOemZJbzV MIME-Version: 1.0 X-Received: by 10.180.212.98 with SMTP id nj2mr3655741wic.52.1389372495927; Fri, 10 Jan 2014 08:48:15 -0800 (PST) Received: by 10.194.54.167 with HTTP; Fri, 10 Jan 2014 08:48:15 -0800 (PST) X-Originating-IP: [98.244.98.35] Date: Fri, 10 Jan 2014 11:48:15 -0500 Message-ID: From: Warren Kumari To: opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OPSAWG] Adoption of the draft-ersue-opsawg-coman-* drafts. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:48:28 -0000 Hi all, We feel that we now have sufficient demonstrated interest / reviewers to adopt the draft-ersue-opsawg-coman-* drafts as WG items. Dear authors, please resubmit as draft-ietf. In addition: Are you personally aware of any IPR that applies to these drafts? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. Thank you! W From j.schoenwaelder@jacobs-university.de Fri Jan 10 11:25:17 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B98C1AE13F for ; Fri, 10 Jan 2014 11:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rosce8hXXrUY for ; Fri, 10 Jan 2014 11:25:15 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 082151AE1C9 for ; Fri, 10 Jan 2014 11:25:15 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80A1320092; Fri, 10 Jan 2014 20:25:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iogsI42mL3sz; Fri, 10 Jan 2014 20:25:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91BA02008F; Fri, 10 Jan 2014 20:25:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 905DF2A82B52; Fri, 10 Jan 2014 20:25:01 +0100 (CET) Date: Fri, 10 Jan 2014 20:25:01 +0100 From: Juergen Schoenwaelder To: Warren Kumari Message-ID: <20140110192501.GC48942@elstar.local> Mail-Followup-To: Warren Kumari , opsawg@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Adoption of the draft-ersue-opsawg-coman-* drafts. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 19:25:17 -0000 On Fri, Jan 10, 2014 at 11:48:15AM -0500, Warren Kumari wrote: > Hi all, > > We feel that we now have sufficient demonstrated interest / reviewers > to adopt the draft-ersue-opsawg-coman-* drafts as WG items. > > Dear authors, please resubmit as draft-ietf. > > In addition: > Are you personally aware of any IPR that applies to these drafts? If > so, has this IPR been disclosed in compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are > personally aware of any relevant IPR. I am personally not aware of any IPR that applies to these drafts. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Sun Jan 12 00:54:06 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6BA1AD73F for ; Sun, 12 Jan 2014 00:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdJ4Zcrw2RT2 for ; Sun, 12 Jan 2014 00:54:04 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7491AD62B for ; Sun, 12 Jan 2014 00:54:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAKRX0lKHCzI1/2dsb2JhbABagmohOFa5GU+BBhZ0giUBAQEBAwEBAQ8oNBcEAgEIDQQEAQELFAkHJwsUCQgCBAESCBqHYgEMnlulFBMEjiURAR84BoMegRMEnwOLKYMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,646,1384318800"; d="scan'208";a="44612829" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Jan 2014 03:53:48 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 12 Jan 2014 03:41:31 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0158.001; Sun, 12 Jan 2014 09:53:16 +0100 From: "Romascanu, Dan (Dan)" To: Warren Kumari , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Adoption of the draft-ersue-opsawg-coman-* drafts. Thread-Index: AQHPDiPG39kk1QR0KEmov6JSl0yVU5qAyupQ Date: Sun, 12 Jan 2014 08:53:15 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243C9501@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] Adoption of the draft-ersue-opsawg-coman-* drafts. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 08:54:06 -0000 Hi, I am personally not aware about any IPR related to the draft-ersue-opsawg-c= oman-* drafts. Regards, Dan > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari > Sent: Friday, January 10, 2014 6:48 PM > To: opsawg@ietf.org > Subject: [OPSAWG] Adoption of the draft-ersue-opsawg-coman-* drafts. >=20 > Hi all, >=20 > We feel that we now have sufficient demonstrated interest / reviewers to > adopt the draft-ersue-opsawg-coman-* drafts as WG items. >=20 > Dear authors, please resubmit as draft-ietf. >=20 > In addition: > Are you personally aware of any IPR that applies to these drafts? If > so, has this IPR been disclosed in compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a > document author or listed contributor on this document, please reply to > this email regardless of whether or not you are personally aware of any > relevant IPR. >=20 > Thank you! > W > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From warren@kumari.net Mon Jan 13 11:48:03 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984231ADF97 for ; Mon, 13 Jan 2014 11:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ73JvAVoR6L for ; Mon, 13 Jan 2014 11:48:00 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6789C1ADF89 for ; Mon, 13 Jan 2014 11:48:00 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hq4so2716447wib.14 for ; Mon, 13 Jan 2014 11:47:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lgIsjVQ2JbxwULeOMIS2/ZBaLg0xXVKrB4YjqFba1Fo=; b=UfOYdc63r47KezlrlD6nicOVMmP1Xj2pUyg0F4gNJ0T6zWKEgAdKlIYk5aUwmbPVwh /bZRXFo8+C6zUeOUekhoP3pc2BBqQbNYFd8fNjd62rug9yhuFAaC6Y1y6Ii5LgFWxKX0 xbkFveq56RWC8Ye/tpqOOmNcyge/zis0Ocze2YzQyl69gp058lO3jsWgZNSANsxHhsiN ewDw9c+JKT3JaJsw/ZDh/IiEJqzlUMXYIHeQVURM2ltLBSqqPXIcQ3+fsFlsX5yHVIGm yBphK/gGaK8+0MwRr2tyWIvHm+lKB2CUlrZXOb6oBYA3Knyr1V3Ff11DppFRDDPGgBz8 Pa2w== X-Gm-Message-State: ALoCoQmBXf9xiB9lYoxgLCVX3K4IKYj4n2FZOBnLeP1P8xZjGEgb+c7OzdXuqNe+NpUadKwnG5j/ MIME-Version: 1.0 X-Received: by 10.194.75.198 with SMTP id e6mr23288376wjw.3.1389642468663; Mon, 13 Jan 2014 11:47:48 -0800 (PST) Received: by 10.194.54.167 with HTTP; Mon, 13 Jan 2014 11:47:48 -0800 (PST) X-Originating-IP: [98.244.98.35] In-Reply-To: References: <52A9D813.3060701@cisco.com> Date: Mon, 13 Jan 2014 14:47:48 -0500 Message-ID: From: Warren Kumari To: ramki Krishnan Content-Type: text/plain; charset=ISO-8859-1 Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-large-flow-load-balancing@tools.ietf.org" , Wesley George Subject: Re: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new version needed to address the IETF LC comments X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:48:03 -0000 On Thu, Dec 26, 2013 at 2:16 PM, ramki Krishnan wrote: > Dear Benoit, > > > > The last call comments and your comments are addressed in the latest version > of the draft. > I think that you missed Pete's comments in http://www.ietf.org/mail-archive/web/opsawg/current/msg02881.html In addition to his note that "last part of that sentence needs clarification" it also has a typo ("distribution at with multi-node" - extra 'at'?) I *think* that you captured all of Benoit's comments, but will leave it to him to confirm. I think that you also cover Wes' comments from http://www.ietf.org/mail-archive/web/opsawg/current/msg02916.html, in section 5.6.2, but it wouldn't hurt to check with him (CCed). The nits checker still complains that it cannot find the publication date, presumably because there are 6 authors. The RFC Editor policy (at http://www.rfc-editor.org/policy.html ) says: "There is no rigid limit on the size of this set, but there is likely to be a discussion if the set exceeds five authors, in which case the right answer is probably to list one editor." You can duke it out with RFC Ed, but personally I'd suggest just reading the "Author Overload" section and implementing one of the options. W > > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ > > > > Thanks, > > Ramki > > > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Thursday, December 12, 2013 5:37 AM > To: draft-ietf-opsawg-large-flow-load-balancing@tools.ietf.org > Cc: opsawg@ietf.org > Subject: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new version > needed to address the IETF LC comments > > > > Dear draft-ietf-opsawg-large-flow-load-balancing authors, > > I started to AD review of draft-ietf-opsawg-large-flow-load-balancing (Sorry > for the delay btw). > Then I reviewed the WG LC feedback (email from Melinda, "[OPSAWG] WG last > call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in > Networks", on August 24th), and I realized that I have the same feedback as > Dan Romascanu in > http://www.ietf.org/mail-archive/web/opsawg/current/msg02891.html > > Then I reviewed all the WGLC feedback, and it appears that this document was > sent on my plate, while the most up to date draft version 5 still doesn't > address the WGLC feedback. > For example: > http://www.ietf.org/mail-archive/web/opsawg/current/msg02897.html > > "It refers to all of them, i.e. LAG, ECMP, and even the (hierarchical) > combination. We can try and provide some clarification around that. We > will add 802.1AX as a reference for LAG." > > Please post a revised version that addresses the WGLC comments. > > While you are at it (and since I reviewed 1/3 of the document), here is part > of my feedback. > I'll restart my AD review with the next version > > Regards, Benoit > > ================================================================= > > - You use the term flow is a lot. Your definition is in line with the Flow > definition in RFC 7011 (IPFIX). > > Why not reuse it? > > Even your specific flow definition could re use the same "Flow" definition > from RFC 7011 > > > > Large Flow(s): long-lived large Flow(s) > > > > Small Flow(s): long-lived small Flow(s) and short-lived small/large > Flow(s) > > > > - How many flow categories do you want to stress? > > 1. Introduction: > > Network traffic can be predominantly categorized into two traffic > > types: long-lived large flows and other flows (which include long- > > lived small flows, short-lived small/large flows) > > 1.2. Terminology > > Large flow(s): long-lived large flow(s) > > Small flow(s): long-lived small flow(s) and short-lived small/large > > flow(s) > > 2. Flow Categorization > > In general, based on the size and duration, a flow can be categorized > > into any one of the following four types, as shown in Figure 1: > > (a) Short-Lived Large Flow (SLLF), > > (b) Short-Lived Small Flow (SLSF), > > (c) Long-Lived Large Flow (LLLF), and > > (d) Long-Lived Small Flow (LLSF). > > > > Please be consistent. This is slightly confusing. > > This only makes sense with the sentence at the end of section 2. > > In this document, we categorize Long-lived large flow(s) as "Large" > > flow(s), and all of the others -- Long-lived small flow(s) and short- > > lived small/large flow(s) as "Small" flow(s). > > > > Proposal (to make it clear earlier in document): > > OLD: > > Network traffic can be predominantly categorized into two traffic > > types: long-lived large flows and other flows (which include long- > > lived small flows, short-lived small/large flows) > > > > NEW: > > Network traffic can be predominantly categorized into two traffic > > types: long-lived large flows and other flows. These other flow, > > which include long-lived small flows and short-lived small/large flows, > > are considered as small flows in this document. > > > > > > > > EDITORIAL > > - > > Please expand LAG/ECMP in the abstract. While ECMP is known, LAG is not. > > > > - > > (load/mix and comma) > > OLD: > > If the traffic load constitutes flows such that the result of the > > hash function across these flows is fairly uniform so that a similar > > number of flows is mapped to each component link, if, the individual > > flow rates are much smaller as compared to the link capacity, > > NEW: > > If the traffic mix constitutes flows such that the result of the > > hash function across these flows is fairly uniform so that a similar > > number of flows is mapped to each component link, if the individual > > flow rates are much smaller as compared to the link capacity, > > > > - > > EDITORIAL > > OLD: > > Where: ->-> small flows > > ===> large flow > > > > NEW: > > Where: -> small flow > > ===> large flow > > > > Alternatively, make it clear in the figure that "-> -> ->" means 3 small > flows, by having each flow on a new line. > > > > In the same figure, what does "--/---/-" mean? > > > > - > > To demonstrate the limitations of local optimization, consider a two- > > level fat-tree topology with three leaf nodes (L1, L2, L3) and two > > spine nodes (S1, S2) and assume all of the links are 10 Gbps. Let L1 > > have two flows of 4 Gbps each towards L3, and let L2 have one flow of > > 7 Gbps also towards L3. If L1 balances the load optimally between S1 > > and S2, and L2 sends the flow via S1, then the downlink from S1 to L3 > > would get congested resulting in packet discards. On the other hand, > > if L1 had sent both its flows towards S1 and L2 had sent its flow > > towards S2, there would have been no congestion at either S1 or S2. > > > > A figure would be appreciated. > > > > - as a courtesy for the RFC editors, please order the references > > > > - idnits complains about the date. > > > > - RFC 5101 -> RFC 7011 > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From bclaise@cisco.com Tue Jan 14 08:34:09 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989361AE0DC for ; Tue, 14 Jan 2014 08:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfjdbzMiF6_Z for ; Tue, 14 Jan 2014 08:34:07 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 023A81ADF7F for ; Tue, 14 Jan 2014 08:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2403; q=dns/txt; s=iport; t=1389717234; x=1390926834; h=message-id:date:from:mime-version:to:cc:subject; bh=Gb23Cbzx1FgxGHe5+oPVbMPOX6Myhin8uZUC9x7bvOc=; b=hoMTVX3J3s6aehooJpt6Xp5iG4wnuXAL4sm9Dv/vU8rKa7kwf4lEbWo5 I1AgM80Sb+sbyexi+n10jscQbfjAQ7OFIza4ZGQopFf+7FRsp5K7FcmON cN2HczpRImnxqg0wT7X60UIH2IaAo8vc88TctRDtnRhRTvxJwdoB29isu I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAI1m1VKQ/khN/2dsb2JhbABagws4uzKBFRZ0gxoKAR8BHBYYAwIBAgFLCgMBBwEBiAANxDQTBI8HhD4EjjmJZYZFi1CDLjs X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208,217";a="2949828" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 14 Jan 2014 16:33:52 +0000 Received: from [10.149.0.203] (dhcp-10-149-0-203.cisco.com [10.149.0.203]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0EGXqja009054; Tue, 14 Jan 2014 16:33:52 GMT Message-ID: <52D566F0.5030103@cisco.com> Date: Tue, 14 Jan 2014 17:33:52 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Edward Beili Content-Type: multipart/alternative; boundary="------------000103000505020203020308" Cc: Pat Thaler , "opsawg@ietf.org" Subject: [OPSAWG] Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:34:09 -0000 This is a multi-part message in MIME format. --------------000103000505020203020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Ed, The OPSAWG charter says: (D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011. Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" as an reference, the following pieces of information would the foundation for the document: a table mapping the old IETF MIB names with the corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interactions (mailing lists, reviews), and clarifications on the intellectual property considerations. If I remember correctly, you committed to work on this one. With the approval of draft-ietf-opsawg-rfc5066bis-07 , are you now focusing on this new work item? Please let us know. Regards, Benoit --------------000103000505020203020308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Ed,

The OPSAWG charter says:
(D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011.
Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to IEEE
802.1 WG" as an reference, the following pieces of information would the
foundation for the document: a table mapping the old IETF MIB names with the
corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interactions
(mailing lists, reviews), and clarifications on the intellectual property considerations.
If I remember correctly, you committed to work on this one.
With the approval of draft-ietf-opsawg-rfc5066bis-07, are you now focusing on this new work item?

Please let us know.

Regards, Benoit



--------------000103000505020203020308-- From EdwardB@actelis.com Tue Jan 14 08:38:57 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C2B1AE124 for ; Tue, 14 Jan 2014 08:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAEhif3XpD_G for ; Tue, 14 Jan 2014 08:38:54 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id D6B811ADF7F for ; Tue, 14 Jan 2014 08:38:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,658,1384293600"; d="scan'208,217";a="2462762" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 14 Jan 2014 18:38:41 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Tue, 14 Jan 2014 18:38:41 +0200 From: Edward Beili To: Benoit Claise Date: Tue, 14 Jan 2014 18:38:40 +0200 Thread-Topic: Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 Thread-Index: Ac8RRmrJXpTQOFiKQCaD41A1q7SKjwAAE6Hg Message-ID: <4087887712E5C648B9F72BB9D912FD4602F6D3A4EBF8@il-mail07.actelis.net> References: <52D566F0.5030103@cisco.com> In-Reply-To: <52D566F0.5030103@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4EBF8ilmail07act_" MIME-Version: 1.0 Cc: Pat Thaler , "opsawg@ietf.org" Subject: Re: [OPSAWG] Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:38:57 -0000 --_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4EBF8ilmail07act_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Benoit, I wouldn't call it focusing, but since I committed I would have to do it. Thanks for reminding me. Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, January 14, 2014 18:34 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thaler Subject: Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 Dear Ed, The OPSAWG charter says: (D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011. Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" as an reference, the following pieces of information would the foundation for the document: a table mapping the old IETF MIB names with th= e corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interact= ions (mailing lists, reviews), and clarifications on the intellectual property c= onsiderations. If I remember correctly, you committed to work on this one. With the approval of draft-ietf-opsawg-rfc5066bis-07, are you now focusing on this new= work item? Please let us know. Regards, Benoit --_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4EBF8ilmail07act_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Benoit,

I wouldn= 217;t call it focusing, but since I committed I would have to do it.

Thanks for reminding me.

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
<= b>Sent: Tuesday, January 14, 2014 18:34
To: Edward Beili
<= b>Cc: opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thaler
Subject:<= /b> Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011=

 

Dear Ed,

The OPSAWG charter says:

(D) Documenting the list of RFCs transitioned to the IEEE= 802.3.1-2011.
Considering RFC 4663 "Transferring MIB Work from IE= TF Bridge MIB WG to IEEE
802.1 WG" as an reference, the following = pieces of information would the
foundation for the document: a table ma= pping the old IETF MIB names with the
corresponding new IEEE ones, clar= ifications/rules on the IETF-IEEE interactions
(mailing lists, reviews)= , and clarifications on the intellectual property considerations.

If I remember corr= ectly, you committed to work on this one.
With the approval of draft-i= etf-opsawg-rfc5066bis-07, are you now focusing on this new work item?
Please let us know.

Regards, Benoit


=
= --_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4EBF8ilmail07act_-- From bclaise@cisco.com Tue Jan 14 08:46:49 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF631AE133 for ; Tue, 14 Jan 2014 08:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4OqXg7FBxaj for ; Tue, 14 Jan 2014 08:46:47 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5F20C1ADFD0 for ; Tue, 14 Jan 2014 08:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7499; q=dns/txt; s=iport; t=1389717995; x=1390927595; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=nxBKwM60nH+ymdjFsWmUx/0OgqJWk/wTTnoaNXrdSrk=; b=aB+1L54cBf/gvRrw68BpACjlncAbsDJf3vwNeQG1f3wLdMGkSFnQMu7v z6NstFxbYAX0YEgjHhnXAjKJYZ0tQZsqfabYqJvqf31u0qGTA+vm3fVAJ wbTVEhFe3M8kpvHtMzOz0Hm2kjYkl28us6QlrHA1xItTSLMGLQEh70Uii g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAARp1VKQ/khL/2dsb2JhbABagkdEOLsygRUWdIIlAQEBBC1BCgEQCxEEAQEKFggHCQMCAQIBNAkIBgoDAQUCAQGIAA3ENBMEjwcGAYQ3BI45iWWGRYtQgy47 X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208,217";a="2950276" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 14 Jan 2014 16:46:34 +0000 Received: from [10.149.0.203] (dhcp-10-149-0-203.cisco.com [10.149.0.203]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0EGkXlC021606; Tue, 14 Jan 2014 16:46:34 GMT Message-ID: <52D569E9.7030303@cisco.com> Date: Tue, 14 Jan 2014 17:46:33 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Edward Beili References: <52D566F0.5030103@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D3A4EBF8@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4602F6D3A4EBF8@il-mail07.actelis.net> Content-Type: multipart/alternative; boundary="------------030901060605010104060406" Cc: Pat Thaler , "opsawg@ietf.org" Subject: Re: [OPSAWG] Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:46:49 -0000 This is a multi-part message in MIME format. --------------030901060605010104060406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ed, > > Benoit, > > I wouldn't call it focusing, but since I committed I would have to do it. > Thanks. Any time estimation? Regards, Benoit. > > Thanks for reminding me. > > Regards, > > -E. > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Tuesday, January 14, 2014 18:34 > *To:* Edward Beili > *Cc:* opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thaler > *Subject:* Documenting the list of RFCs transitioned to the IEEE > 802.3.1-2011 > > Dear Ed, > > The OPSAWG charter says: > > (D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011. > Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to > IEEE > 802.1 WG" as an reference, the following pieces of information would the > foundation for the document: a table mapping the old IETF MIB names > with the > corresponding new IEEE ones, clarifications/rules on the IETF-IEEE > interactions > (mailing lists, reviews), and clarifications on the intellectual > property considerations. > > If I remember correctly, you committed to work on this one. > With the approval of draft-ietf-opsawg-rfc5066bis-07 > , are > you now focusing on this new work item? > > Please let us know. > > Regards, Benoit > > --------------030901060605010104060406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Ed,

Benoit,

I wouldn’t call it focusing, but since I committed I would have to do it.

Thanks.  Any time estimation?

Regards, Benoit.

Thanks for reminding me.

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, January 14, 2014 18:34
To: Edward Beili
Cc: opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thaler
Subject: Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011

 

Dear Ed,

The OPSAWG charter says:

(D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011.
Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to IEEE
802.1 WG" as an reference, the following pieces of information would the
foundation for the document: a table mapping the old IETF MIB names with the
corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interactions
(mailing lists, reviews), and clarifications on the intellectual property considerations.

If I remember correctly, you committed to work on this one.
With the approval of draft-ietf-opsawg-rfc5066bis-07, are you now focusing on this new work item?

Please let us know.

Regards, Benoit



--------------030901060605010104060406-- From EdwardB@actelis.com Tue Jan 14 09:34:11 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30D71AE15E for ; Tue, 14 Jan 2014 09:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTAepf6DrYV7 for ; Tue, 14 Jan 2014 09:34:09 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id AD0EF1AE142 for ; Tue, 14 Jan 2014 09:34:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,658,1384293600"; d="scan'208,217";a="2463001" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 14 Jan 2014 19:33:56 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Tue, 14 Jan 2014 19:33:56 +0200 From: Edward Beili To: Benoit Claise Date: Tue, 14 Jan 2014 19:33:54 +0200 Thread-Topic: Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 Thread-Index: Ac8RSDBILHYdk+dQTwmfil5PniulqgABoJpw Message-ID: <4087887712E5C648B9F72BB9D912FD4602F6D3A4EBFB@il-mail07.actelis.net> References: <52D566F0.5030103@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D3A4EBF8@il-mail07.actelis.net> <52D569E9.7030303@cisco.com> In-Reply-To: <52D569E9.7030303@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4EBFBilmail07act_" MIME-Version: 1.0 Cc: Pat Thaler , "opsawg@ietf.org" Subject: Re: [OPSAWG] Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:34:12 -0000 --_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4EBFBilmail07act_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Say the 1st draft by Feb 9th? Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, January 14, 2014 18:47 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thaler Subject: Re: Documenting the list of RFCs transitioned to the IEEE 802.3.1-= 2011 Ed, Benoit, I wouldn't call it focusing, but since I committed I would have to do it. Thanks. Any time estimation? Regards, Benoit. Thanks for reminding me. Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, January 14, 2014 18:34 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thal= er Subject: Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 Dear Ed, The OPSAWG charter says: (D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011. Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" as an reference, the following pieces of information would the foundation for the document: a table mapping the old IETF MIB names with th= e corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interact= ions (mailing lists, reviews), and clarifications on the intellectual property c= onsiderations. If I remember correctly, you committed to work on this one. With the approval of draft-ietf-opsawg-rfc5066bis-07, are you now focusing on this new= work item? Please let us know. Regards, Benoit --_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4EBFBilmail07act_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Say the 1st draft by Feb 9th?

Regards,

-E.

 

Fr= om: Benoit Claise [mailto:bclaise@cisco.com]
Sen= t: Tuesday, January 14, 2014 18:47
To: Edward Beili
Cc:= opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thaler
Subject: R= e: Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011<= /o:p>

 

=

Ed,

Benoit,

I wouldn’t call it focusing, b= ut since I committed I would have to do it.

Thanks.  Any time estimation?

Regards, = Benoit.

Thanks for reminding me.=

Regards,

-E.

&nbs= p;

Fr= om: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, January 14, 2014 1= 8:34
To: Edward Beili
Cc: opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thaler
Subject:<= /b> Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011

 

Dear Ed,

The OPSAWG charter says:

(D) Documenting the list of RFCs transitioned to the IEEE= 802.3.1-2011.
Considering RFC 4663 "Transferring MIB Work from IE= TF Bridge MIB WG to IEEE
802.1 WG" as an reference, the following = pieces of information would the
foundation for the document: a table ma= pping the old IETF MIB names with the
corresponding new IEEE ones, clar= ifications/rules on the IETF-IEEE interactions
(mailing lists, reviews)= , and clarifications on the intellectual property considerations.

If I remember corr= ectly, you committed to work on this one.
With the approval of draft-i= etf-opsawg-rfc5066bis-07, are you now focusing on this new work item?
Please let us know.

Regards, Benoit



=

 

= --_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4EBFBilmail07act_-- From dromasca@avaya.com Wed Jan 15 01:51:07 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDAD1AE013 for ; Wed, 15 Jan 2014 01:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XuRIX3Jiolt for ; Wed, 15 Jan 2014 01:51:05 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 65C271ADF88 for ; Wed, 15 Jan 2014 01:51:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocFANJY1lKHCzI1/2dsb2JhbABagkcjIThWunyBFBZ0giUBAQEBAxIbQQsQAgEGAg0EBAEBCx0HMhQJCAIEAQkEBQgah2IBDIwQkTCmOBMEjjMDAQEeLQQGAYMkgRMEjjmQUYspgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,661,1384318800"; d="scan'208,217";a="45180397" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 15 Jan 2014 04:50:53 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 15 Jan 2014 04:38:59 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0158.001; Wed, 15 Jan 2014 10:50:50 +0100 From: "Romascanu, Dan (Dan)" To: Edward Beili , Benoit Claise Thread-Topic: Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 Thread-Index: AQHPEUZrLFfr/5fK3ku3s3kmwBVd85qEWtgAgAACNICAAA07AIABH7Mw Date: Wed, 15 Jan 2014 09:50:49 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243CE84A@AZ-FFEXMB04.global.avaya.com> References: <52D566F0.5030103@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D3A4EBF8@il-mail07.actelis.net> <52D569E9.7030303@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D3A4EBFB@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4602F6D3A4EBFB@il-mail07.actelis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA243CE84AAZFFEXMB04globa_" MIME-Version: 1.0 Cc: Pat Thaler , "opsawg@ietf.org" Subject: Re: [OPSAWG] Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 09:51:07 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA243CE84AAZFFEXMB04globa_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Ed, This would be perfect, and thanks for doing this, Ed. The cut-off date for = submissions before IETF-89 is 2/14. Having an I-D before that date would al= low to send it for comments to the OPSAWG mail list. It=92s already in the = charter, but the first version should be probably an individual submission = draft-beili-opsawg-ethernet-mib-transition (or something similar) and we ca= n ask at the OPSAWG meeting in London to adopt it as WG item. In case you c= annot attend IETF-89 in London I can present on your behalf. Regards, Dan From: Edward Beili [mailto:EdwardB@actelis.com] Sent: =E9=E5=ED =E2 14 =E9=F0=E5=E0=F8 2014 19:34 To: Benoit Claise Cc: opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thaler Subject: RE: Documenting the list of RFCs transitioned to the IEEE 802.3.1-= 2011 Say the 1st draft by Feb 9th? Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, January 14, 2014 18:47 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thal= er Subject: Re: Documenting the list of RFCs transitioned to the IEEE 802.3.1-= 2011 Ed, Benoit, I wouldn=92t call it focusing, but since I committed I would have to do it. Thanks. Any time estimation? Regards, Benoit. Thanks for reminding me. Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, January 14, 2014 18:34 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thal= er Subject: Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011 Dear Ed, The OPSAWG charter says: (D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011. Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" as an reference, the following pieces of information would the foundation for the document: a table mapping the old IETF MIB names with th= e corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interact= ions (mailing lists, reviews), and clarifications on the intellectual property c= onsiderations. If I remember correctly, you committed to work on this one. With the approval of draft-ietf-opsawg-rfc5066bis-07, are you now focusing on this new= work item? Please let us know. Regards, Benoit --_000_9904FB1B0159DA42B0B887B7FA8119CA243CE84AAZFFEXMB04globa_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi Ed,<= /p>

 <= /p>

This would be perfect, an= d thanks for doing this, Ed. The cut-off date for submissions before IETF-8= 9 is 2/14. Having an I-D before that date would allow to send it for comments to the OPSAWG mail list. It=92s already in the charte= r, but the first version should be probably an individual submission draft-= beili-opsawg-ethernet-mib-transition (or something similar) and we can ask = at the OPSAWG meeting in London to adopt it as WG item. In case you cannot attend IETF-89 in London I can pre= sent on your behalf.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: Edward Beili [mailto:EdwardB@actelis.com]
Sent: =E9=E5=ED =E2 14 =E9=F0=E5=E0=F8<= /span><= /span> 2014 19:34
To: Benoit Claise
Cc: opsawg@ietf.org; Romascanu, Dan (Dan); Pat Thaler
Subject: RE: Documenting the list of RFCs transitioned to the IEEE 8= 02.3.1-2011

 

Say the 1st dr= aft by Feb 9th?

Regards,

-E.

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, January 14, 2014 18:47
To: Edward Beili
Cc: opsawg@ietf.org; Romascan= u, Dan (Dan); Pat Thaler
Subject: Re: Documenting the list of RFCs transitioned to the IEEE 8= 02.3.1-2011

 

Ed,

Benoit,=

I wouldn=92t call it focu= sing, but since I committed I would have to do it.

Thanks.  Any time estimation?

Regards, Benoit.

Thanks for reminding me.<= /span>

Regards,

-E.

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, January 14, 2014 18:34
To: Edward Beili
Cc: opsawg@ietf.org; Romascan= u, Dan (Dan); Pat Thaler
Subject: Documenting the list of RFCs transitioned to the IEEE 802.3= .1-2011

 

Dear Ed,

The OPSAWG charter says:

(D) Documenting the list of RFCs transitioned to the= IEEE 802.3.1-2011.
Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to= IEEE
802.1 WG" as an reference, the following pieces of information would t= he
foundation for the document: a table mapping the old IETF MIB names with th= e
corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interact= ions
(mailing lists, reviews), and clarifications on the intellectual property c= onsiderations.

If I remember correct= ly, you committed to work on this one.
With the approval of draft-ietf-opsawg-rfc5066bis-07, are you now focusing on this new work = item?

Please let us know.

Regards, Benoit


 

--_000_9904FB1B0159DA42B0B887B7FA8119CA243CE84AAZFFEXMB04globa_-- From james.huy.nguyen@gmail.com Wed Jan 15 13:47:40 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5341AE167 for ; Wed, 15 Jan 2014 13:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_eMFffmBMLn for ; Wed, 15 Jan 2014 13:47:37 -0800 (PST) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBC71AE197 for ; Wed, 15 Jan 2014 13:47:29 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id x13so1583223qcv.33 for ; Wed, 15 Jan 2014 13:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kSOFgAZzEGxQ5HWH4LZFqndqdttmAwKOIPHzJ5nOxtI=; b=aSsB5z6OyFimkULgtK0TYk3bdp/uQb51ZAH9aG6xKIUBrALw4aHdcCu6x/EIYkCS3z 3SjSdKSOw6wR+EczVqV0/MGRPD6rJrS4iVqU5OI+SbrQ3Yg9Gzhc+rbQGSS5ZSYf3Iab Yhty99E8sq1MKIRtIWuS7Ggl/6+Y6n04lO4q3ju+JKAts4XF4qg85RK2sWph+WC2/OEu E6dzfYXwCKTt60rCPyjNsJmpzHxOSymXbKAiesPvddXsai3milY+Mxa56E6NbRNRFoZN rJ4C0alqzG3ybyRKI/7y86FzWONFTrf3OHfIETOy2AZLHABx4zFDQWDD9EQuRxIIKKZR pdTw== MIME-Version: 1.0 X-Received: by 10.140.94.246 with SMTP id g109mr1819332qge.19.1389822437387; Wed, 15 Jan 2014 13:47:17 -0800 (PST) Received: by 10.96.131.11 with HTTP; Wed, 15 Jan 2014 13:47:17 -0800 (PST) In-Reply-To: References: Date: Wed, 15 Jan 2014 16:47:17 -0500 Message-ID: From: James Nguyen To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=001a113a81d6aeb8a304f00940fb Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 21:47:41 -0000 --001a113a81d6aeb8a304f00940fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I really enjoy reading this draft. In general, in my opinion is very useful for managing constrained devices. I have a couple of questions/suggestions: (1) Req-ID 4.3.002 Title: Capacity Discovery I don't quite understand this req. Please be more specific. (2) Section 3.3 Configuration Management Session-oriented configuration protocol may be expensive for managing a large number of similar devices. In a case when common redundant configurations is issued, reliable multicast with negative acknowledgement (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast (NORM)) would work best. I suggest to add a reliable transport requirement in this section. Moreover, a common data model would be needed. Stateless configuration update solution would also work well for constrained networks. (3) Section 3.8 Group-based provisioning As I mentioned in (2), a common data model would be required for common redundant configurations. I suggest to add this requirement here. Hope this helps. James On Mon, Jan 6, 2014 at 1:56 PM, Ersue, Mehmet (NSN - DE/Munich) < mehmet.ersue@nsn.com> wrote: > Hi Hui, > > > > thank you for your kind review. > > > > > 1. in section 3., a section of =E2=80=98IPv4/v6 address management=E2= =80=99 could be > helpful, including the discussion of different types of ip addresses on > devices, link-local, global, private, etc.. > > Concerning IPv4/v6 addresses which requirements do you have in mind from > management pov.? > > > > > 2. in Appendix A, any relevant discussion in =E2=80=98oneM2M=E2=80=99? > > I would need your help for this as I=E2=80=99m not involved in oneM2M. Th= anks. > > > > Cheers, > Mehmet > > > > *From:* OPSAWG [mailto:opsawg-bounces@ietf.org] *On Behalf Of *ext Hui > Deng > *Sent:* Monday, January 06, 2014 8:49 AM > *To:* opsawg@ietf.org > *Subject:* [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs > > > > Hi Authors, > > > > This document is very useful for service providers and operators that are > managing their constrained devices. > > > > Two cents for authors to consider, > > 1. in section 3., a section of =E2=80=98IPv4/v6 address management=E2=80= =99 could be > helpful, including the discussion of different types of ip addresses on > devices, link-local, global, private, etc.. > > 2. in Appendix A, any relevant discussion in =E2=80=98oneM2M=E2=80=99? > > > Regards, > > > > -Hui > > > > > 2014/1/4 Ersue, Mehmet (NSN - DE/Munich) > > Hi Dan, > > thank you for your review and comments. See below. > > Cheers, > Mehmet > > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of ext > Romascanu, Dan > > (Dan) > > Sent: Thursday, December 12, 2013 2:23 PM > > To: Warren Kumari; opsawg@ietf.org > > Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* > > > > Hi, > > > > I do not know if I really should be included in the reviewers count, as > I am a participant > > in the coman work since it started, and my name shows up on the list of > authors, > > although in all sincerity most of the credits go to Mehmet, who hold th= e > pen for most > > of the time, including this latest wound which split the original > document into two > > separate documents - one for use cases, the other for problem statement > and > > requirements. Anyway, FWIW I obviously believe this work is useful and = I > support > > doing it in the OPSAWG. I have a few comments recorded below: > > > > draft-ersue-opsawg-coman-use-cases > > > > 1. I do not believe that we can get away with a zero-content security > considerations > > section. The described use cases mention the need to secure information > collected by > > constrained devices, some other (like security cameras) carry > information related to > > personal or public security that needs to be protected by robust > mechanisms. These > > kind of threats need to be mentioned IMO. > > You are right a dummy security considerations section is not sufficient. > Coman was not planning to address security exhaustively. Solace, now ACE, > has > been started where security for constrained devices will be discussed. > We discussed the security requirements in section 3.6 of the problem > statement draft. > > I agree, a discussion of the security threads should be provided in a > security considerations section. > > > draft-ersue-opsawg-coman-probstate-reqs > > > > 1. The draft uses the 'adjective' small device in association with > constrained device in a > > few place. I suggest to remove this. There is no automatic association > of a device > > being small implying that it is also constrained. Nor are all > constrained devices small in > > size. > > Agree. We should be more precise with the terminology. > > > 2. We have made an effort in the last few versions and especially in > this one to > > distinguish between the constrained devices and constrained networks, > but the clean-up > > on this issue is not complete. For example section 1.6 still has text > about constrained > > networks - this section and other in which constrained networks are > mentioned should > > be carefully examined to make sure that the focus of the document stays > with > > constrained devices, and that if constrained networks are mentioned at > all this is in the > > context of their relationship with the constrained devices. > > Why strictly devices? We also have requirements discussing the > organization of constrained networks from management pov. in section 3.1. > > > 3. I do not believe that we can get away with a zero-content security > considerations > > section here either. The document even says: > > > > If specific requirements for > > security will be identified, they will be described in future > > versions of this document. > > > > This is not accurate - section 3.6 already speaks about requirments for > security and > > access control, and section 1.6 mentions limitations that would prevent > the > > implementation of strong scryptographic algorythms. The text needs to b= e > reviewed > > and revised from this perspective. > > I think the "future" is now and the current text in the security > considerations section needs to be replaced. I would suggest to provide a > security considerations section by listing and discussing threads in the > problem statement draft and refer to it from the use cases draft. > Comments? > > > > > Regards, > > > > Dan > > > > > -----Original Message----- > > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren > Kumari > > > Sent: Wednesday, December 04, 2013 6:49 PM > > > To: opsawg@ietf.org > > > Subject: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-* > > > > > > Hi all, > > > > > > Hopefully you all had a good Thanksgiving -- if you are in the US, > > > hopefully you had good turkey, stuffing / whatever. > > > If you are not US based, hopefully you enjoyed the decrease in email > > > volume while everyone recovered form eating too much. :-) > > > > > > One of the action items from Vancouver was for us to call for reviewe= rs > > > for: > > > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs/ > > > and > > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-use-cases/ > > > > > > So, can we get some volunteers please? According to our new guideline= s > > > we require sufficient reviewers before adopting new work. > > > > > > The documents are (IMO) interesting and easy to read. Constrained > > > devices have some interesting requirements and limitations. > > > If you would like a quick reminder / refresher from the meeting, slid= es > > > are here: > http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pdf > > > > > > Juergen Schoenwaelder indicate= d > > > that one of his Ph.D. students had read the draft a couple of weeks > ago. > > > So they just have to review the changes to the latest version. > > > > > > > > > W > > > -- > > > "I think it would be a good idea." > > > - Mahatma Ghandi, when asked what he thought of Western civilization > > > > > > > > > > > > _______________________________________________ > > > OPSAWG mailing list > > > OPSAWG@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > --=20 James Nguyen Email: james.huy.nguyen@gmail.com --001a113a81d6aeb8a304f00940fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I really enjoy reading this draft. = =C2=A0In general, in my opinion is very useful for managing constrained dev= ices. =C2=A0

I have a couple of questions/suggesti= ons:

(1) Req-ID 4.3.002 Title: Capacity Discovery
=
=C2=A0 =C2=A0 =C2=A0I don't quite understand this req. = =C2=A0Please be more specific.

(2) Section 3.3 Con= figuration Management

=C2=A0 =C2=A0 =C2=A0Session-oriented configuration prot= ocol may be expensive for managing a large number of similar devices. =C2= =A0In a case when common redundant configurations is issued, reliable multi= cast with negative acknowledgement (e.g. Negative ACKnowledgement (NACK)-Or= iented Reliable Multicast (NORM)) would work best. =C2=A0I suggest to add a= reliable transport requirement in this section. =C2=A0Moreover, a common d= ata model would be needed. =C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0 =C2=A0Stateless configuration update solu= tion would also work well for constrained networks.

(3) Section 3.8 Group-based provisioning

=C2=A0 = =C2=A0 =C2=A0As I mentioned in (2), a common data model would be required f= or common redundant configurations. =C2=A0I suggest to add this requirement= here.

Hope this helps.

James

=C2=A0 =C2=A0 =C2=A0


<= /div>


On Mon, = Jan 6, 2014 at 1:56 PM, Ersue, Mehmet (NSN - DE/Munich) &= lt;mehmet.ersue@n= sn.com> wrote:

Hi Hui,=

=C2=A0<= /p>

thank you for your kind revi= ew.

=C2=A0<= /p>

> 1. in section 3., a = section of =E2=80=98IPv4/v6 address management=E2=80=99 could be helpful, i= ncluding the discussion of different types of ip addresses on devices, link= -local, global, private, etc..

Concerning IPv4/v6 add= resses which requirements do you have in mind from management pov.?<= u>

=C2=A0

> 2. in Appendix A, an= y relevant discussion in =E2=80=98oneM2M=E2=80=99?

I would need your help= for this as I=E2=80=99m not involved in oneM2M. Thanks.

=C2=A0<= /p>

Cheers,
Mehmet

=C2=A0<= /p>

From: OPSAWG [= mailto:opsawg-= bounces@ietf.org] On Behalf Of ext Hui Deng
Sent: Monday, January 06, 2014 8:49 AM
To: opsawg@ietf= .org
Subject: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-req= s

=C2=A0

Hi Authors,

=C2=A0

This document is very use= ful for service providers and operators that are managing their constrained= devices.

=C2=A0

Two cents for authors to = consider,

1. in section 3., a secti= on of =E2=80=98IPv4/v6 address management=E2=80=99 could be helpful, includ= ing the discussion of different types of ip addresses on devices, link-loca= l, global, private, etc..

2. in Appendix A, any rel= evant discussion in =E2=80=98oneM2M=E2=80=99?


Regards,

=C2=A0

-Hui


=C2=A0

2014/1/4 Ersue, Mehmet (NSN - DE/Munich) <mehmet.ersue@nsn.com= >

Hi Dan,

thank you for your review and comments. See below.

Cheers,
Mehmet

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of ext Romascanu, Dan > (Dan)
> Sent: Thursday, December 12, 2013 2:23 PM
> To: Warren Kumari; opsawg@ietf.org
> Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*=
>
> Hi,
>
> I do not know if I really should be included in the reviewers count, a= s I am a participant
> in the coman work since it started, and my name shows up on the list o= f authors,
> although in all sincerity most of the credits go to Mehmet, who hold t= he pen for most
> of the time, including this latest wound which split the original docu= ment into two
> separate documents - one for use cases, the other for problem statemen= t and
> requirements. Anyway, FWIW I obviously believe this work is useful and= I support
> doing it in the OPSAWG. I have a few comments recorded below:
>
> =C2=A0draft-ersue-opsawg-coman-use-cases
>
> 1. I do not believe that we can get away with a zero-content security = considerations
> section. The described use cases mention the need to secure informatio= n collected by
> constrained devices, some other (like security cameras) carry informat= ion related to
> personal or public security that needs to be protected by robust mecha= nisms. These
> kind of threats need to be mentioned IMO.

You are right a dummy security considerations section is not sufficient. Coman was not planning to address security exhaustively. Solace, now ACE, h= as
been started where security for constrained devices will be discussed.
We discussed the security requirements in section 3.6 of the problem statem= ent draft.

I agree, a discussion of the security threads should be provided in a secur= ity considerations section.

> draft-ersue-opsawg-coman-probstate-reqs
>
> 1. The draft uses the 'adjective' small device in association = with constrained device in a
> few place. I suggest to remove this. There is no automatic association= of a device
> being small implying that it is also constrained. Nor are all constrai= ned devices small in
> size.

Agree. We should be more precise with the terminology.

> 2. We have made an effort in the last few versions and especially in t= his one to
> distinguish between the constrained devices and constrained networks, = but the clean-up
> on this issue is not complete. For example section 1.6 still has text = about constrained
> networks - this section and other in which constrained networks are me= ntioned should
> be carefully examined to make sure that the focus of the document stay= s with
> constrained devices, and that if constrained networks are mentioned at= all this is in the
> context of their relationship with the constrained devices.

Why strictly devices? We also have requirements discussing the organization= of constrained networks from management pov. in section 3.1.

> 3. I do not believe that we can get away with a zero-content security = considerations
> section here either. The document even says:
>
> =C2=A0 =C2=A0If specific requirements for
> =C2=A0 =C2=A0security will be identified, they will be described in fu= ture
> =C2=A0 =C2=A0versions of this document.
>
> This is not accurate - section 3.6 already speaks about requirments fo= r security and
> access control, and section 1.6 mentions limitations that would preven= t the
> implementation of strong scryptographic algorythms. The text needs to = be reviewed
> and revised from this perspective.

I think the "future" is now and the current text in the security = considerations section needs to be replaced. I would suggest to provide a s= ecurity considerations section by listing and discussing threads in the pro= blem statement draft and refer to it from the use cases draft.
Comments?

>
> Regards,
>
> Dan
>
> > -----Original Message-----
> > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari > > Sent: Wednesday, December 04, 2013 6:49 PM
> > To: opsawg@i= etf.org
> > Subject: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-= *
> >
> > Hi all,
> >
> > Hopefully you all had a good Thanksgiving -- if you are in the US= ,
> > hopefully you had good turkey, stuffing / whatever.
> > If you are not US based, hopefully you enjoyed the decrease in em= ail
> > volume while everyone recovered form eating too much. :-)
> >
> > One of the action items from Vancouver was for us to call for rev= iewers
> > for:
> > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs/
> > and
> > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-use-cases/
> >
> > So, can we get some volunteers please? According to our new guide= lines
> > we require sufficient reviewers before adopting new work.
> >
> > The documents are (IMO) interesting and easy to read. Constrained=
> > devices have some interesting requirements and limitations.
> > If you would like a quick reminder / refresher from the meeting, = slides
> > are here: http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pdf
> >
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > indicated
> > that one of his Ph.D. students had read the draft a couple of wee= ks ago.
> > So they just have to review the changes to the latest version. > >
> >
> > W
> > --
> > "I think it would be a good idea."
> > - Mahatma Ghandi, when asked what he thought of Western civilizat= ion
> >
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.= org
> > https://www.ietf.org/mailman/listinfo/opsawg
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org = https://www.ietf.org/mailman/listinfo/opsawg

=C2=A0


_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg




--
James Ng= uyen
Email: james.huy.nguy= en@gmail.com
--001a113a81d6aeb8a304f00940fb-- From internet-drafts@ietf.org Wed Jan 15 14:10:59 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B14C1AE42C; Wed, 15 Jan 2014 14:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxrdx0A6H5zm; Wed, 15 Jan 2014 14:10:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D54741AE237; Wed, 15 Jan 2014 14:10:57 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140115221057.23049.16882.idtracker@ietfa.amsl.com> Date: Wed, 15 Jan 2014 14:10:57 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-large-flow-load-balancing-07.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 22:10:59 -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 Working Gr= oup Working Group of the IETF. Title : Mechanisms for Optimal LAG/ECMP Component Link Ut= ilization in Networks Authors : Ram Krishnan Lucy Yong Anoop Ghanwani Ning So Bhumip Khasnabish Filename : draft-ietf-opsawg-large-flow-load-balancing-07.txt Pages : 23 Date : 2014-01-15 Abstract: Demands on networking infrastructure are growing exponentially due to bandwidth hungry applications such as rich media applications and inter-data center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal cost multi-paths as techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancin= g/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-large-flow-load-balanc= ing-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ramk@Brocade.com Wed Jan 15 16:31:21 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64DA1AE425 for ; Wed, 15 Jan 2014 16:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNFxjI23_9mU for ; Wed, 15 Jan 2014 16:31:19 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD011AE145 for ; Wed, 15 Jan 2014 16:31:19 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s0G0GHdg006945; Wed, 15 Jan 2014 16:31:05 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1hdpap8j18-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Jan 2014 16:31:05 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 15 Jan 2014 16:31:04 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 15 Jan 2014 16:31:03 -0800 From: ramki Krishnan To: Warren Kumari Date: Wed, 15 Jan 2014 16:31:01 -0800 Thread-Topic: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new version needed to address the IETF LC comments Thread-Index: Ac8QmFhwrgKkkCV7SoCIPlAxKPlisQBuQrpA Message-ID: References: <52A9D813.3060701@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-15_07:2014-01-15,2014-01-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401150179 Cc: Pete Moyer , "opsawg@ietf.org" , "draft-ietf-opsawg-large-flow-load-balancing@tools.ietf.org" , Wesley George Subject: Re: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new version needed to address the IETF LC comments X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 00:31:22 -0000 Hi Warren, We have addressed Pete's comments, nits and the author overload. Latest dra= ft below. https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancin= g/ Thanks, Ramki on behalf of the co-authors -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net]=20 Sent: Monday, January 13, 2014 11:48 AM To: ramki Krishnan Cc: Benoit Claise; draft-ietf-opsawg-large-flow-load-balancing@tools.ietf.o= rg; opsawg@ietf.org; Wesley George Subject: Re: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new vers= ion needed to address the IETF LC comments On Thu, Dec 26, 2013 at 2:16 PM, ramki Krishnan wrote: > Dear Benoit, > > > > The last call comments and your comments are addressed in the latest=20 > version of the draft. > I think that you missed Pete's comments in http://www.ietf.org/mail-archive= /web/opsawg/current/msg02881.html In addition to his note that "last part of that sentence needs clarificatio= n" it also has a typo ("distribution at with multi-node" - extra 'at'?) I *think* that you captured all of Benoit's comments, but will leave it to = him to confirm. I think that you also cover Wes' comments from http://www.ietf.org/mail-arc= hive/web/opsawg/current/msg02916.html, in section 5.6.2, but it wouldn't hu= rt to check with him (CCed). The nits checker still complains that it cannot find the publication date, = presumably because there are 6 authors. The RFC Editor policy (at http://www.rfc-editor.org/policy.html ) says: "There is no rigid limit on the size of this set, but there is likely to be= a discussion if the set exceeds five authors, in which case the right answ= er is probably to list one editor." You can duke it out with RFC Ed, but personally I'd suggest just reading th= e "Author Overload" section and implementing one of the options. W > > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-bal > ancing/ > > > > Thanks, > > Ramki > > > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit=20 > Claise > Sent: Thursday, December 12, 2013 5:37 AM > To: draft-ietf-opsawg-large-flow-load-balancing@tools.ietf.org > Cc: opsawg@ietf.org > Subject: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new=20 > version needed to address the IETF LC comments > > > > Dear draft-ietf-opsawg-large-flow-load-balancing authors, > > I started to AD review of draft-ietf-opsawg-large-flow-load-balancing=20 > (Sorry for the delay btw). > Then I reviewed the WG LC feedback (email from Melinda, "[OPSAWG] WG=20 > last call for "Mechanisms for Optimal LAG/ECMP Component Link=20 > Utilization in Networks", on August 24th), and I realized that I have=20 > the same feedback as Dan Romascanu in=20 > http://www.ietf.org/mail-archive/web/opsawg/current/msg02891.html > > Then I reviewed all the WGLC feedback, and it appears that this=20 > document was sent on my plate, while the most up to date draft version=20 > 5 still doesn't address the WGLC feedback. > For example: > http://www.ietf.org/mail-archive/web/opsawg/current/msg02897.html > > "It refers to all of them, i.e. LAG, ECMP, and even the (hierarchical)=20 > combination. We can try and provide some clarification around that. =20 > We will add 802.1AX as a reference for LAG." > > Please post a revised version that addresses the WGLC comments. > > While you are at it (and since I reviewed 1/3 of the document), here=20 > is part of my feedback. > I'll restart my AD review with the next version > > Regards, Benoit > > =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=3D=3D=3D=3D=3D > > - You use the term flow is a lot. Your definition is in line with the=20 > Flow definition in RFC 7011 (IPFIX). > > Why not reuse it? > > Even your specific flow definition could re use the same "Flow"=20 > definition from RFC 7011 > > > > Large Flow(s): long-lived large Flow(s) > > > > Small Flow(s): long-lived small Flow(s) and short-lived small/large > Flow(s) > > > > - How many flow categories do you want to stress? > > 1. Introduction: > > Network traffic can be predominantly categorized into two traffic > > types: long-lived large flows and other flows (which include long- > > lived small flows, short-lived small/large flows) > > 1.2. Terminology > > Large flow(s): long-lived large flow(s) > > Small flow(s): long-lived small flow(s) and short-lived small/large > > flow(s) > > 2. Flow Categorization > > In general, based on the size and duration, a flow can be categorized > > into any one of the following four types, as shown in Figure 1: > > (a) Short-Lived Large Flow (SLLF), > > (b) Short-Lived Small Flow (SLSF), > > (c) Long-Lived Large Flow (LLLF), and > > (d) Long-Lived Small Flow (LLSF). > > > > Please be consistent. This is slightly confusing. > > This only makes sense with the sentence at the end of section 2. > > In this document, we categorize Long-lived large flow(s) as "Large" > > flow(s), and all of the others -- Long-lived small flow(s) and=20 > short- > > lived small/large flow(s) as "Small" flow(s). > > > > Proposal (to make it clear earlier in document): > > OLD: > > Network traffic can be predominantly categorized into two traffic > > types: long-lived large flows and other flows (which include long- > > lived small flows, short-lived small/large flows) > > > > NEW: > > Network traffic can be predominantly categorized into two traffic > > types: long-lived large flows and other flows. These other flow, > > which include long-lived small flows and short-lived small/large=20 > flows, > > are considered as small flows in this document. > > > > > > > > EDITORIAL > > - > > Please expand LAG/ECMP in the abstract. While ECMP is known, LAG is not. > > > > - > > (load/mix and comma) > > OLD: > > If the traffic load constitutes flows such that the result of the > > hash function across these flows is fairly uniform so that a=20 > similar > > number of flows is mapped to each component link, if, the=20 > individual > > flow rates are much smaller as compared to the link capacity, > > NEW: > > If the traffic mix constitutes flows such that the result of the > > hash function across these flows is fairly uniform so that a=20 > similar > > number of flows is mapped to each component link, if the individual > > flow rates are much smaller as compared to the link capacity, > > > > - > > EDITORIAL > > OLD: > > Where: ->-> small flows > > =3D=3D=3D> large flow > > > > NEW: > > Where: -> small flow > > =3D=3D=3D> large flow > > > > Alternatively, make it clear in the figure that "-> -> ->" means 3=20 > small flows, by having each flow on a new line. > > > > In the same figure, what does "--/---/-" mean? > > > > - > > To demonstrate the limitations of local optimization, consider a=20 > two- > > level fat-tree topology with three leaf nodes (L1, L2, L3) and two > > spine nodes (S1, S2) and assume all of the links are 10 Gbps. Let=20 > L1 > > have two flows of 4 Gbps each towards L3, and let L2 have one flow=20 > of > > 7 Gbps also towards L3. If L1 balances the load optimally between=20 > S1 > > and S2, and L2 sends the flow via S1, then the downlink from S1 to=20 > L3 > > would get congested resulting in packet discards. On the other=20 > hand, > > if L1 had sent both its flows towards S1 and L2 had sent its flow > > towards S2, there would have been no congestion at either S1 or S2. > > > > A figure would be appreciated. > > > > - as a courtesy for the RFC editors, please order the references > > > > - idnits complains about the date. > > > > - RFC 5101 -> RFC 7011 > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From j.schoenwaelder@jacobs-university.de Wed Jan 15 23:37:53 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FFB1AE2E4 for ; Wed, 15 Jan 2014 23:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfvHlPKNTC4D for ; Wed, 15 Jan 2014 23:37:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 327451ADBCD for ; Wed, 15 Jan 2014 23:37:51 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D37E220048; Thu, 16 Jan 2014 08:37:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id D2lg95NBqsvs; Thu, 16 Jan 2014 08:37:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23EB120031; Thu, 16 Jan 2014 08:37:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 14DB02AA6572; Thu, 16 Jan 2014 08:37:34 +0100 (CET) Date: Thu, 16 Jan 2014 08:37:34 +0100 From: Juergen Schoenwaelder To: James Nguyen Message-ID: <20140116073734.GA1160@elstar.local> Mail-Followup-To: James Nguyen , "Ersue, Mehmet (NSN - DE/Munich)" , "opsawg@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 07:37:54 -0000 On Wed, Jan 15, 2014 at 04:47:17PM -0500, James Nguyen wrote: > Hi, > > I really enjoy reading this draft. In general, in my opinion is very > useful for managing constrained devices. > > I have a couple of questions/suggestions: > > (1) Req-ID 4.3.002 Title: Capacity Discovery > > I don't quite understand this req. Please be more specific. Here is the text (it is _capability_ not _capacity_ discovery): Req-ID: 4.3.002 Title: Capability Discovery Description: Enable the discovery of supported optional management capabilities of a device and their exposure via at least one protocol and/or data model. Devices may have different levels of management support. This requirement says that it should be possible to discover any optional management capabilities. What is unclear here? How can we improve it? > (2) Section 3.3 Configuration Management > > Session-oriented configuration protocol may be expensive for managing > a large number of similar devices. In a case when common redundant > configurations is issued, reliable multicast with negative acknowledgement > (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast (NORM)) > would work best. I suggest to add a reliable transport requirement in this > section. Moreover, a common data model would be needed. > > Stateless configuration update solution would also work well for > constrained networks. My assumption is that reliable multicast protocols are not simple and bring their own can of worms. Can you point to prototype systems that do successfully use reliable multicast to configure constrained devices? Can you also elaborate what "stateless configuration update solution" means to you? > (3) Section 3.8 Group-based provisioning > > As I mentioned in (2), a common data model would be required for > common redundant configurations. I suggest to add this requirement here. Yes, perhaps we have to say something explicit about this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From james.huy.nguyen@gmail.com Thu Jan 16 06:38:44 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C9B1AE36F for ; Thu, 16 Jan 2014 06:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAqCeHWf9Bmv for ; Thu, 16 Jan 2014 06:38:42 -0800 (PST) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8134F1AE0E5 for ; Thu, 16 Jan 2014 06:38:42 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id w5so2188994qac.31 for ; Thu, 16 Jan 2014 06:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0J5pOF3FCNlRbar/kgGOGDnwp0hpPUCMmu8KZH16UM0=; b=yPTWB+C01EPGn25fbrh3Gzda11dW4TZdwIHzwT9B7vJ+e/1qsh/4pkxRWijffZTrvF YxyjjUhX0xuKeHsIZbS8DU3PxUPCkYUMKBoC5gIentUWhTUn6Pm8hl21ZooVP2dL/wjC hbZTFBb3ChVq/62s5SS0s/oMFKFpjtU3Fgzk2tODmyrJhjAwPUxdVnxDXY/2w6JcQDs5 KL5tt/Uzvf/poWB7rea4Gc7bzkkJf4GODERd1tjxHzFue4lSlcUSOvp6H2xphQ7aMaCc Dm856skMy5ShNvoHVODF74WNB3X/v9tRFBTWOjjjyIXk8kWREq7+RtmpddoIKDhLpm9T zzRw== MIME-Version: 1.0 X-Received: by 10.140.82.50 with SMTP id g47mr8572655qgd.99.1389883110274; Thu, 16 Jan 2014 06:38:30 -0800 (PST) Received: by 10.96.131.11 with HTTP; Thu, 16 Jan 2014 06:38:30 -0800 (PST) In-Reply-To: <20140116073734.GA1160@elstar.local> References: <20140116073734.GA1160@elstar.local> Date: Thu, 16 Jan 2014 09:38:30 -0500 Message-ID: From: James Nguyen To: Juergen Schoenwaelder Content-Type: text/plain; charset=UTF-8 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 14:38:44 -0000 Sent from my iPad >> On Jan 16, 2014, at 2:37 AM, Juergen Schoenwaelder wrote: >> >> On Wed, Jan 15, 2014 at 04:47:17PM -0500, James Nguyen wrote: >> Hi, >> >> I really enjoy reading this draft. In general, in my opinion is very >> useful for managing constrained devices. >> >> I have a couple of questions/suggestions: >> >> (1) Req-ID 4.3.002 Title: Capacity Discovery >> >> I don't quite understand this req. Please be more specific. > > Here is the text (it is _capability_ not _capacity_ discovery): > > Req-ID: 4.3.002 > > Title: Capability Discovery > > Description: Enable the discovery of supported optional management > capabilities of a device and their exposure via at least one > protocol and/or data model. > > Devices may have different levels of management support. This > requirement says that it should be possible to discover any optional > management capabilities. What is unclear here? How can we improve it? It's clear to me now. Thx. > >> (2) Section 3.3 Configuration Management >> >> Session-oriented configuration protocol may be expensive for managing >> a large number of similar devices. In a case when common redundant >> configurations is issued, reliable multicast with negative acknowledgement >> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast (NORM)) >> would work best. I suggest to add a reliable transport requirement in this >> section. Moreover, a common data model would be needed. >> >> Stateless configuration update solution would also work well for >> constrained networks. > > My assumption is that reliable multicast protocols are not simple and > bring their own can of worms. Can you point to prototype systems that > do successfully use reliable multicast to configure constrained > devices? I certainly can list a couple of scenarios: I assume that military radios could be categorized as constrained devices as they're often on the move and operated in unreliable networks with lossy links and/or highly disrupted environment. Military radios or military devices seem to fit the definitions that are listed in Section 1.6. (1) In military theater or emergency disaster incident, a group of soldiers or a group of search-and-rescuers need to switch frequency of their radios to join other group's communication network. (2) In battlefield, soldiers' need to be zero-outed (of configurations) to prevent these radios/comms devices to fall in enemies' hands. > > Can you also elaborate what "stateless configuration update solution" > means to you? I meant stateless configuration management. > >> (3) Section 3.8 Group-based provisioning >> >> As I mentioned in (2), a common data model would be required for >> common redundant configurations. I suggest to add this requirement here. > > Yes, perhaps we have to say something explicit about this. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Jan 16 07:29:31 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1DA1AE394 for ; Thu, 16 Jan 2014 07:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaUhJhyJ-2-Y for ; Thu, 16 Jan 2014 07:29:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCA11AE393 for ; Thu, 16 Jan 2014 07:29:29 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFD2220066; Thu, 16 Jan 2014 16:29:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cynmNqt9PMNT; Thu, 16 Jan 2014 16:29:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5B452004D; Thu, 16 Jan 2014 16:29:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C7F722AA8145; Thu, 16 Jan 2014 16:29:13 +0100 (CET) Date: Thu, 16 Jan 2014 16:29:13 +0100 From: Juergen Schoenwaelder To: James Nguyen Message-ID: <20140116152913.GA2658@elstar.local> Mail-Followup-To: James Nguyen , "Ersue, Mehmet (NSN - DE/Munich)" , "opsawg@ietf.org" References: <20140116073734.GA1160@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 15:29:31 -0000 On Thu, Jan 16, 2014 at 09:38:30AM -0500, James Nguyen wrote: > > > >> (2) Section 3.3 Configuration Management > >> > >> Session-oriented configuration protocol may be expensive for managing > >> a large number of similar devices. In a case when common redundant > >> configurations is issued, reliable multicast with negative acknowledgement > >> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast (NORM)) > >> would work best. I suggest to add a reliable transport requirement in this > >> section. Moreover, a common data model would be needed. > >> > >> Stateless configuration update solution would also work well for > >> constrained networks. > > > > My assumption is that reliable multicast protocols are not simple and > > bring their own can of worms. Can you point to prototype systems that > > do successfully use reliable multicast to configure constrained > > devices? > > I certainly can list a couple of scenarios: > > I assume that military radios could be categorized as constrained > devices as they're often on the move and operated in unreliable > networks with lossy links and/or highly disrupted environment. > Military radios or military devices seem to fit the definitions that > are listed in Section 1.6. > > (1) In military theater or emergency disaster incident, a group of > soldiers or a group of search-and-rescuers need to switch frequency of > their radios to join other group's communication network. > > (2) In battlefield, soldiers' need to be zero-outed (of > configurations) to prevent these radios/comms devices to fall in > enemies' hands. Luckily, I am not familiar with any of this. But my concern remains and in such scenarios, I would have serious trouble to define what 'reliable' means given that the group membership is open ended. > > Can you also elaborate what "stateless configuration update solution" > > means to you? > > I meant stateless configuration management. > And that means what to you? What is 'stateless'? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From james.huy.nguyen@gmail.com Thu Jan 16 07:50:48 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7681AE37E for ; Thu, 16 Jan 2014 07:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eX9sTxKobhA for ; Thu, 16 Jan 2014 07:50:46 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC6D1AE399 for ; Thu, 16 Jan 2014 07:50:46 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id c9so2468351qcz.31 for ; Thu, 16 Jan 2014 07:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jdIpoabIjVwVM6sVBCb7ZSwrMGR2xwYCzl62uZXioJk=; b=BG5EjNifbrDRqq/Yp+RnUREi+ZmNCObDqhfGcaSwNiuu7DYPCEx3O6cjFUu5DEpZbE CbuXooH7HxsTADr9eQ5xT3HOt/Rk3jW9T95+ySKhsRnP/tinoumGeXYDd1nbxaf/31Sp 2wK2yq4fDL4L3hvjRUERKcUsPjgTx56SoHqFuNu80zPjgg2YrmgXvxTecIeQBbOPaHvh Liz96d3GluziksU8b47mI9inwFOJ5C4EU/+AKX/7xaurQ/ZqM6X+9Jsdcoru7344gDTk yzi90T3fXD0QXdKtb3PPP/Fya8dpX5LJ0eEkPfNB4Z1AS+/j4hD/Hv2D4pw9EEXZR4To nTtQ== MIME-Version: 1.0 X-Received: by 10.140.28.134 with SMTP id 6mr9115683qgz.50.1389887434182; Thu, 16 Jan 2014 07:50:34 -0800 (PST) Received: by 10.96.131.11 with HTTP; Thu, 16 Jan 2014 07:50:34 -0800 (PST) In-Reply-To: <20140116152913.GA2658@elstar.local> References: <20140116073734.GA1160@elstar.local> <20140116152913.GA2658@elstar.local> Date: Thu, 16 Jan 2014 10:50:34 -0500 Message-ID: From: James Nguyen To: Juergen Schoenwaelder , James Nguyen , "Ersue, Mehmet (NSN - DE/Munich)" , "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=001a1139ae7acaeef204f01862da Subject: Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 15:50:48 -0000 --001a1139ae7acaeef204f01862da Content-Type: text/plain; charset=UTF-8 On Thu, Jan 16, 2014 at 10:29 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jan 16, 2014 at 09:38:30AM -0500, James Nguyen wrote: > > > > > >> (2) Section 3.3 Configuration Management > > >> > > >> Session-oriented configuration protocol may be expensive for > managing > > >> a large number of similar devices. In a case when common redundant > > >> configurations is issued, reliable multicast with negative > acknowledgement > > >> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast > (NORM)) > > >> would work best. I suggest to add a reliable transport requirement > in this > > >> section. Moreover, a common data model would be needed. > > >> > > >> Stateless configuration update solution would also work well for > > >> constrained networks. > > > > > > My assumption is that reliable multicast protocols are not simple and > > > bring their own can of worms. Can you point to prototype systems that > > > do successfully use reliable multicast to configure constrained > > > devices? > > > > I certainly can list a couple of scenarios: > > > > I assume that military radios could be categorized as constrained > > devices as they're often on the move and operated in unreliable > > networks with lossy links and/or highly disrupted environment. > > Military radios or military devices seem to fit the definitions that > > are listed in Section 1.6. > > > > (1) In military theater or emergency disaster incident, a group of > > soldiers or a group of search-and-rescuers need to switch frequency of > > their radios to join other group's communication network. > > > > (2) In battlefield, soldiers' need to be zero-outed (of > > configurations) to prevent these radios/comms devices to fall in > > enemies' hands. > > Luckily, I am not familiar with any of this. But my concern remains > and in such scenarios, I would have serious trouble to define what > 'reliable' means given that the group membership is open ended. > I see that Req-ID 4.10.003 is about best-effort multicast. Would "best-effort" be good enough instead of reliable? We can assume that developers have an option of how to implement. > > > > Can you also elaborate what "stateless configuration update solution" > > > means to you? > > > > I meant stateless configuration management. > > > > And that means what to you? What is 'stateless'? > > Let's take NETCONF as an example of stateful management protocol that requires many message exchanges. This might be inefficient in constrained networks. A less chatty management protocol fits better in this case. > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- James Nguyen Email: james.huy.nguyen@gmail.com --001a1139ae7acaeef204f01862da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 16, 2014 at 10:29 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On T= hu, Jan 16, 2014 at 09:38:30AM -0500, James Nguyen wrote:
> >
> >> (2) Section 3.3 Configuration Management
> >>
> >> =C2=A0 =C2=A0 Session-oriented configuration protocol may be = expensive for managing
> >> a large number of similar devices. =C2=A0In a case when commo= n redundant
> >> configurations is issued, reliable multicast with negative ac= knowledgement
> >> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multi= cast (NORM))
> >> would work best. =C2=A0I suggest to add a reliable transport = requirement in this
> >> section. =C2=A0Moreover, a common data model would be needed.=
> >>
> >> =C2=A0 =C2=A0 Stateless configuration update solution would a= lso work well for
> >> constrained networks.
> >
> > My assumption is that reliable multicast protocols are not simple= and
> > bring their own can of worms. Can you point to prototype systems = that
> > do successfully use reliable multicast to configure constrained > > devices?
>
> I certainly can list a couple of scenarios:
>
> I assume that military radios could be categorized as constrained
> devices as they're often on the move and operated in unreliable > networks with lossy links and/or highly disrupted environment.
> Military radios or military devices seem to fit the definitions that > are listed in Section 1.6.
>
> (1) In military theater or emergency disaster incident, a group of
> soldiers or a group of search-and-rescuers need to switch frequency of=
> their radios to join other group's communication network.
>
> (2) In battlefield, soldiers' need to be zero-outed (of
> configurations) to prevent these radios/comms devices to fall in
> enemies' hands.

Luckily, I am not familiar with any of this. But my concern rem= ains
and in such scenarios, I would have serious trouble to define what
'reliable' means given that the group membership is open ended.
=

I see that Req-ID 4.10.003 is about best-e= ffort multicast. =C2=A0Would "best-effort" be good enough instead= of reliable? =C2=A0We can assume that developers have an option of how to = implement. =C2=A0
=C2=A0

> > Can you also elaborate what "stateless configuration update = solution"
> > means to you?
>
> I meant stateless configuration management.
>

And that means what to you? What is 'stateless'?

<= br>
Let's take NETCONF as an example of stateful management p= rotocol that requires many message exchanges. =C2=A0This might be inefficie= nt in constrained networks. =C2=A0A less chatty management protocol fits be= tter in this case.
=C2=A0
/js

--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49= 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Bremen, = Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-university.de/= >



--
= James Nguyen
Email: james.= huy.nguyen@gmail.com
--001a1139ae7acaeef204f01862da-- From andy@yumaworks.com Thu Jan 16 08:39:26 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB6C1AE3B2 for ; Thu, 16 Jan 2014 08:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voGeyODkKOJy for ; Thu, 16 Jan 2014 08:39:23 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id BA65B1AE39A for ; Thu, 16 Jan 2014 08:39:23 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id c9so2472411qcz.41 for ; Thu, 16 Jan 2014 08:39:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=D+aBCKj5CY5orZRbE1XYiPT2PcqmkkQnaG/gswZzPMY=; b=PdmYFUk7arl929/iVG97ib7BZecn3TVkx2CdxokhAgsWvANLhMeTdbJzXR5z8+jKGc iDndnzAMucKQQdCkPX2p4Mxr0ff6kc/ntA288ELsOB5lfCZEPeEUMvI00sBODl3c77F5 Pht7rAv1BxHSdBZRGmnNZCtKbR2mpB7UGi3jQcuJq4J1yifXTY2dm5FjTcYdU9yli0pw qKaaGsl1u1MAOdQ8X+DZuIcl2BV/xNnbWVBaWBk+/VzHjh211uCiO8EqVfIRIXCac8s9 gY+Wjdi3ttD8GeStfY1bMwa2Pc3UdI/pBfu5bA1yo81wrfbE3f5006KCV7VoseD/8BqH wldQ== X-Gm-Message-State: ALoCoQmqNXgJcQw3j4ryrqYvZSs/cBp9RJ/ZyIa85uXyqgPOfgWmIN0qr9FegGbIh+HsUYz11Gc5 MIME-Version: 1.0 X-Received: by 10.140.92.65 with SMTP id a59mr9497704qge.34.1389890351168; Thu, 16 Jan 2014 08:39:11 -0800 (PST) Received: by 10.140.48.75 with HTTP; Thu, 16 Jan 2014 08:39:11 -0800 (PST) In-Reply-To: <20140116152913.GA2658@elstar.local> References: <20140116073734.GA1160@elstar.local> <20140116152913.GA2658@elstar.local> Date: Thu, 16 Jan 2014 08:39:11 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , James Nguyen , "Ersue, Mehmet (NSN - DE/Munich)" , "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=001a113ab29ea9079704f019108d Subject: Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 16:39:26 -0000 --001a113ab29ea9079704f019108d Content-Type: text/plain; charset=ISO-8859-1 Hi, On Thu, Jan 16, 2014 at 7:29 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jan 16, 2014 at 09:38:30AM -0500, James Nguyen wrote: > > > > > >> (2) Section 3.3 Configuration Management > > >> > > >> Session-oriented configuration protocol may be expensive for > managing > > >> a large number of similar devices. In a case when common redundant > > >> configurations is issued, reliable multicast with negative > acknowledgement > > >> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast > (NORM)) > > >> would work best. I suggest to add a reliable transport requirement > in this > > >> section. Moreover, a common data model would be needed. > > >> > > >> Stateless configuration update solution would also work well for > > >> constrained networks. > > > > > > My assumption is that reliable multicast protocols are not simple and > > > bring their own can of worms. Can you point to prototype systems that > > > do successfully use reliable multicast to configure constrained > > > devices? > > > > I certainly can list a couple of scenarios: > > > > I assume that military radios could be categorized as constrained > > devices as they're often on the move and operated in unreliable > > networks with lossy links and/or highly disrupted environment. > > Military radios or military devices seem to fit the definitions that > > are listed in Section 1.6. > > > > (1) In military theater or emergency disaster incident, a group of > > soldiers or a group of search-and-rescuers need to switch frequency of > > their radios to join other group's communication network. > > > > (2) In battlefield, soldiers' need to be zero-outed (of > > configurations) to prevent these radios/comms devices to fall in > > enemies' hands. > > Luckily, I am not familiar with any of this. But my concern remains > and in such scenarios, I would have serious trouble to define what > 'reliable' means given that the group membership is open ended. > > > > Can you also elaborate what "stateless configuration update solution" > > > means to you? > > > > I meant stateless configuration management. > > > > And that means what to you? What is 'stateless'? > Perhaps state-less means 1 session-less request/response pair instead of establishing a session, performing a sequence of request/response pairs, and then closing the session. > /js > > Andy --001a113ab29ea9079704f019108d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

 

1.3. The OAM toolsets

 

   This memo provides an overview of the different s= ets of OAM

   mecha= nisms defined by the IETF. It is intended for those with little<= /p>

   or no familiarity with the = described mechanisms. The set of OAM

   mechanisms described in this memo are applicable to IP= unicast, MPLS,

   = pseudowires, and MPLS for the transport environment (MPLS-TP). While

   OAM mechanisms that ar= e applicable to other technologies exist, they

 

 

Mizrahi, et al.   &nb= sp;     Expires July 9, 2013           &= nbsp;      [Page 4]

Internet-Draft       Overview of OAM Mechanisms  =         January 2013

 

&nbs= p;

   are beyond the sco= pe of this memo. This document focuses on IETF

   documents that have been published as RFCs, = while other ongoing OAM-

&nbs= p;  related work is outside the scope.

 

  =  The IETF has defined OAM protocols and mechanisms in several

   different fronts:

 

   o IP Ping and Traceroute:

      Ping is a very simple and = common application for failure diagnosis

 

TOM: I am not sure the term "common" is necessary.<= /o:p>

[TM] Removed.

 <= /p>

<= p class=3DMsoNormal>      that uses ICMP Echo requests, as d= efined in [ICMPv4], and

 = ;     [ICMPv6].

&nb= sp;     Traceroute ([TCPIP-Tools], [NetTools]) is an application = that

      all= ows users to trace the path between an IP source and an IP

      destination, i.e., to id= entify the nodes along the path.

 

   o BFD= :

      Bidire= ctional Forwarding Detection (BFD) is defined in [BFD] as a

<= /div>

      framework for a lightwe= ight generic OAM mechanism.  The intention

      is to define a base mechanism that = can be used with various

&nbs= p;     encapsulation types, network environments, and in various = medium

      t= ypes.

 

   o MPLS OAM:

=

      MPLS LSP Ping, as defined in= [MPLS-OAM], [MPLS-OAM-FW] and [LSP-

      Ping], is an OAM mechanism for point to point = MPLS LSPs. It

    &= nbsp; includes two main functions: Ping and Traceroute.

 

   o MPLS-TP OAM:

      MPLS-TP OAM is defined in a set of RFCs. The OAM r= equirements for

   =   MPLS Transport Profile (MPLS-TP) are defined in [MPLS-TP-OAM].=

      Each of the = tools in the OAM toolset is defined in its own RFC, as

=

      specified in Section 1.4.

 

   o PWE3 OAM:

      The PWE3 OAM architecture defines co= ntrol channels that support

&= nbsp;     the use of existing IETF OAM tools to be used for a pse= udowire

      = (PW).  The control channels that are defined in [VCCV] and [PW-G-=

      ACH] may be = used in conjunction with ICMP Ping, LSP Ping, and BFD

<= div>

      to perform CC and CV function= ality.  In addition the channels

      support use of any of the MPLS-TP based OAM t= ools for completing

  &n= bsp;   their respective OAM functionality for a PW.

 

   o OWAMP and TWAMP:

      The One Way Active Measurement Protocol (OWAM= P) and the Two Way

  &nb= sp;   Active Measurement Protocols (TWAMP) are two protocols defined i= n

      the IP= Performance Metrics (IPPM) working group in the IETF. These

=

      protocols allow delay = and packet loss measurement in IP networks.

 

&n= bsp;

Mizrahi, et al.    =     Expires July 9, 2013           &nbs= p;      [Page 5]

Internet-Draft       Overview of OAM Mechanisms   &n= bsp;       January 2013

 

 <= /o:p>

   This document summari= zes the OAM mechanisms defined by the IETF. We

   first present a comparison of the terminolog= y used in various OAM

  =  standards, and then summarize the OAM functions that each OAM

   standard provides.=

 

<= p class=3DMsoNormal>1.4. IETF OAM Documents

 

  =  Table 1 summarizes the IETF OAM related RFCs discussed in this

   document.

 

   The table includes a "Type" column, spe= cifying the nature of each of

   the listed documents:

 

   o = Tool: documents that define an OAM tool or mechanism.

<= div>

 

   o Prof.: documents that define a profile or a variant for a= n OAM

      to= ol that is defined in other documents.

 

   = ;o Inf.: documents that define an infrastructure that is used by OAM

      tools.

 

   o Misc.: other OAM related documents, e.g., O= AM requirement and

  &nb= sp;   framework documents.

 

   +-----= ------+--------------------------------------+-----+----------+<= /p>

   |       &nbs= p;   | Title                 &= nbsp;              |Type | RFC   &n= bsp;  |

   +--= ---------+--------------------------------------+-----+----------+

   |IP Ping and| Internet C= ontrol Message Protocol    |Tool | RFC 792  |

=

   |Traceroute | [ICMPv4]   =                      = ;     |     |          |<= /o:p>

   |      = ;     +--------------------------------------+-----+----------+

   |     &= nbsp;     | Internet Control Message Protocol    |Tool = | RFC 4443 |

   | &= nbsp;         | (ICMPv6) for the Internet Protocol &nbs= p; |     |          |

   |         &nbs= p; | Version 6 (IPv6) Specification       |     | =          |

   |           | [ICMPv6]   =                      = ;     |     |          |<= /o:p>

   |      = ;     +--------------------------------------+-----+----------+

   |     &= nbsp;     | A Primer On Internet and TCP/IP      |= Tool | RFC 2151 |

  &nbs= p;|           | Tools and Utilities [TCPIP-Tools] =    |     |          |

   |       &= nbsp;   +--------------------------------------+-----+----------+=

   |     &nbs= p;     | FYI on a Network Management Tool     |Tool | R= FC 1147 |

   | &nbs= p;         | Catalog: Tools for Monitoring and   &= nbsp;|     |          |

   |         &n= bsp; | Debugging TCP/IP Internets and       |     = |          |

   |           | Interconnected= Devices [NetTools]    |     |       &nb= sp;  |

   | &n= bsp;         +--------------------------------------+--= ---+----------+

   = |           | Extended ICMP to Support Multi-Part =  |Tool | RFC 4884 |

 

 

Mizrahi, et al.         Expi= res July 9, 2013                 &n= bsp;[Page 6]

Internet-Draft &= nbsp;     Overview of OAM Mechanisms         =   January 2013

&nbs= p;

 

   |           | M= essages [ICMP-MP]                 &= nbsp; |     |          |

<= /div>

   |         &= nbsp; +--------------------------------------+-----+----------+<= /p>

   |       &nbs= p;   | ICMP Extensions for Multiprotocol    |Tool | RFC 4950= |

   |   &nbs= p;       | Label Switching [ICMP-Ext]       &= nbsp;   |     |          |

   |       &= nbsp;   +--------------------------------------+-----+----------+=

   |     &nbs= p;     | Extending ICMP for Interface and     |Tool | R= FC 5837 |

   | &nbs= p;         | Next-Hop Identification [ICMP-Int]   = |     |          |

<= div>

   +-----------+------------------------= --------------+-----+----------+

   |BFD        | Bidirectional Forwarding= Detection   |Tool | RFC 5880 |

   |           | [BFD]   &n= bsp;                     =        |     |         &n= bsp;|

   |   &= nbsp;       +--------------------------------------+-----+--= --------+

   | &nbs= p;         | Bidirectional Forwarding Detection   = |Prof.| RFC 5881 |

  &nb= sp;|           | (BFD) for IPv4 and IPv6 (Single H= op) |     |          |

   |         &nb= sp; | [BFD-IP]                 &nbs= p;           |     |      = ;    |

   = ;|           +------------------------------------= --+-----+----------+

  &= nbsp;|           | Generic Application of Bidirect= ional |Misc.| RFC 5882 |

&nbs= p;  |           | Forwarding Detection [BFD-G= en]       |     |         &nbs= p;|

   |   &nb= sp;       +--------------------------------------+-----+----= ------+

   |  =         | Bidirectional Forwarding Detection   |P= rof.| RFC 5883 |

   = ;|           | (BFD) for Multihop Paths [BFD-Multi= ] |     |          |

   |          = ; +--------------------------------------+-----+----------+

<= /div>

   |         &= nbsp; | Bidirectional Forwarding Detection   |Prof.| RFC 5884 |

   |      =     | for MPLS Label Switched Paths (LSPs) |     | &nb= sp;        |

   |           | [BFD-LSP]   &n= bsp;                     =    |     |          |

   |       &= nbsp;   +--------------------------------------+-----+----------+=

   |     &nbs= p;     | Bidirectional Forwarding Detection   |Prof.| RFC 58= 85 |

   |   &n= bsp;       | for the Pseudowire Virtual Circuit   | &nb= sp;   |          |

<= p class=3DMsoNormal>   |           | Con= nectivity Verification (VCCV)     |     |    =      |

 =  |           | [BFD-VCCV]     &nbs= p;                     | =     |          |

   +-----------+--------------------------= ------------+-----+----------+

   |MPLS OAM   | Operations and Management (OAM)   &n= bsp;  |Misc.| RFC 4377 |

   |           | Requirements for Multi= -Protocol Label|     |          |

   |      =     | Switched (MPLS) Networks [MPLS-OAM]  |     = |          |

   |           +---------------= -----------------------+-----+----------+

   |           | A Framewor= k for Multi-Protocol       |Misc.| RFC 4378 |

=

   |         =   | Label Switching (MPLS) Operations    |     | &= nbsp;        |

   |           | and Management (O= AM) [MPLS-OAM-FW]   |     |         &nbs= p;|

   |   &nb= sp;       +--------------------------------------+-----+----= ------+

   |  =         | Detecting Multi-Protocol Label    =   |Tool | RFC 4379 |

&n= bsp;  |           | Switched (MPLS) Data Plan= e Failures  |     |          |=

   |     &nbs= p;     | [LSP-Ping]             &nb= sp;             |     |   &nbs= p;      |

 

 

Mizrahi, et al.         Expi= res July 9, 2013                 &n= bsp;[Page 7]

Internet-Draft &= nbsp;     Overview of OAM Mechanisms         =   January 2013

&nbs= p;

 

   |           +--= ------------------------------------+-----+----------+

=

   |          = | Operations and Management (OAM)      |Misc.| RFC 4687 |

   |     &= nbsp;     | Requirements for Point-to-Multipoint |     = |          |

   |           | MPLS Networks = [MPLS-P2MP]            |     | &nbs= p;        |

   +-----------+--------------------------------------+-----+-= ---------+

   |MPLS= -TP    | Requirements for OAM in MPLS-TP      |Mis= c.| RFC 5860 |

   |= OAM        | [MPLS-TP-OAM]         =                |     | &n= bsp;        |

   |           +-------------------= -------------------+-----+----------+

   |           | MPLS Generic A= ssociated Channel      |Inf. | RFC 5586 |

   |         &nbs= p; | [G-ACh]                  =            |     |     &= nbsp;    |

  &= nbsp;|           +--------------------------------= ------+-----+----------+

&nbs= p;  |           | MPLS-TP OAM Framework  = ;              |Misc.| RFC 6371 |

   |      =     | [TP-OAM-FW]             &nbs= p;            |     |    =      |

 =  |           +------------------------------= --------+-----+----------+

&n= bsp;  |           | Proactive Connectivity Ve= rification, |Tool | RFC 6428 |

   |           | Continuity Check, and= Remote Defect  |     |          |<= o:p>

   |     =       | Indication for the MPLS Transport    | &nb= sp;   |          |

<= p class=3DMsoNormal>   |           | Pro= file [TP-CC-CV]                 &nb= sp; |     |          |

   |         &nb= sp; +--------------------------------------+-----+----------+

   |        =   | MPLS On-Demand Connectivity          |To= ol | RFC 6426 |

   = |           | Verification and Route Tracing  = ;     |     |          |<= /o:p>

   |      = ;     | [OnDemand-CV]             &= nbsp;          |     |     &nb= sp;    |

  &nb= sp;|           +----------------------------------= ----+-----+----------+

 =  |           | MPLS Fault Management Operati= ons,    |Tool | RFC 6427 |

   |           | Administration,= and Maintenance (OAM)|     |          |=

   |    =       | [TP-Fault]            = ;               |     |  =        |

   |           +-----------------------= ---------------+-----+----------+

   |           | MPLS Transport Pro= file Lock Instruct |Tool | RFC 6435 |

   |           | and Loopback F= unctions [Lock-Loop]   |     |         &= nbsp;|

   |   =         +--------------------------------------+-----+-= ---------+

   | &nb= sp;         | Packet Loss and Delay Measurement for|Too= l | RFC 6374 |

   |=           | MPLS Networks [MPLS-LM-DM]   &nb= sp;       |     |         &nbs= p;|

   |   &nb= sp;       +--------------------------------------+-----+----= ------+

   |  =         | A Packet Loss and Delay Measurement  |P= rof.| RFC 6375 |

   = ;|           | Profile for MPLS-Based Transport &n= bsp;   |     |          |

   |       &n= bsp;   | Networks [TP-LM-DM]            =      |     |          |<= o:p>

   +-----------+---= -----------------------------------+-----+----------+

<= div>

   |PWE3 OAM   | Pseudowire Virtual= Circuit           |Inf. | RFC 5085 |

   |        = ;   | Connectivity Verification (VCCV):    |     |=          |

   |           | A Control Chann= el for Pseudowires    |     |       &nbs= p;  |

   | &nb= sp;         | [VCCV]          =                     | &n= bsp;   |          |

=

 

<= o:p> 

Mizrahi, et al.   =       Expires July 9, 2013          = ;        [Page 8]

Internet-Draft       Overview of OAM Mechanisms &nb= sp;         January 2013

 

&= nbsp;

   |    =       +--------------------------------------+-----+-------= ---+

   |   &n= bsp;       | Bidirectional Forwarding Detection   |Prof= .| RFC 5885 |

   | =           | for the Pseudowire Virtual Circuit &nb= sp; |     |          |

   |         &nb= sp; | Connectivity Verification (VCCV)     |     | &nbs= p;        |

   |           | [BFD-VCCV]   &n= bsp;                     =   |     |          |

=

   |         =   +--------------------------------------+-----+----------+=

   |       &nb= sp;   | Using the Generic Associated Channel |Inf. | RFC 6423 |

   |      =     | Label for Pseudowire in the MPLS     |   &n= bsp; |          |

   |           | Transport= Profile (MPLS-TP)          |     | &nbs= p;        |

   |           | [PW-G-ACh]   &n= bsp;                     =   |     |          |

=

   |         =   +--------------------------------------+-----+----------+=

   |       &nb= sp;   | Pseudowire (PW) Operations,          = |Misc.| RFC 6310 |

  &nb= sp;|           | Administration, and Maintenance (= OAM)|     |          |

   |         &nb= sp; | Message Mapping [PW-Map]             | =     |          |

   +-----------+--------------------------= ------------+-----+----------+

   |OWAMP and  | A One-way Active Measurement Protocol|Too= l | RFC 4656 |

   |= TWAMP      | [OWAMP]           &nbs= p;                  |   &= nbsp; |          |

   |           +---------= -----------------------------+-----+----------+

   |           | A Tw= o-Way Active Measurement Protocol|Tool | RFC 5357 |

   |           | = [TWAMP]                   &nbs= p;          |     |      =    |

   = |           +-------------------------------------= -+-----+----------+

  &n= bsp;|           | Framework for IP Performance Met= rics |Misc.| RFC 2330 |

 = ;  |           | [IPPM-FW]     &nbs= p;                     &n= bsp;|     |          |

   |         &nb= sp; +--------------------------------------+-----+----------+

   |        =   | IPPM Metrics for Measuring           |Mi= sc.| RFC 2678 |

   = |           | Connectivity [IPPM-Con]    = ;          |     |       =    |

   |=           +--------------------------------------= +-----+----------+

  &nb= sp;|           | A One-way Delay Metric for IPPM &= nbsp;    |Misc.| RFC 2679 |

   |           | [IPPM-1DM] &nb= sp;                     &= nbsp;   |     |          |

   |       &= nbsp;   +--------------------------------------+-----+----------+=

   |     &nbs= p;     | A One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 |<= o:p>

   |     =       | [IPPM-1LM]            =               |     |   =        |

=    |           +------------------------= --------------+-----+----------+

   |           | A Round-trip Delay = Metric for IPPM   |Misc.| RFC 2681 |

   |           | [IPPM-2DM]=                     &nbs= p;     |     |          |=

   +-----------+-------= -------------------------------+-----+----------+

=

               = ;  Table 1 Summary of IETF OAM Related RFCs

<= p class=3DMsoNormal> 

 

 

 

 

 

 

Mizrahi, et al.         Expires July 9,= 2013                  [Page 9= ]

Internet-Draft    = ;   Overview of OAM Mechanisms           Janu= ary 2013

 

 

1.5. Non-IETF OAM Documents

 

  &n= bsp;In addition to the OAM mechanisms defined by the IETF, the IEEE and

   ITU-T have also def= ined various OAM mechanisms that focus on

   Ethernet, and various other transport network env= ironments. These

   = ;various mechanisms, defined by the three standard organizations, are<= /o:p>

   often tightly coupled= , and have had a mutual effect on each other.

   The ITU-T and IETF have both defined OAM mech= anisms for MPLS LSPs,

  =  [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards by the IEEE=

   and ITU-T are t= o some extent linked to IETF OAM mechanisms listed

   above and are mentioned here only as ref= erence material:

 <= /o:p>

   o OAM mechanisms for = Ethernet based networks have been defined by

      both the ITU-T in [ITU-T-Y1731], and b= y the IEEE in [IEEE802.1ag].

=       The IEEE 802.3 standard defines OAM for one-hop Ethern= et links

     = [IEEE802.3ah].

 

   o The ITU-T has define= d OAM for MPLS LSPs in [ITU-T-Y1711], and

      MPLS-TP OAM in [ITU-G8113.1] and [ITU-G81= 13.2].

 

<= /div>

   Table 2 summarizes the OAM stan= dards mentioned in this document. This

   document focuses on IETF OAM standards, but these no= n-IETF standards

   = ;are referenced where relevant.

 

   +-----= ------+--------------------------------------+---------------+

   |        = ;   | Title                 &n= bsp;              |Standard/Draft |=

   +-----------+-------= -------------------------------+---------------+

<= p class=3DMsoNormal>   |ITU-T      | Operation &am= p; Maintenance mechanism    | ITU-T Y.1711  |

=

   |MPLS OAM   | for MPLS ne= tworks [ITU-T-Y1711]      |         &nbs= p;     |

  &nb= sp;|           +----------------------------------= ----+---------------+

  =  |           | Assignment of the 'OAM Alert L= abel'  | RFC 3429      |

   |           | for Mul= tiprotocol Label Switching    |          = ;     |

  &nbs= p;|           | Architecture (MPLS) Operation and =    |               |

   |       &n= bsp;   | Maintenance (OAM) Functions          = ;|               |

<= div>

   |           = | [OAM-Label]                  = ;        |             &n= bsp; |

   |   =         |             &nb= sp;                     &= nbsp;  |               |=

   |       &nb= sp;   |  Note: although this is an IETF      | &nb= sp;             |

   |           | &nbs= p;document, it is listed as one of the|           =     |

   = |           |  non-IETF OAM standards, since = it    |               |

   |      =     |  was defined as a complementary part |     =           |

   |           |  of ITU-T = Y.1711.                   &nbs= p;|               |

=

   +-----------+-----------------------= ---------------+---------------+

   |ITU-T      | Operations, administration an= d       |ITU-T G.8113.2 |

   |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP =   |               |

<= /div>

 

 

Mizrahi, et a= l.         Expires July 9, 2013       &n= bsp;         [Page 10]

Internet-Draft       Overview of OAM Mechanism= s           January 2013

=

 

<= o:p> 

   |   &= nbsp;       | networks using the tools defined for |   =             |

   |           | MPLS [IT= U-G8113.2]                   |=               |

   |           | =                      = ;                |     &n= bsp;         |

   |           |  Note: this = document describes the   |             &= nbsp; |

   |  =         |  OAM toolset defined by the IETF for | =               |

   |           | &= nbsp;MPLS-TP, whereas ITU-T G.8113.1     |       &= nbsp;       |

=    |           |  describes the OAM= toolset defined   |               = |

   |    = ;       |  by the ITU-T.         &n= bsp;             |        = ;       |

&nbs= p;  |           +----------------------------= ----------+---------------+

&= nbsp;  |           | Operations, Administrati= on and       |ITU-T G.8113.1 |

   |           | Mainte= nance mechanism for MPLS-TP in |             =   |

   |  = ;         | Packet Transport Network (PTN)    = ;   |               |

   |        =   +--------------------------------------+---------------+=

   |       &nb= sp;   | Allocation of a Generic Associated   | RFC 6671   &n= bsp;  |

   | &= nbsp;         | Channel Type for ITU-T MPLS Transport| =               |

   |           | P= rofile Operation, Maintenance, and  |         &nbs= p;     |

  &nb= sp;|           | Administration (MPLS-TP OAM) &nbs= p;       |               = |

   |    = ;       | [ITU-T-CT]           &nbs= p;               |       =         |

   |           |       &= nbsp;                    =          |           &nb= sp;   |

   | &= nbsp;         |  Note: although this is an IETF &n= bsp;    |               |=

   |     &nbs= p;     |  document, it is listed as one of the|    = ;           |

   |           |  non-IET= F OAM standards, since it    |          =     |

   = ;|           |  was defined as a complementar= y part |               |

<= /div>

   |         &= nbsp; |  of ITU-T G.8113.1.             =      |               |

   +-----------+-----= ---------------------------------+---------------+

   |ITU-T      | OAM Functio= ns and Mechanisms for     |[ITU-T-Y1731]  |

   |Ethernet   | Ethernet-base= d Networks              |     =           |

   |OAM        |      =                     &nbs= p;          |           &= nbsp;   |

   += -----------+--------------------------------------+---------------+

   |IEEE     &nb= sp; | Connectivity Fault Management        | IEEE 802.1= ag  |

   |CFM =        | [IEEE802.1ag]         &nbs= p;              |       &= nbsp;       |

=    |           |       &n= bsp;                     =          |           &nbs= p;   |

   | &n= bsp;         |  Note: CFM was originally published=  |               |

<= /div>

   |         &= nbsp; |  as IEEE 802.1ag, but is now         | &nb= sp;             |

   |           | &nbs= p;incorporated in the 802.1Q standard.|           =     |

   = +-----------+--------------------------------------+---------------+

   |IEEE     &n= bsp; | Media Access Control Parameters,     | IEEE 802.3ah  = |

   |802.3   =    | Physical Layers, and Management      |  =             |

   |link level | Parameters for Subscriber Access=     |               |

   |OAM     &nbs= p;  | Networks [IEEE802.3ah]            =   |               |

=

   |         =   |                   &nb= sp;                  |   =             |

 

&n= bsp;

Mizrahi, et al.    =     Expires July 9, 2013           &nbs= p;     [Page 11]

In= ternet-Draft       Overview of OAM Mechanisms     =       January 2013

 

 =

   |       &nb= sp;   |  Note: link level OAM was originally |     &nbs= p;         |

   |           |  defined in IE= EE 802.3ah, and is now |               |=

   |    =       |  incorporated in the 802.3 standard. |   =             |

   +-----------+----------------------------------= ----+---------------+

  =        Table 2 Non-IETF OAM Standards Mentioned in this= Document

 

2. Basic Terminology

=

 

2.1. Abbreviations

&= nbsp;

   ACH   &nbs= p;Associated Channel Header

<= o:p> 

   AIS  =  Alarm Indication Signal

 

   BFD &nb= sp;  Bidirectional Forwarding Detection

 

 =  CC     Continuity Check

 

  &n= bsp;CV     Connectivity Verification

 

&nbs= p;  DM     Delay Measurement

 

  =  FEC    Forwarding Equivalence Class

 

   GAL    Generic Associated Label

 

   ICMP   Internet Control Message Protocol<= /p>

 

   LDP    Label Distribution Protocol=

 

<= p class=3DMsoNormal>   LM     Loss Measurement

 

   LSP    Label Switched Path

 

   ME     Maintenance Entity<= /p>

 

   MEG    Maintenance Entity Group

 

   MEP    MEG End Point

=

 

   MIP    MEG Intermediate Point

 

   MP     Maintenance Point

=

 

   MPLS   Multiprotocol Label Switching=

 

 

&nb= sp;

Mizrahi, et al.     =     Expires July 9, 2013            = ;     [Page 12]

Int= ernet-Draft       Overview of OAM Mechanisms     &= nbsp;     January 2013

 

 <= /p>

   MPLS-TP MPLS Transport Prof= ile

 

   MTU    Maximum Transmiss= ion Unit

 

   OAM    Operations, = Administration, and Maintenance

 

   PW &nb= sp;   Pseudowire

&n= bsp;

   PWE3   Pseu= dowire Emulation Edge-to-Edge

 

   RDI &nbs= p;  Remote Defect Indication

 

   TTL =    Time To Live

 

   VCCV   = Virtual Circuit Connectivity Verification

 

 

TOM: Why is = this section not at the top of this document, as is customary for RFCs? &nb= sp;

[TM] The introduction i= s now significantly shorter than it was when you sent this comment, which m= eans that the terminology section is now much closer to the beginning of th= e document.

 

 

2.2. Terminology used in OAM Standards

 

2.2.1. General Terms

 

   = A wide variety of terms is used in various OAM standards. Each of the<= /o:p>

   OAM standards listed = in the reference section includes a section that

<= p class=3DMsoNormal>   defines terms relevant to that tool. A the= saurus of terminology for

&nb= sp;  MPLS-TP terms is presented in [TP-Term], and provides a good summ= ary

   of some of t= he OAM related terminology.

<= o:p> 

   This secti= on presents a comparison of the terms used in various OAM

   standards, without fully quoting = the definition of each term. For a

   formal definition of each term, refer to the references = at the end of

   th= is document.

 

2.2.2. OAM Maintenance Entities

 

   OAM tools are designed to monitor and manage= a Maintenance Entity

  =  (ME).  An ME, as defined in [TP-OAM-FW], defines a relationship<= o:p>

   between two poin= ts of a transport path to which maintenance and

   monitoring operations apply.

=

 

   The following related terms are also quoted from [TP= -OAM-FW]:

 

   o MEP: The two points that d= efine a maintenance entity.

<= o:p> 

   o MEG: The= collection of one or more MEs that belongs to the same

      transport path and that are= maintained and monitored as a group

      are known as a Maintenance Entity Group (MEG).=

 

<= div>

 

 

 

Mizrahi, et al.       &nbs= p; Expires July 9, 2013               &n= bsp; [Page 13]

Internet-Draft=       Overview of OAM Mechanisms        = ;   January 2013

&n= bsp;

 

   o MIP: In between MEPs, there are zero= or more intermediate points,

      called Maintenance Entity Group Intermediate Points (= MIPs).

 

<= /div>

   A pair of MEPs engaged in an ME= are connected by a communication

   link, which may be one of several types of connection, e.= g. a single

   phys= ical connection, a set of physical connections, or a virtual link

   such as an MPLS LSP.=

 

<= p class=3DMsoNormal>   The term Maintenance Entity (ME) is used i= n ITU-T Recommendations

 = ;  (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology ([TP-OA= M-

   FW]). Various= terms are used to refer to an ME. For example, BFD does

   not explicitly use a term that is = equivalent to ME, but rather uses

   the term "session", referring to the relationsh= ip between two nodes

  &= nbsp;using a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) terminology<= /o:p>

   simply uses the term = "LSP" in this context.

 

   MPLS-= TP has defined the terms ME and Maintenance Entity Group (MEG)

   in [TP-OAM-FW], similar to t= he terms defined by ITU-T.  A MEG allows

   the monitoring of a compound set of MEs, for = example when monitoring

 = ;  a p2mp MEG that is considered to be the set of MEs between the root=

   and each indivi= dual destination MEP.

&n= bsp;

2.2.3. OAM Maintenance Points=

 

<= div>

   A Maintenance Point (MP) is a functio= nal entity that is defined at a

   node in the network, and either initiates or reacts to OAM = messages.

   A Main= tenance End Point (MEP) is one of the end points of an ME, and

   can initiate OAM messages an= d respond to them. A Maintenance

   Intermediate Point (MIP) is an intermediate point between = two MEPs,

   that d= oes not generally initiate OAM frames (one exception to this is<= /p>

   the use of AIS notification= s), but is able to respond to OAM frames

   that are destined to it. A MIP in MPLS-TP identif= ies OAM packets

   = destined to it by the value of the TTL field in the OAM packet. The

   term Maintenance Point = is a general term for MEPs and MIPs.

 

   T= he 802.1ag defines a finer distinction between Up MPs and Down MPs.

   An MP is a bridge inter= face, that is monitored by an OAM protocol

   either in the direction facing the network, or i= n the direction

   = facing the bridge. A Down MP is an MP that receives OAM packets from,<= /o:p>

   and transmits them to= the direction of the network. An Up MP receives

<= p class=3DMsoNormal>   OAM packets from, and transmits them to th= e direction of the bridging

&= nbsp;  entity.

&nbs= p;

   MPLS-TP ([TP-OAM-F= W]) uses a similar distinction on the placement of

   the MP - either at the ingress, egress, = or forwarding function of the

   node (Down / Up MPs).  This placement is important for l= ocalization

   of a= connection failure.

&nb= sp;

 

Mizrahi, et al.         Expires = July 9, 2013                 [Page = 14]

Internet-Draft   &nb= sp;   Overview of OAM Mechanisms           Ja= nuary 2013

 <= /p>

 

2.2.4. Proactive and On-demand activation

=

 

   The different OAM tools may be used in one of two basic ty= pes of

   activatio= n:

 

   o Proactive activation - indicates = that the tool is activated on a

      continual basis periodically, where messages are se= nt between the

    =   two MEPs, and errors are detected when a certain number of

      expected messages= are not received.

 = ;

   o On-demand activat= ion - indicates that the tool is activated

      "manually" to detect a specifi= c anomaly.  In this activation a

      small number of OAM messages are sent by a ME= P and the reply

   =   message is received.

=  

2.2.5. Connectivity Ve= rification and Continuity Checks

 

   Two d= istinct classes of failure management functions are used in OAM<= /p>

   protocols, connectivity ver= ification and continuity checks. The

   distinction between these terms is defined in [MPLS-TP= -OAM], and is

   us= ed similarly in this document.

 

   Continu= ity checks are used to verify the liveness of a connection or

   a path between two MPs, and a= re typically sent proactively, though

   they can be invoked on-demand as well.

=

 

   A connectivity verification function allows an MP to= check whether it

  &nbs= p;is connected to a peer MP or not. This function also allows the MP to

   verify that message= s from the peer MP are received through the

   correct path, thereby verifying not only that t= he two MPs are

   c= onnected, but also that they are connected through the expected<= /p>

   path. This allows detection= of unexpected topology changes. A

   connectivity verification (CV) protocol typically uses a= CV message,

   fol= lowed by a CV reply that is sent back to the originator. A CV

   function can be applied proac= tively or on-demand.

&nb= sp;

   Connectivity veri= fication and continuity checks are considered

   complementary mechanisms, and are often used = in conjunction with each

&nbs= p;  other.

 

2.2.6. Failures

 

   The terms Failure, Fault, and Defect are used interchange= ably in the

   stan= dards, referring to a malfunction that can be detected by a

<= /div>

   connectivity or a continuity ch= eck. In some standards, such as

   [IEEE802.1ag], there is no distinction between these terms,= while in

 

 

 

Mizrahi, = et al.         Expires July 9, 2013      = ;           [Page 15]

Internet-Draft       Overview of OAM Mecha= nisms           January 2013

<= div>

 

 

   other = standards each of these terms refers to a different type of

<= /div>

   malfunction.

 

   The terminology used in IETF MPLS-TP OAM takes after the= ITU-T, which

   di= stinguishes between these terms in [ITU-T-G.806]; The term Fault=

   refers to an inability to = perform a required action, e.g., an

   unsuccessful attempt to deliver a packet. The term Defe= ct refers to

   an = interruption in the normal operation, such as a consecutive period

   of time where no packets= are delivered successfully. The term Failure

   refers to the termination of the required fun= ction. While a Defect

  =  typically refers to a limited period of time, a failure refers to a

   long period of ti= me.

 

3. OAM Tools

 

3.1. IP P= ing and Traceroute

 = ;

3.1.1. Ping

=

 

   Ping is a common network diagnosis application for IP netw= orks that

   uses I= CMP. The ICMP Echo request/reply exchange is a connectivity

<= /div>

   verification function for the I= nternet Protocol. The originator

   transmits an ICMP Echo request packet, and the receiver re= plies with

   an Ec= ho reply. ICMP ping is defined in two variants, [ICMPv4] is used=

   for IPv4, and [ICMPv6] is = used for IPv6.

 

3.1.2. Traceroute

 

   Traceroute ([TCPIP-Tools], [NetTools]) is an application= that allows

   use= rs to discover the path between an IP source and an IP

=

   destination. Traceroute sends a sequ= ence of UDP packets to UDP port

   33434 at the destination. By default, Traceroute begins by = sending

   three pa= ckets (the number of packets is configurable in most

   Traceroute implementations), each with= an IP Time-To-Live (TTL) value

   of one to the destination. These packets expire as soon as = they reach

   the f= irst router in the path. That router responds by sending three

   ICMP Time Exceeded Messages = to the Traceroute application. Traceroute

   now sends another three UDP packets, each with th= e TTL value of 2.

  &nbs= p;These messages cause the second router to return ICMP messages. This=

   process continues, w= ith ever increasing values for the TTL field,

   until the packets actually reach the destinat= ion. Because no

   = application listens to port 33434 at the destination, the destination<= /o:p>

   returns ICMP Destinat= ion Unreachable Messages indicating an

   unreachable port. This event indicates to the Tracer= oute application

   = ;that it is finished.  The Traceroute program displays the round-trip<= o:p>

   delay associated= with each of the attempts.

<= o:p> 

 

 

Mizrahi, et al.         Expires July 9, 2013 &n= bsp;               [Page 16]<= /p>

Internet-Draft       Over= view of OAM Mechanisms           January 2013=

 

<= p class=3DMsoNormal> 

&n= bsp;  Note that IP routing may be asymmetric. While Traceroute reveals= the

   path betwee= n a source and destination, it may not reveal the reverse

   path.

 

&nb= sp;  A few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have be= en

   defined in th= e context of Traceroute. These extensions augment the

<= div>

   ICMP Destination Unreachable message,= and can be used by Traceroute

   applications.

=  

3.2. Bidirectional For= warding Detection (BFD)

=  

3.2.1. Overview<= /p>

 

   While multiple OAM mechanisms have been defined f= or various protocols

  &= nbsp;in the protocol stack, Bidirectional Forwarding Detection [BFD],<= /o:p>

   defined by the IETF B= FD working group, is a generic OAM mechanism

   that can be deployed over various encapsulatin= g protocols, and in

  &n= bsp;various medium types. The IETF has defined variants of the protocol

   for IP ([BFD-IP], [= BFD-Multi]), for MPLS LSPs [BFD-LSP], and for PWE3

   [BFD-VCCV]. The usage of BFD in MPLS-TP = is defined in [MPLS-TP-CC-

&n= bsp;  CV].

 

   BFD includes two main = OAM functions, using two types of BFD packets:

   BFD Control packets, and BFD Echo packets.

 

3.2.2. BFD Control

 

  &n= bsp;BFD supports a bidirectional continuity check, using BFD control

   packets, that are exch= anged within a BFD session. BFD sessions

   operate in one of two modes:

=

 

   o Asynchronous mode (i.e. proactive): in this mode BFD con= trol

      pac= kets are sent periodically. When the receiver detects that no

      BFD control packet ha= ve been received during a predetermined

      period of time, a failure is detected.

 

   o Demand mode: in this mode, BFD control= packets are sent on-demand.

=       Upon need, a system initiates a series of BFD control = packets to

    &nbs= p; verify the liveness of the session. BFD control packets are sent

      independently i= n each direction.

 =

   Each of the end-poin= ts of the monitored path maintains its own

   session identification, called a Discriminator, = both of which are

  &nbs= p;included in the BFD Control Packets that are exchanged between the

   end-points.  At t= he time of session establishment, the Discriminators

   are exchanged between the two-end poin= ts.  In addition, the

&n= bsp;  transmission (and reception) rate is negotiated between the two = end-

 

 

Mizrahi, et al.         Expires July 9, 2013 &nb= sp;               [Page 17]

Internet-Draft       Overv= iew of OAM Mechanisms           January 2013<= /o:p>

 

 

&nb= sp;  points, based on information included in the control packets. &nb= sp;These

   transmi= ssion rates may be renegotiated during the session.

 

   During normal operation of the session, i.e. no failures are<= o:p>

   detected, the BF= D session is in the Up state.  If no BFD Control

<= div>

   packets are received during a fixed p= eriod of time, called the

 

TOM: F= ixed, pre-configured or negotiated period of time (i.e.: BFD interval)=

[TM] We rephrased th= is sentence.

 

   Detection Time, the se= ssion is declared to be Down. The detection

   time is a function of the negotiated transmissi= on time, and a

   p= arameter called Detect Mult. Detect Mult determines the number of

   missing BFD Control packe= ts that cause the session to be declared as

   Down. This parameter is included in the BFD Con= trol packet.

 

3.2.3. BFD Echo

 

   A BFD echo packet is sent to a peer system, and is looped ba= ck to the

   origin= ator. The echo function can be used proactively, or on-demand.

 

   The BFD echo function has been defined in BFD for= IPv4 and IPv6

   (= [BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for

   MPLS-TP.

=

 

3.3. MPLS OAM

=  

   The IETF MPLS = working group has defined OAM for MPLS LSPs. The

<= p class=3DMsoNormal>   requirements and framework of this effort = are defined in [MPLS-OAM-

&nb= sp;  FW] and [MPLS-OAM], respectively. The corresponding OAM mechanism=

   defined, in thi= s context, is LSP Ping [LSP-Ping].

 

   LSP= Ping is based on ICMP Ping and just like its predecessor may be=

   used in one of two modes:<= o:p>

 

   o "Ping" mode: In this mode = LSP ping is used for end-to-end

      connectivity verification between two LERs.

 

   o "Traceroute" mode: This mode is u= sed for hop-by-hop fault

&nbs= p;     isolation.

<= o:p> 

   LSP Ping e= xtends the basic ICMP Ping operation (of data-plane

   connectivity verification) with functio= nality to verify data-plane

&= nbsp;  vs. control-plane consistency for a Forwarding Equivalence Clas= s

   (FEC) and also= Maximum Transmission Unit (MTU) problems. The

   traceroute functionality may be used to isol= ate and localize the MPLS

&nb= sp;  faults, using the Time-to-live (TTL) indicator to incrementally

   identify the sub-= path of the LSP that is successfully traversed

   before the faulty link or node.

 

 

&nbs= p;

 

Mizrahi, et al.         Expires J= uly 9, 2013                 [Page 1= 8]

Internet-Draft   &nbs= p;   Overview of OAM Mechanisms           Jan= uary 2013

 

 

   It should be noted that LSP Ping supports unique = identification of

  &nbs= p;the LSP within an addressing domain. The identification is checked

   using the full FEC ide= ntification. LSP Ping is easily extensible to

   include additional information needed to supp= ort new functionality,

 =  by use of Type-Length-Value (TLV) constructs. The usage of TLVs is

   typically not eas= y to perform in hardware, and is thus typically

   handled by the control plane.

 

   LSP Ping supports both asynchronous, as well as, = on-demand

   activa= tion.

 

3.4. MPLS-TP OAM

 

3.4.= 1. Overview

 =

   The MPLS working group is = currently working on defining the OAM

   toolset that fulfills the requirements for MPLS-TP OA= M. The full set

   = of requirements for MPLS-TP OAM are defined in [MPLS-TP-OAM], and

   include both general requ= irements for the behavior of the OAM

   mechanisms and a set of operations that should be supp= orted by the

   OAM= toolset.  The set of mechanisms required are further elaborated<= /o:p>

   in [TP-OAM-FW], which= describes the general architecture of the OAM

   system as well as giving overviews of the fu= nctionality of the OAM

 =  toolset.

 

   Some of the basic requ= irements for the OAM toolset for MPLS-TP are:

 

 = ;  o MPLS-TP OAM must be able to support both an IP based and non-IP

      based env= ironment. If the network is IP based, i.e. IP routing and

      forwarding are available,= then the MPLS-TP OAM toolset should rely

      on the IP routing and forwarding capabili= ties. On the other hand,

&nbs= p;     in environments where IP functionality is not available, t= he OAM

      t= ools must still be able to operate without dependence on IP

<= /div>

      forwarding and routing.=

 

<= div>

   o OAM packets and the user traffic ar= e required to be congruent

&n= bsp;     (i.e. OAM packets are transmitted in-band) and there is = a need to

     = ; differentiate OAM packets from user-plane ones. Inherent in this

      requirement is t= he principle that MPLS-TP OAM be independent of

      any existing control-plane, althoug= h it should not preclude use of

      the control-plane functionality.

 

3.4.2. Generic Associated Channel

 

  &n= bsp;In order to address the requirement for in-band transmission of MPLS-

   TP OAM traffic, M= PLS-TP uses a Generic Associated Channel (G-ACh),

=

   defined in [G-ACh] for LSP-based OAM traf= fic. This mechanism is based

=  

 

<= /div>

Mizrahi, et al.         = Expires July 9, 2013                = ; [Page 19]

Internet-Draft &n= bsp;     Overview of OAM Mechanisms         &= nbsp; January 2013

 = ;

 

=

   on the same concepts as the PWE3 ACH and = VCCV mechanisms.  However,

   to address the needs of LSPs as differentiated from PW, the= following

   conce= pts were defined for [G-ACh]:

 

   o An Ass= ociated Channel Header (ACH), that uses a format similar to

<= /div>

      the PW Control Word, is= a 4-byte header that is prepended to OAM

      packets.

 

  &= nbsp;o A Generic Associated Label (GAL). The GAL is a reserved MPLS label

      value (13= ) that indicates that the packet is an ACH packet and the

      payload follows immediate= ly after the label stack.

 

3.4.3. MPLS-TP OAM Toolse= t

 

=

   To address the functionality that is= required of the OAM toolset, the

   MPLS WG conducted an analysis of the existing IETF and IT= U-T OAM

   mechanis= ms and their ability to fulfill the required functionality.

<= /div>

   The conclusions of this analysi= s are documented in [OAM-Analys]. The

   MPLS working group currently plans to use a mixture o= f OAM mechanisms

   = ;that are based on various existing standards, and adapt them to the

   requirements of [MPLS-= TP-OAM]. Some of the main building blocks of

   this solution are based on:

 

   o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) = for

      proa= ctive continuity check and connectivity verification.

<= div>

 

   o LSP Ping as defined in [LSP-Ping] for on-demand connectiv= ity

      veri= fication.

 

   o New protocol packets, usin= g G-ACH, to address different

      functionality.

 

   o= Performance measurement protocols that are based on the

      functionality that is desc= ribed in [ITU-T-Y1731].

=  

   The following = sub-sections describe the OAM tools defined for MPLS-TP

   as described in [TP-OAM-FW].

 

3.4.3.1. Continuity Check and Connectivity Verification

 

   Continuity Check and Connectivity Verif= ication are presented in

&nbs= p;  Section 2.2.5. of this document.  As presented there, these t= ools may

   be used= either proactively or on-demand.  When using these tools

   proactively, they are genera= lly used in tandem.

&nbs= p;

   For MPLS-TP there = are two distinct tools, the proactive tool is

   defined in [TP-CC-CV] while the on-demand too= l is defined in

 

 

Mizrahi, et al.         Expires July = 9, 2013                 [Page 20]

Internet-Draft     &= nbsp; Overview of OAM Mechanisms           January= 2013

 

 

   [OnDemand-CV].Proactively [MPLS-TP-OAM] states that th= e function

   shoul= d allow the MEPs to monitor the liveness and connectivity of a

   transport path. In on-demand= mode, this function should support

   monitoring between the MEPs and, in addition, between a= MEP and MIP.

   [T= P-OAM-FW] highlights,  when performing Connectivity Verification,=

   the need for the CC-= V messages to include unique identification of

   the MEG that is being monitored and the MEP = that originated the

  &n= bsp;message.

 

   The proactive tool [TP-CC= -CV] is based on extensions to BFD (see

   Section 3.2. ) with the additional limitation tha= t the transmission

  &nb= sp;and receiving rates are based on configuration by the operator.  Th= e

   on-demand tool= [OnDemand-CV] is an adaptation of LSP Ping (see

<= p class=3DMsoNormal>   Section 3.3. ) for the required behavior o= f MPLS-TP.

 <= /p>

3.4.3.2. Route Tracing

 

   [MPLS-TP-OAM] defines that there is a need for function= ality that

   would= allow a path end-point to identify the intermediate and end-

   points of the path. This func= tion would be used in on-demand mode.

   Normally, this path will be used for bidirectional PW= , LSP, and

   secti= ons, however, unidirectional paths may be supported only if a

   return path exists.  The= tool for this is based on the LSP Ping (see

   Section 3.3. ) functionality and is described = in [OnDemand-CV].

 =

3.4.3.3. Lock Instruct=

 

   The Lock Instruct function [Lock-Loop] is used t= o notify a transport

  &= nbsp;path end-point of an administrative need to disable the transport=

   path.  This fun= ctionality will generally be used in conjunction with

<= div>

   some intrusive OAM function, e.g. Per= formance measurement, Diagnostic

   testing, to minimize the side-effect on user data traffic.=

 

<= div>

3.4.3.4. Lock Reporting

<= p class=3DMsoNormal> 

&n= bsp;  Lock Reporting is a function used by an end-point of a path to r= eport

   to its far= -end end-point that a lock condition has been affected on

   the path.

 

3.4.3.5. Alarm Reporting

 

   Alarm Report= ing is a function used by an intermediate point of a

   path, that becomes aware of a fault on= the path, to report to the

&= nbsp;  end-points of the path. [TP-OAM-FW] states that this may occur = as a

   result of a= defect condition discovered at a server sub-layer. This

   generates an Alarm Indication Sign= al (AIS) that continues until the

 

 =

 

Mizrahi, et al.         Expires July 9, 2= 013                 [Page 21]<= /o:p>

Internet-Draft      = ; Overview of OAM Mechanisms           January 201= 3

 

=

 

   fault is cleared. The consequent action of this function i= s detailed

   in [T= P-OAM-FW].

 <= /p>

3.4.3.6. Remote Defect Indication

 

   Remote Defect Indication (RDI) is used proac= tively by a path end-

  =  point to report to its peer end-point that a defect is detected on a<= o:p>

   bidirectional co= nnection between them. [MPLS-TP-OAM] points out that

   this function may be applied to a unid= irectional LSP only if there a

   return path exists.  [TP-OAM-FW] points out that this f= unction is

   assoc= iated with the proactive CC-V function.

 

3.4.3.7. = Client Failure Indication

 

   Client Failu= re Indication (CFI) is defined in [MPLS-TP-OAM] to allow

   the propagation information from o= ne edge of the network to the

   other. The information concerns a defect to a client, in the = case

   that the cl= ient does not support alarm notification.

 

3.4.3.8. = Packet Loss Measurement (LM)

=  

   Packet Lo= ss Measurement is a function used to verify the quality of

   the service. This function indic= ates the ratio of packets that are

   not delivered out of all packets that are transmitted by= the path

   source= .

 

=

   There are two possible ways of deter= mining this measurement:

 

   o Using OAM p= ackets, it is possible to compute the statistics based

=

      on a series of OAM packets. = This, however, has the disadvantage of

      being artificial, and may not be representat= ive since part of the

  =     packet loss may be dependent upon packet sizes.

 

TOM: Not just packet sizes. Things like imple= mentation (as I mentioned above with the comment about the accuracy or trut= hfulness of the data plane processing of OAM packets).  Doing very acc= urate RTT as a simple example, with just IP Pings, is a tricky thing to mak= e work.  Also, it is important to mention that the scale in terms of n= umber of packets, number of tests, etc… can and will impact these par= ameters too.

[TM] Following= your comment we rephrased this sentence.<= /span>

 

 

 

<= div>

   o Sending delimiting messages for the= start and end of a measurement

      period during which the source and sink of the path= count the

    &nbs= p; packets transmitted and received. After the end delimiter, the

      ratio would be ca= lculated by the path OAM entity.

 

3.4.3.9. Packet De= lay Measurement (DM)

&nb= sp;

   Packet Delay Meas= urement is a function that is used to measure one-

   way or two-way delay of a packet transmi= ssion between a pair of the

&= nbsp;  end-points of a path (PW, LSP, or Section). Where:

 

 

&nbs= p;

 

 

=  

Mizrahi, et al.  =       Expires July 9, 2013         &nbs= p;       [Page 22]

Internet-Draft       Overview of OAM Mechanisms   =         January 2013

 

&nbs= p;

   o One-way packet d= elay is the time elapsed from the start of

      transmission of the first bit of the pac= ket by a source node until

&n= bsp;     the reception of the last bit of that packet by the dest= ination

      = node.

 

   o Two-way packet delay is the ti= me elapsed from the start of

=       transmission of the first bit of the packet by a sourc= e node until

    &n= bsp; the reception of the last bit of the loop-backed packet by the

      same source nod= e, when the loopback is performed at the packet's

=

      destination node.

<= /div>

 

   Similarly to the packet loss measurement this could b= e performed in

   e= ither of the two ways outlined above.

 

3.5. PWE3 OAM=

 

<= div>

3.5.1. PWE3 OAM using Virtual Circuit Connectivity= Verification (VCCV)

&nb= sp;

   VCCV, as defined = in [VCCV], provides a means for end-to-end fault

<= p class=3DMsoNormal>   detection and diagnostics tools to be exte= nded for PWs (regardless of

&= nbsp;  the underlying tunneling technology). The VCCV switching functi= on

   provides a co= ntrol channel associated with each PW (based on the PW

=

   Associated Channel Header (ACH) whic= h is defined in [PW-ACH]), and

   allows transmitting the OAM packets in-band with PW data (us= ing CC

   Type 1: I= n-band VCCV).

 

   VCCV currently supports = the following OAM mechanisms: ICMP Ping, LSP

   Ping, and BFD. ICMP and LSP Ping are IP encaps= ulated before being

  &n= bsp;sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of

   encapsulation - eit= her IP/UDP encapsulated (with IP/UDP header) or

   PW-ACH encapsulated (with no IP/UDP header)= and provides support to

&nbs= p;  signal the AC status. The use of the VCCV control channel provides=

   the context, ba= sed on the MPLS-PW label, required to bind and

   bootstrap the BFD session to a particular ps= eudo wire (FEC),

   = ;eliminating the need to exchange Discriminator values.

 

   VCCV consists of two components: (1) signaled component t= o

   communicate VC= CV capabilities as part of VC label, and (2) switching

=

   component to cause the PW payload to= be treated as a control packet.

 

   VCCV = is not directly dependent upon the presence of a control plane.<= /p>

   The VCCV capability negotia= tion may be performed as part of the PW

   signaling when LDP is used. In case of manual con= figuration of the

  &nbs= p;PW, it is the responsibility of the operator to set consistent=

   options at both ends.=

 

TOM: Might be helpful to note that t= he static mode was created specifically to handle the MPLS-TP cases where n= o control plane was a requirement. However, new use cases such as pure mobi= le backhaul, etc… find this functionality useful too.

<= p class=3DMsoNormal>[TM] Following your comment we added some = text to explain this.

 

&nbs= p;

 

 

 

 

Mizrahi, et al.         Expires July 9,= 2013                 [Page 23]

Internet-Draft     &nb= sp; Overview of OAM Mechanisms           January 2= 013

 

 

3.5.2. PWE3 OAM using G-ACh

 

   As m= entioned above, VCCV enables OAM for PWs by using a control

<= /div>

   channel for OAM packets. When P= Ws are used in MPLS-TP networks,

   rather than the control channels defined in VCCV, the G-AC= h can be

   used as= an alternative control channel. The usage of the G-ACh for

<= /div>

   PWs is defined in [PW-G-ACh].

 

3.6. OWAMP and TWAMP

 

3.6.1. = Overview

 

   The IPPM working group in the= IETF defines common criteria and

   metrics for measuring performance of IP traffic ([IPPM-FW= ]). Some of

   the = key RFCs published by this working group have defined metrics for

   measuring connectivity [I= PPM-Con], delay ([IPPM-1DM], [IPPM-2DM]),

   and packet loss [IPPM-1LM].

<= div>

 

   Alternative protocols for performance measurement are defin= ed, for

   example,= in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet

<= /div>

   OAM [ITU-T-Y1731].

 

   The IPPM working group has defined not only metri= cs for performance

  &nb= sp;measurement, but also protocols that define how the measurement is<= /o:p>

   carried out. The One-= way Active Measurement Protocol [OWAMP] and the

   Two-Way Active Measurement Protocol [TWAMP]= define a method and

  &= nbsp;protocol for measuring delay and packet loss in IP networks.

 

   OWAMP [OWAMP] enables measurement of one-way ch= aracteristics of IP

  &n= bsp;networks, such as one-way packet loss and one-way delay.  For its<= o:p>

   proper operation= OWAMP requires accurate time of day setting at its

   end points.

 

&nb= sp;  TWAMP [TWAMP] is a similar protocol that enables measurement of t= wo-

   way (round t= rip) characteristics.  TWAMP does not require accurate

<= /div>

   time of day, and, furthermore, = allows the use of a simple session

   reflector, making it an attractive alternative to OWAMP.=

 

<= div>

   OWAMP and TWAMP use two separate prot= ocols: a Control plane protocol,

   and a Test plane protocol.

 

3.6.2. = Control and Test Protocols

 

   OWAMP and T= WAMP control protocols run over TCP, while the test

   protocols run over UDP.  The purpo= se of the control protocols is to

   initiate, start, and stop test sessions, and for OWAMP to= fetch

   results. =  The test protocols introduce test packets (which contain

 

 

Mizrahi, = et al.         Expires July 9, 2013      = ;           [Page 24]

Internet-Draft       Overview of OAM Mecha= nisms           January 2013

<= div>

 

Hi,


On Thu, Jan 16, 2014 at 7:29 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jan 16, 2014 at 09:38:30AM -0500, Ja= mes Nguyen wrote:
> >
> >> (2) Section 3.3 Configuration Management
> >>
> >> =A0 =A0 Session-oriented configuration protocol may be expens= ive for managing
> >> a large number of similar devices. =A0In a case when common r= edundant
> >> configurations is issued, reliable multicast with negative ac= knowledgement
> >> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multi= cast (NORM))
> >> would work best. =A0I suggest to add a reliable transport req= uirement in this
> >> section. =A0Moreover, a common data model would be needed. > >>
> >> =A0 =A0 Stateless configuration update solution would also wo= rk well for
> >> constrained networks.
> >
> > My assumption is that reliable multicast protocols are not simple= and
> > bring their own can of worms. Can you point to prototype systems = that
> > do successfully use reliable multicast to configure constrained > > devices?
>
> I certainly can list a couple of scenarios:
>
> I assume that military radios could be categorized as constrained
> devices as they're often on the move and operated in unreliable > networks with lossy links and/or highly disrupted environment.
> Military radios or military devices seem to fit the definitions that > are listed in Section 1.6.
>
> (1) In military theater or emergency disaster incident, a group of
> soldiers or a group of search-and-rescuers need to switch frequency of=
> their radios to join other group's communication network.
>
> (2) In battlefield, soldiers' need to be zero-outed (of
> configurations) to prevent these radios/comms devices to fall in
> enemies' hands.

Luckily, I am not familiar with any of this. But my concern remains
and in such scenarios, I would have serious trouble to define what
'reliable' means given that the group membership is open ended.

> > Can you also elaborate what "stateless configuration update = solution"
> > means to you?
>
> I meant stateless configuration management.
>

And that means what to you? What is 'stateless'?


Perhaps state-less means 1 session-less re= quest/response
pair instead of establishing a session, performing= a sequence of
request/response pairs, and then closing the session.




/js


Andy

--001a113ab29ea9079704f019108d-- From james.huy.nguyen@gmail.com Thu Jan 16 09:29:34 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F921AE0FC for ; Thu, 16 Jan 2014 09:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O178wiHP4sf8 for ; Thu, 16 Jan 2014 09:29:32 -0800 (PST) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3971AE0DF for ; Thu, 16 Jan 2014 09:29:32 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id 5so2794725qeb.20 for ; Thu, 16 Jan 2014 09:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l07Fpp4in51x4ywgjrcMQVdZ4TiGNVa0qubbt4pfEqA=; b=VZnG+zKpLZq5pefavuZ/G6iIqSpNtLEYifJQkey8kZkJ1w8odnllCrfCr1ycllMepS OTTunJnTB/qtngeSa29CXA5AeJPWnC5vdRSu+fQy4+SQfxew7DN5+Cfw2N2a7hiObb8k 2B25JFBcJ4B24y9BfsThTaujfeJaf6vpodQq4UwBrBhe4VGsipgkDEZo5HztSvI/wpYt bkdr4Y2b10vjRjvXY5CSN3A31+mHXuwZ5or0I7lOsoM2MtLcraPRL/ONQ4Hxw7JgcDRC s7cOsUm977dKFZUv+jvaksbvKJlypChYlBRc6q5xoiGxIrozYNAQlB/4QLMK066zGJla rT1Q== MIME-Version: 1.0 X-Received: by 10.140.89.241 with SMTP id v104mr10270333qgd.27.1389893359767; Thu, 16 Jan 2014 09:29:19 -0800 (PST) Received: by 10.96.131.11 with HTTP; Thu, 16 Jan 2014 09:29:19 -0800 (PST) In-Reply-To: References: <20140116073734.GA1160@elstar.local> <20140116152913.GA2658@elstar.local> Date: Thu, 16 Jan 2014 12:29:19 -0500 Message-ID: From: James Nguyen To: Andy Bierman Content-Type: multipart/alternative; boundary=001a11c134eafc16ad04f019c32e Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 17:29:34 -0000 --001a11c134eafc16ad04f019c32e Content-Type: text/plain; charset=UTF-8 On Thu, Jan 16, 2014 at 11:39 AM, Andy Bierman wrote: > Hi, > > > On Thu, Jan 16, 2014 at 7:29 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Thu, Jan 16, 2014 at 09:38:30AM -0500, James Nguyen wrote: >> > > >> > >> (2) Section 3.3 Configuration Management >> > >> >> > >> Session-oriented configuration protocol may be expensive for >> managing >> > >> a large number of similar devices. In a case when common redundant >> > >> configurations is issued, reliable multicast with negative >> acknowledgement >> > >> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast >> (NORM)) >> > >> would work best. I suggest to add a reliable transport requirement >> in this >> > >> section. Moreover, a common data model would be needed. >> > >> >> > >> Stateless configuration update solution would also work well for >> > >> constrained networks. >> > > >> > > My assumption is that reliable multicast protocols are not simple and >> > > bring their own can of worms. Can you point to prototype systems that >> > > do successfully use reliable multicast to configure constrained >> > > devices? >> > >> > I certainly can list a couple of scenarios: >> > >> > I assume that military radios could be categorized as constrained >> > devices as they're often on the move and operated in unreliable >> > networks with lossy links and/or highly disrupted environment. >> > Military radios or military devices seem to fit the definitions that >> > are listed in Section 1.6. >> > >> > (1) In military theater or emergency disaster incident, a group of >> > soldiers or a group of search-and-rescuers need to switch frequency of >> > their radios to join other group's communication network. >> > >> > (2) In battlefield, soldiers' need to be zero-outed (of >> > configurations) to prevent these radios/comms devices to fall in >> > enemies' hands. >> >> Luckily, I am not familiar with any of this. But my concern remains >> and in such scenarios, I would have serious trouble to define what >> 'reliable' means given that the group membership is open ended. >> >> > > Can you also elaborate what "stateless configuration update solution" >> > > means to you? >> > >> > I meant stateless configuration management. >> > >> >> And that means what to you? What is 'stateless'? >> > > > Perhaps state-less means 1 session-less request/response > pair instead of establishing a session, performing a sequence of > request/response pairs, and then closing the session. > +1 > > > > >> /js >> >> > Andy > > -- James Nguyen Email: james.huy.nguyen@gmail.com --001a11c134eafc16ad04f019c32e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 16, 2014 at 11:39 AM, Andy Bierman &l= t;andy@yumaworks.co= m> wrote:
Hi,


On Thu, Ja= n 16, 2014 at 7:29 AM, Juergen Schoenwaelder <j.schoen= waelder@jacobs-university.de> wrote:
On Thu, Jan 16, 2014 at 09:38:30AM -0500, Ja= mes Nguyen wrote:
> >
> >> (2) Section 3.3 Configuration Management
> >>
> >> =C2=A0 =C2=A0 Session-oriented configuration protocol may be = expensive for managing
> >> a large number of similar devices. =C2=A0In a case when commo= n redundant
> >> configurations is issued, reliable multicast with negative ac= knowledgement
> >> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multi= cast (NORM))
> >> would work best. =C2=A0I suggest to add a reliable transport = requirement in this
> >> section. =C2=A0Moreover, a common data model would be needed.=
> >>
> >> =C2=A0 =C2=A0 Stateless configuration update solution would a= lso work well for
> >> constrained networks.
> >
> > My assumption is that reliable multicast protocols are not simple= and
> > bring their own can of worms. Can you point to prototype systems = that
> > do successfully use reliable multicast to configure constrained > > devices?
>
> I certainly can list a couple of scenarios:
>
> I assume that military radios could be categorized as constrained
> devices as they're often on the move and operated in unreliable > networks with lossy links and/or highly disrupted environment.
> Military radios or military devices seem to fit the definitions that > are listed in Section 1.6.
>
> (1) In military theater or emergency disaster incident, a group of
> soldiers or a group of search-and-rescuers need to switch frequency of=
> their radios to join other group's communication network.
>
> (2) In battlefield, soldiers' need to be zero-outed (of
> configurations) to prevent these radios/comms devices to fall in
> enemies' hands.

Luckily, I am not familiar with any of this. But my concern remains
and in such scenarios, I would have serious trouble to define what
'reliable' means given that the group membership is open ended.

> > Can you also elaborate what "stateless configuration update = solution"
> > means to you?
>
> I meant stateless configuration management.
>

And that means what to you? What is 'stateless'?


Perhaps state-less means 1 ses= sion-less request/response
pair instead of establishing a session= , performing a sequence of
request/response pairs, and then closing the session.

+1
=C2=A0




/js


Andy

<= /div>



--
James Nguyen=
Email: james.huy.nguyen@g= mail.com
--001a11c134eafc16ad04f019c32e-- From brian.e.carpenter@gmail.com Sat Jan 18 11:44:40 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E68A1AD939 for ; Sat, 18 Jan 2014 11:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CjnU3KNv9RM for ; Sat, 18 Jan 2014 11:44:38 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9A16F1AD10A for ; Sat, 18 Jan 2014 11:44:38 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id un15so1746143pbc.32 for ; Sat, 18 Jan 2014 11:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=fjUXPX71yo0Cus68mTSeRgE5V/hKCIvJD7p07/tpUJI=; b=Pr8gpibg1yEK6ENEYNcKbAtrME1QQMFdipifeL/PMKlvL8Bn36l4/U65d2DRcWTnuB aEhSlCf1czWeMCBCMN/ImqzFbAhW7vHyr1f7JvaNdsXuu4HvwqO1nHMyxokc+zig4ixd vMEJ+kGJQDUXUG3Lu3lB17kMF7R+a6T+tjqtXIkKwczn8phlj1qKzTnev4dFiBdoYsjV ObTWrZMwNOxSRNgbup8SN6SxTAsBEA783r1yikbIu9Tg5rWiXr1bOhenbp0OV7zkAvjG OkhFlKvi6n+h3jjid3eby0jDQ8CrIkbS2hVgoAxUPvBe1mDdRs5i6tnX58q6uxd9PKX8 ZAig== X-Received: by 10.66.228.201 with SMTP id sk9mr9500678pac.134.1390074265458; Sat, 18 Jan 2014 11:44:25 -0800 (PST) Received: from [192.168.178.23] (243.199.69.111.dynamic.snap.net.nz. [111.69.199.243]) by mx.google.com with ESMTPSA id fm1sm44719620pab.22.2014.01.18.11.44.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Jan 2014 11:44:24 -0800 (PST) Message-ID: <52DAD996.1030606@gmail.com> Date: Sun, 19 Jan 2014 08:44:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] [Fwd: I-D Action: draft-jiang-config-negotiation-ps-02.txt] X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 19:44:40 -0000 Hi, We've updated this draft (problem statement for distributed autonomous configuration) following the comments we got in Vancouver, and we'd be interested in discussion here. We will also be following up this work in the IRTF Network Management research group, in the context of a more general approach to autonomous networks. However, comments from a practical viewpoint would be most welcome. Brian + co-authors -------- Original Message -------- Subject: I-D Action: draft-jiang-config-negotiation-ps-02.txt Date: Sat, 18 Jan 2014 11:23:25 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Configuration Negotiation Problem Statement and Requirements Authors : Sheng Jiang Yuanbin Yin Brian Carpenter Filename : draft-jiang-config-negotiation-ps-02.txt Pages : 14 Date : 2014-01-18 Abstract: This document describes a problem statement and general requirements for distributed autonomous configuration of multiple aspects of networks, in particular carrier networks. The basic model is that network elements need to negotiate configuration settings with each other to meet overall goals. The document describes a generic negotiation behavior model. The document also reviews whether existing management and configuration protocols may be suitable for autonomic networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-ps/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-jiang-config-negotiation-ps-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -- Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182 From internet-drafts@ietf.org Mon Jan 20 03:20:33 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7411A0123; Mon, 20 Jan 2014 03:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYBqskvOCnB3; Mon, 20 Jan 2014 03:20:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9EA1A00E0; Mon, 20 Jan 2014 03:20:31 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140120112030.14073.53842.idtracker@ietfa.amsl.com> Date: Mon, 20 Jan 2014 03:20:30 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-coman-probstate-reqs-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 11:20:33 -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 Working Gr= oup Working Group of the IETF. Title : Management of Networks with Constrained Devices: = Problem Statement and Requirements Authors : Mehmet Ersue Dan Romascanu Juergen Schoenwaelder Filename : draft-ietf-opsawg-coman-probstate-reqs-00.txt Pages : 56 Date : 2014-01-20 Abstract: This document provides a problem statement, deployment and management topology options as well as the requirements for the management of networks where constrained devices are involved. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jan 20 03:20:50 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7461A012D; Mon, 20 Jan 2014 03:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdX0TtZFDHLK; Mon, 20 Jan 2014 03:20:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3111A0122; Mon, 20 Jan 2014 03:20:49 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140120112049.13488.86954.idtracker@ietfa.amsl.com> Date: Mon, 20 Jan 2014 03:20:49 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-coman-use-cases-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 11:20:50 -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 Working Gr= oup Working Group of the IETF. Title : Management of Networks with Constrained Devices: = Use Cases Authors : Mehmet Ersue Dan Romascanu Juergen Schoenwaelder Filename : draft-ietf-opsawg-coman-use-cases-00.txt Pages : 33 Date : 2014-01-20 Abstract: This document discusses the use cases concerning the management of networks, where constrained devices are involved. A problem statement, deployment options and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tnadeau@lucidvision.com Mon Jan 20 07:29:25 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B401A01B4; Mon, 20 Jan 2014 07:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.223 X-Spam-Level: *** X-Spam-Status: No, score=3.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O2-0aJHFDk0; Mon, 20 Jan 2014 07:29:12 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5B00C1A01B9; Mon, 20 Jan 2014 07:29:11 -0800 (PST) Received: from [192.168.1.115] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 47A8526BF074; Mon, 20 Jan 2014 10:29:11 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_6B2B593D-96C5-4FE4-AD09-6076CE6AEF7A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <50F972FC.2030707@cisco.com> Date: Mon, 20 Jan 2014 10:29:10 -0500 Message-Id: <6C3490D7-3727-41BA-8980-683DF84451A2@lucidvision.com> References: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> <50F437BF.8040005@cisco.com> <50F972FC.2030707@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1827) X-Mailman-Approved-At: Mon, 20 Jan 2014 07:32:08 -0800 Cc: "draft-ietf-opsawg-oam-overview@tools.ietf.org" , opsawg@ietf.org, IETF Disgust Subject: Re: [OPSAWG] Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 15:29:25 -0000 --Apple-Mail=_6B2B593D-96C5-4FE4-AD09-6076CE6AEF7A Content-Type: multipart/alternative; boundary="Apple-Mail=_37D55104-A690-4711-87D5-FDCA45807A2C" --Apple-Mail=_37D55104-A690-4711-87D5-FDCA45807A2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Reviewing the current version of the draft (12), many of the = comments below are still not addressed. --Tom > Here is Tom Nadeau's feedback, forwarded with permission: >=20 > Regards, Benoit >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Some general comments: >=20 > I did not find any discussion around use of configuration within OAM = mechanisms. This is clearly something that is happening in groups like = PWE3 and CCAMP. The motivation for this should be explained and = documented to at least guide these efforts. > 2. There is no real discussion around the security aspects of these = tools. Should there be? >=20 > 3. While the document provides a nice taxonomy of various OAM tools, = it does not really discuss the techniques for using them. I do not = expect anything in detail, but it is not obvious that many of these = tools can be orchestrated to form a "toolset" that can be used to do = multi-layer OAM functions for services such as carrier Ethernet over = VPLS over MPLS, for example. >=20 > 4. It might be useful to at least mention in the performance metrics = section, a discussion around the accuracy of these tools and how it = depends on scale, implementation and network configurations. >=20 >=20 > My detailed comments inline starting with TOM: >=20 > --Tom >=20 >=20 >=20 >=20 >=20 >=20 > Expires: July 2013 Nokia Siemens = Networks > E. = Bellagamba > = Ericsson > Y. = Weingarten >=20 > January 9, = 2013 >=20 > An Overview of > Operations, Administration, and Maintenance (OAM) Mechanisms > draft-ietf-opsawg-oam-overview-08.txt >=20 >=20 > Abstract >=20 > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset that can be used for fault detection and > isolation, and for performance measurement. OAM mechanisms have = been > defined for various layers in the protocol stack, and are used with = a > variety of protocols. >=20 > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted to IETF in full conformance with = the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. >=20 > Internet-Drafts are draft documents valid for a maximum of six = months > and may be updated, replaced, or obsoleted by other documents at = any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on July 9, 2013. >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 1] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > Copyright Notice >=20 > Copyright (c) 2013 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with = respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. >=20 > Table of Contents >=20 >=20 > 1. Introduction ................................................. 3 > 1.1. The Building Blocks of OAM .............................. 3 > 1.2. Forwarding Plane vs. Management Plane ................... 4 > 1.3. The OAM toolsets ........................................ 4 > 1.4. IETF OAM Documents ...................................... 6 > 1.5. Non-IETF OAM Documents ................................. 10 > 2. Basic Terminology ........................................... 12 > 2.1. Abbreviations .......................................... 12 > 2.2. Terminology used in OAM Standards ...................... 13 > 2.2.1. General Terms ..................................... 13 > 2.2.2. OAM Maintenance Entities .......................... 13 > 2.2.3. OAM Maintenance Points ............................ 14 > 2.2.4. Proactive and On-demand activation ................ 15 > 2.2.5. Connectivity Verification and Continuity Checks ... 15 > 2.2.6. Failures .......................................... 15 > 3. OAM Tools ................................................... 16 > 3.1. IP Ping and Traceroute ................................. 16 > 3.1.1. Ping .............................................. 16 > 3.1.2. Traceroute......................................... 16 > 3.2. Bidirectional Forwarding Detection (BFD) ............... 17 > 3.2.1. Overview .......................................... 17 > 3.2.2. BFD Control ....................................... 17 > 3.2.3. BFD Echo .......................................... 18 > 3.3. MPLS OAM ............................................... 18 > 3.4. MPLS-TP OAM ............................................ 19 > 3.4.1. Overview .......................................... 19 > 3.4.2. Generic Associated Channel ........................ 19 > 3.4.3. MPLS-TP OAM Toolset ............................... 20 > 3.4.3.1. Continuity Check and Connectivity Verification 20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 2] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > 3.4.3.2. Route Tracing ................................ 21 > 3.4.3.3. Lock Instruct ................................ 21 > 3.4.3.4. Lock Reporting ............................... 21 > 3.4.3.5. Alarm Reporting .............................. 21 > 3.4.3.6. Remote Defect Indication ..................... 22 > 3.4.3.7. Client Failure Indication .................... 22 > 3.4.3.8. Packet Loss Measurement (LM) ................. 22 > 3.4.3.9. Packet Delay Measurement (DM) ................ 22 > 3.5. PWE3 OAM ............................................... 23 > 3.5.1. PWE3 OAM using Virtual Circuit Connectivity = Verification > (VCCV) ................................................... 23 > 3.5.2. PWE3 OAM using G-ACh .............................. 24 > 3.6. OWAMP and TWAMP......................................... 24 > 3.6.1. Overview .......................................... 24 > 3.6.2. Control and Test Protocols ........................ 24 > 3.6.3. OWAMP ............................................. 25 > 3.6.4. TWAMP ............................................. 26 > 3.7. Summary of OAM Functions ............................... 26 > 4. Security Considerations ..................................... 27 > 5. IANA Considerations ......................................... 27 > 6. Acknowledgments ............................................. 27 > 7. References .................................................. 28 > 7.1. Normative References ................................... 28 > 7.2. Informative References ................................. 31 >=20 > 1. Introduction >=20 > OAM is a general term that refers to a toolset for detecting, > isolating and reporting connection failures and performance > degradation. >=20 > This document summarizes the OAM tools and mechanisms defined in = the > IETF. >=20 > The term OAM in this document refers to Operations, Administration > and Maintenance [OAM-Def], focusing on the forwarding plane of OAM. > Hence, management aspects are outside the scope of this document. >=20 > TOM: This is a curious sentence to me since to me, OAM is management, = or a subset of it. Also, if you look at the referenced documents, = there are many indirect references to MIBs, Netconf, etc=85 making this = sentence further confusing. It might be helpful to explain more clearly = that the authors here intended to not cover those things explicitly = rather than grouping them arbitrarily under the definition of = "management aspects" Further, to clarify, it might be useful to expand = on what "forwarding plane" is here just to be clear. That is, is this = "in band" or "out-of band" or both? Some of the tools referred to here = also are part of the control AND data planes.=20 >=20 > 1.1. The Building Blocks of OAM >=20 > An OAM protocol is run in the context of a Maintenance Domain, > consisting of two or more nodes that run the OAM protocol, referred > to as Maintenance Points (MP). >=20 > This subsection provides a brief summary of the common tools used = by > OAM protocols. An OAM protocol typically supports one or more of = the > tools described below. >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 3] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > o Continuity Checking (CC): > Used for verifying the liveness of a connection between two MPs. >=20 > o Connectivity Verification (CV): > Allows an MP to check whether it is connected to a peer MP, and = to > verify that messages from the peer MP are received through the > expected path. >=20 > o Path Discovery / Fault Localization: > An MP uses this mechanism to trace the route to a peer MP, i.e., > to identify the nodes along the path to the peer MP. When a > connection fails, this mechanism also allows the MP to detect = the > location of the failure. >=20 > TOM: The definition calls this "path discovery" but then talks about = tracing routes. A better way of describing this in the paragraph would = be that there I a use of path tracing in order to discover (or = re-discover) paths that have been changed, created or destroyed. =20 >=20 >=20 > o Performance Monitoring: > Consists of 3 main functions >=20 > o Loss Measurement (LM) - monitors the packet loss rate of a > connection. >=20 > o Delay Measurement (DM) - monitors the delay and delay > variation between MPs. >=20 > o Throughput measurement - monitors the throughput of a > connection. >=20 > TOM: Along with the discussion above around path trace/discovery, it = is imperative that paths be discovered (one way or another) in order to = successfully d performance monitoring on those paths. >=20 > 1.2. Forwarding Plane vs. Management Plane >=20 > While the OAM tools may, and quite often do, work in conjunction = with > a control-plane or management plane, they are usually defined to be > independent of the control-plane. The OAM tools communicate with = the > management plane to raise alarms, and often the on-demand tools may > be activated by the management, e.g. to locate and localize = problems. >=20 > The considerations of the control-plane maintenance tools or the > functionality of the management-plane are out of scope for this > document, which will concentrate on presenting the forwarding-plane > tools that are used for OAM. >=20 > TOM: What about the data plane? For example, the GACH OAM type is such = an example. VCCV also operates within the data plane after its = configuration capabilities have been signaled. It should also be = mentioned that it is imperative that when required, OAM tools are = capable of testing the actual data plane in as much accuracy as = possible, but that they all should note how accurate. Not all OAM = tools are created equal. >=20 >=20 > 1.3. The OAM toolsets >=20 > This memo provides an overview of the different sets of OAM > mechanisms defined by the IETF. It is intended for those with = little > or no familiarity with the described mechanisms. The set of OAM > mechanisms described in this memo are applicable to IP unicast, = MPLS, > pseudowires, and MPLS for the transport environment (MPLS-TP). = While > OAM mechanisms that are applicable to other technologies exist, = they >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 4] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > are beyond the scope of this memo. This document focuses on IETF > documents that have been published as RFCs, while other ongoing = OAM- > related work is outside the scope. >=20 > The IETF has defined OAM protocols and mechanisms in several > different fronts: >=20 > o IP Ping and Traceroute: > Ping is a very simple and common application for failure = diagnosis >=20 > TOM: I am not sure the term "common" is necessary. >=20 > that uses ICMP Echo requests, as defined in [ICMPv4], and > [ICMPv6]. > Traceroute ([TCPIP-Tools], [NetTools]) is an application that > allows users to trace the path between an IP source and an IP > destination, i.e., to identify the nodes along the path. >=20 > o BFD: > Bidirectional Forwarding Detection (BFD) is defined in [BFD] as = a > framework for a lightweight generic OAM mechanism. The = intention > is to define a base mechanism that can be used with various > encapsulation types, network environments, and in various medium > types. >=20 > o MPLS OAM: > MPLS LSP Ping, as defined in [MPLS-OAM], [MPLS-OAM-FW] and [LSP- > Ping], is an OAM mechanism for point to point MPLS LSPs. It > includes two main functions: Ping and Traceroute. >=20 > o MPLS-TP OAM: > MPLS-TP OAM is defined in a set of RFCs. The OAM requirements = for > MPLS Transport Profile (MPLS-TP) are defined in [MPLS-TP-OAM]. > Each of the tools in the OAM toolset is defined in its own RFC, = as > specified in Section 1.4. >=20 > o PWE3 OAM: > The PWE3 OAM architecture defines control channels that support > the use of existing IETF OAM tools to be used for a pseudowire > (PW). The control channels that are defined in [VCCV] and = [PW-G- > ACH] may be used in conjunction with ICMP Ping, LSP Ping, and = BFD > to perform CC and CV functionality. In addition the channels > support use of any of the MPLS-TP based OAM tools for completing > their respective OAM functionality for a PW. >=20 > o OWAMP and TWAMP: > The One Way Active Measurement Protocol (OWAMP) and the Two Way > Active Measurement Protocols (TWAMP) are two protocols defined = in > the IP Performance Metrics (IPPM) working group in the IETF. = These > protocols allow delay and packet loss measurement in IP = networks. >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 5] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > This document summarizes the OAM mechanisms defined by the IETF. We > first present a comparison of the terminology used in various OAM > standards, and then summarize the OAM functions that each OAM > standard provides. >=20 > 1.4. IETF OAM Documents >=20 > Table 1 summarizes the IETF OAM related RFCs discussed in this > document. >=20 > The table includes a "Type" column, specifying the nature of each = of > the listed documents: >=20 > o Tool: documents that define an OAM tool or mechanism. >=20 > o Prof.: documents that define a profile or a variant for an OAM > tool that is defined in other documents. >=20 > o Inf.: documents that define an infrastructure that is used by OAM > tools. >=20 > o Misc.: other OAM related documents, e.g., OAM requirement and > framework documents. >=20 > = +-----------+--------------------------------------+-----+----------+ > | | Title |Type | RFC = | > = +-----------+--------------------------------------+-----+----------+ > |IP Ping and| Internet Control Message Protocol |Tool | RFC 792 = | > |Traceroute | [ICMPv4] | | = | > | = +--------------------------------------+-----+----------+ > | | Internet Control Message Protocol |Tool | RFC 4443 = | > | | (ICMPv6) for the Internet Protocol | | = | > | | Version 6 (IPv6) Specification | | = | > | | [ICMPv6] | | = | > | = +--------------------------------------+-----+----------+ > | | A Primer On Internet and TCP/IP |Tool | RFC 2151 = | > | | Tools and Utilities [TCPIP-Tools] | | = | > | = +--------------------------------------+-----+----------+ > | | FYI on a Network Management Tool |Tool | RFC 1147 = | > | | Catalog: Tools for Monitoring and | | = | > | | Debugging TCP/IP Internets and | | = | > | | Interconnected Devices [NetTools] | | = | > | = +--------------------------------------+-----+----------+ > | | Extended ICMP to Support Multi-Part |Tool | RFC 4884 = | >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 6] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > | | Messages [ICMP-MP] | | = | > | = +--------------------------------------+-----+----------+ > | | ICMP Extensions for Multiprotocol |Tool | RFC 4950 = | > | | Label Switching [ICMP-Ext] | | = | > | = +--------------------------------------+-----+----------+ > | | Extending ICMP for Interface and |Tool | RFC 5837 = | > | | Next-Hop Identification [ICMP-Int] | | = | > = +-----------+--------------------------------------+-----+----------+ > |BFD | Bidirectional Forwarding Detection |Tool | RFC 5880 = | > | | [BFD] | | = | > | = +--------------------------------------+-----+----------+ > | | Bidirectional Forwarding Detection |Prof.| RFC 5881 = | > | | (BFD) for IPv4 and IPv6 (Single Hop) | | = | > | | [BFD-IP] | | = | > | = +--------------------------------------+-----+----------+ > | | Generic Application of Bidirectional |Misc.| RFC 5882 = | > | | Forwarding Detection [BFD-Gen] | | = | > | = +--------------------------------------+-----+----------+ > | | Bidirectional Forwarding Detection |Prof.| RFC 5883 = | > | | (BFD) for Multihop Paths [BFD-Multi] | | = | > | = +--------------------------------------+-----+----------+ > | | Bidirectional Forwarding Detection |Prof.| RFC 5884 = | > | | for MPLS Label Switched Paths (LSPs) | | = | > | | [BFD-LSP] | | = | > | = +--------------------------------------+-----+----------+ > | | Bidirectional Forwarding Detection |Prof.| RFC 5885 = | > | | for the Pseudowire Virtual Circuit | | = | > | | Connectivity Verification (VCCV) | | = | > | | [BFD-VCCV] | | = | > = +-----------+--------------------------------------+-----+----------+ > |MPLS OAM | Operations and Management (OAM) |Misc.| RFC 4377 = | > | | Requirements for Multi-Protocol Label| | = | > | | Switched (MPLS) Networks [MPLS-OAM] | | = | > | = +--------------------------------------+-----+----------+ > | | A Framework for Multi-Protocol |Misc.| RFC 4378 = | > | | Label Switching (MPLS) Operations | | = | > | | and Management (OAM) [MPLS-OAM-FW] | | = | > | = +--------------------------------------+-----+----------+ > | | Detecting Multi-Protocol Label |Tool | RFC 4379 = | > | | Switched (MPLS) Data Plane Failures | | = | > | | [LSP-Ping] | | = | >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 7] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > | = +--------------------------------------+-----+----------+ > | | Operations and Management (OAM) |Misc.| RFC 4687 = | > | | Requirements for Point-to-Multipoint | | = | > | | MPLS Networks [MPLS-P2MP] | | = | > = +-----------+--------------------------------------+-----+----------+ > |MPLS-TP | Requirements for OAM in MPLS-TP |Misc.| RFC 5860 = | > |OAM | [MPLS-TP-OAM] | | = | > | = +--------------------------------------+-----+----------+ > | | MPLS Generic Associated Channel |Inf. | RFC 5586 = | > | | [G-ACh] | | = | > | = +--------------------------------------+-----+----------+ > | | MPLS-TP OAM Framework |Misc.| RFC 6371 = | > | | [TP-OAM-FW] | | = | > | = +--------------------------------------+-----+----------+ > | | Proactive Connectivity Verification, |Tool | RFC 6428 = | > | | Continuity Check, and Remote Defect | | = | > | | Indication for the MPLS Transport | | = | > | | Profile [TP-CC-CV] | | = | > | = +--------------------------------------+-----+----------+ > | | MPLS On-Demand Connectivity |Tool | RFC 6426 = | > | | Verification and Route Tracing | | = | > | | [OnDemand-CV] | | = | > | = +--------------------------------------+-----+----------+ > | | MPLS Fault Management Operations, |Tool | RFC 6427 = | > | | Administration, and Maintenance (OAM)| | = | > | | [TP-Fault] | | = | > | = +--------------------------------------+-----+----------+ > | | MPLS Transport Profile Lock Instruct |Tool | RFC 6435 = | > | | and Loopback Functions [Lock-Loop] | | = | > | = +--------------------------------------+-----+----------+ > | | Packet Loss and Delay Measurement for|Tool | RFC 6374 = | > | | MPLS Networks [MPLS-LM-DM] | | = | > | = +--------------------------------------+-----+----------+ > | | A Packet Loss and Delay Measurement |Prof.| RFC 6375 = | > | | Profile for MPLS-Based Transport | | = | > | | Networks [TP-LM-DM] | | = | > = +-----------+--------------------------------------+-----+----------+ > |PWE3 OAM | Pseudowire Virtual Circuit |Inf. | RFC 5085 = | > | | Connectivity Verification (VCCV): | | = | > | | A Control Channel for Pseudowires | | = | > | | [VCCV] | | = | >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 8] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > | = +--------------------------------------+-----+----------+ > | | Bidirectional Forwarding Detection |Prof.| RFC 5885 = | > | | for the Pseudowire Virtual Circuit | | = | > | | Connectivity Verification (VCCV) | | = | > | | [BFD-VCCV] | | = | > | = +--------------------------------------+-----+----------+ > | | Using the Generic Associated Channel |Inf. | RFC 6423 = | > | | Label for Pseudowire in the MPLS | | = | > | | Transport Profile (MPLS-TP) | | = | > | | [PW-G-ACh] | | = | > | = +--------------------------------------+-----+----------+ > | | Pseudowire (PW) Operations, |Misc.| RFC 6310 = | > | | Administration, and Maintenance (OAM)| | = | > | | Message Mapping [PW-Map] | | = | > = +-----------+--------------------------------------+-----+----------+ > |OWAMP and | A One-way Active Measurement Protocol|Tool | RFC 4656 = | > |TWAMP | [OWAMP] | | = | > | = +--------------------------------------+-----+----------+ > | | A Two-Way Active Measurement Protocol|Tool | RFC 5357 = | > | | [TWAMP] | | = | > | = +--------------------------------------+-----+----------+ > | | Framework for IP Performance Metrics |Misc.| RFC 2330 = | > | | [IPPM-FW] | | = | > | = +--------------------------------------+-----+----------+ > | | IPPM Metrics for Measuring |Misc.| RFC 2678 = | > | | Connectivity [IPPM-Con] | | = | > | = +--------------------------------------+-----+----------+ > | | A One-way Delay Metric for IPPM |Misc.| RFC 2679 = | > | | [IPPM-1DM] | | = | > | = +--------------------------------------+-----+----------+ > | | A One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 = | > | | [IPPM-1LM] | | = | > | = +--------------------------------------+-----+----------+ > | | A Round-trip Delay Metric for IPPM |Misc.| RFC 2681 = | > | | [IPPM-2DM] | | = | > = +-----------+--------------------------------------+-----+----------+ > Table 1 Summary of IETF OAM Related RFCs >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 9] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > 1.5. Non-IETF OAM Documents >=20 > In addition to the OAM mechanisms defined by the IETF, the IEEE and > ITU-T have also defined various OAM mechanisms that focus on > Ethernet, and various other transport network environments. These > various mechanisms, defined by the three standard organizations, = are > often tightly coupled, and have had a mutual effect on each other. > The ITU-T and IETF have both defined OAM mechanisms for MPLS LSPs, > [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards by the = IEEE > and ITU-T are to some extent linked to IETF OAM mechanisms listed > above and are mentioned here only as reference material: >=20 > o OAM mechanisms for Ethernet based networks have been defined by > both the ITU-T in [ITU-T-Y1731], and by the IEEE in = [IEEE802.1ag]. > The IEEE 802.3 standard defines OAM for one-hop Ethernet links > [IEEE802.3ah]. >=20 > o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and > MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. >=20 > Table 2 summarizes the OAM standards mentioned in this document. = This > document focuses on IETF OAM standards, but these non-IETF = standards > are referenced where relevant. >=20 > = +-----------+--------------------------------------+---------------+ > | | Title |Standard/Draft = | > = +-----------+--------------------------------------+---------------+ > |ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 = | > |MPLS OAM | for MPLS networks [ITU-T-Y1711] | = | > | = +--------------------------------------+---------------+ > | | Assignment of the 'OAM Alert Label' | RFC 3429 = | > | | for Multiprotocol Label Switching | = | > | | Architecture (MPLS) Operation and | = | > | | Maintenance (OAM) Functions | = | > | | [OAM-Label] | = | > | | | = | > | | Note: although this is an IETF | = | > | | document, it is listed as one of the| = | > | | non-IETF OAM standards, since it | = | > | | was defined as a complementary part | = | > | | of ITU-T Y.1711. | = | > = +-----------+--------------------------------------+---------------+ > |ITU-T | Operations, administration and |ITU-T G.8113.2 = | > |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | = | >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 10] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > | | networks using the tools defined for | = | > | | MPLS [ITU-G8113.2] | = | > | | | = | > | | Note: this document describes the | = | > | | OAM toolset defined by the IETF for | = | > | | MPLS-TP, whereas ITU-T G.8113.1 | = | > | | describes the OAM toolset defined | = | > | | by the ITU-T. | = | > | = +--------------------------------------+---------------+ > | | Operations, Administration and |ITU-T G.8113.1 = | > | | Maintenance mechanism for MPLS-TP in | = | > | | Packet Transport Network (PTN) | = | > | = +--------------------------------------+---------------+ > | | Allocation of a Generic Associated | RFC 6671 = | > | | Channel Type for ITU-T MPLS Transport| = | > | | Profile Operation, Maintenance, and | = | > | | Administration (MPLS-TP OAM) | = | > | | [ITU-T-CT] | = | > | | | = | > | | Note: although this is an IETF | = | > | | document, it is listed as one of the| = | > | | non-IETF OAM standards, since it | = | > | | was defined as a complementary part | = | > | | of ITU-T G.8113.1. | = | > = +-----------+--------------------------------------+---------------+ > |ITU-T | OAM Functions and Mechanisms for |[ITU-T-Y1731] = | > |Ethernet | Ethernet-based Networks | = | > |OAM | | = | > = +-----------+--------------------------------------+---------------+ > |IEEE | Connectivity Fault Management | IEEE 802.1ag = | > |CFM | [IEEE802.1ag] | = | > | | | = | > | | Note: CFM was originally published | = | > | | as IEEE 802.1ag, but is now | = | > | | incorporated in the 802.1Q standard.| = | > = +-----------+--------------------------------------+---------------+ > |IEEE | Media Access Control Parameters, | IEEE 802.3ah = | > |802.3 | Physical Layers, and Management | = | > |link level | Parameters for Subscriber Access | = | > |OAM | Networks [IEEE802.3ah] | = | > | | | = | >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 11] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > | | Note: link level OAM was originally | = | > | | defined in IEEE 802.3ah, and is now | = | > | | incorporated in the 802.3 standard. | = | > = +-----------+--------------------------------------+---------------+ > Table 2 Non-IETF OAM Standards Mentioned in this Document >=20 > 2. Basic Terminology >=20 > 2.1. Abbreviations >=20 > ACH Associated Channel Header >=20 > AIS Alarm Indication Signal >=20 > BFD Bidirectional Forwarding Detection >=20 > CC Continuity Check >=20 > CV Connectivity Verification >=20 > DM Delay Measurement >=20 > FEC Forwarding Equivalence Class >=20 > GAL Generic Associated Label >=20 > ICMP Internet Control Message Protocol >=20 > LDP Label Distribution Protocol >=20 > LM Loss Measurement >=20 > LSP Label Switched Path >=20 > ME Maintenance Entity >=20 > MEG Maintenance Entity Group >=20 > MEP MEG End Point >=20 > MIP MEG Intermediate Point >=20 > MP Maintenance Point >=20 > MPLS Multiprotocol Label Switching >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 12] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > MPLS-TP MPLS Transport Profile >=20 > MTU Maximum Transmission Unit >=20 > OAM Operations, Administration, and Maintenance >=20 > PW Pseudowire >=20 > PWE3 Pseudowire Emulation Edge-to-Edge >=20 > RDI Remote Defect Indication >=20 > TTL Time To Live >=20 > VCCV Virtual Circuit Connectivity Verification >=20 >=20 > TOM: Why is this section not at the top of this document, as is = customary for RFCs? =20 >=20 >=20 > 2.2. Terminology used in OAM Standards >=20 > 2.2.1. General Terms >=20 > A wide variety of terms is used in various OAM standards. Each of = the > OAM standards listed in the reference section includes a section = that > defines terms relevant to that tool. A thesaurus of terminology for > MPLS-TP terms is presented in [TP-Term], and provides a good = summary > of some of the OAM related terminology. >=20 > This section presents a comparison of the terms used in various OAM > standards, without fully quoting the definition of each term. For a > formal definition of each term, refer to the references at the end = of > this document. >=20 > 2.2.2. OAM Maintenance Entities >=20 > OAM tools are designed to monitor and manage a Maintenance Entity > (ME). An ME, as defined in [TP-OAM-FW], defines a relationship > between two points of a transport path to which maintenance and > monitoring operations apply. >=20 > The following related terms are also quoted from [TP-OAM-FW]: >=20 > o MEP: The two points that define a maintenance entity. >=20 > o MEG: The collection of one or more MEs that belongs to the same > transport path and that are maintained and monitored as a group > are known as a Maintenance Entity Group (MEG). >=20 >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 13] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > o MIP: In between MEPs, there are zero or more intermediate points, > called Maintenance Entity Group Intermediate Points (MIPs). >=20 > A pair of MEPs engaged in an ME are connected by a communication > link, which may be one of several types of connection, e.g. a = single > physical connection, a set of physical connections, or a virtual = link > such as an MPLS LSP. >=20 > The term Maintenance Entity (ME) is used in ITU-T Recommendations > (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology = ([TP-OAM- > FW]). Various terms are used to refer to an ME. For example, BFD = does > not explicitly use a term that is equivalent to ME, but rather uses > the term "session", referring to the relationship between two nodes > using a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) terminology > simply uses the term "LSP" in this context. >=20 > MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG) > in [TP-OAM-FW], similar to the terms defined by ITU-T. A MEG = allows > the monitoring of a compound set of MEs, for example when = monitoring > a p2mp MEG that is considered to be the set of MEs between the root > and each individual destination MEP. >=20 > 2.2.3. OAM Maintenance Points >=20 > A Maintenance Point (MP) is a functional entity that is defined at = a > node in the network, and either initiates or reacts to OAM = messages. > A Maintenance End Point (MEP) is one of the end points of an ME, = and > can initiate OAM messages and respond to them. A Maintenance > Intermediate Point (MIP) is an intermediate point between two MEPs, > that does not generally initiate OAM frames (one exception to this = is > the use of AIS notifications), but is able to respond to OAM frames > that are destined to it. A MIP in MPLS-TP identifies OAM packets > destined to it by the value of the TTL field in the OAM packet. The > term Maintenance Point is a general term for MEPs and MIPs. >=20 > The 802.1ag defines a finer distinction between Up MPs and Down = MPs. > An MP is a bridge interface, that is monitored by an OAM protocol > either in the direction facing the network, or in the direction > facing the bridge. A Down MP is an MP that receives OAM packets = from, > and transmits them to the direction of the network. An Up MP = receives > OAM packets from, and transmits them to the direction of the = bridging > entity. >=20 > MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement = of > the MP - either at the ingress, egress, or forwarding function of = the > node (Down / Up MPs). This placement is important for localization > of a connection failure. >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 14] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > 2.2.4. Proactive and On-demand activation >=20 > The different OAM tools may be used in one of two basic types of > activation: >=20 > o Proactive activation - indicates that the tool is activated on a > continual basis periodically, where messages are sent between = the > two MEPs, and errors are detected when a certain number of > expected messages are not received. >=20 > o On-demand activation - indicates that the tool is activated > "manually" to detect a specific anomaly. In this activation a > small number of OAM messages are sent by a MEP and the reply > message is received. >=20 > 2.2.5. Connectivity Verification and Continuity Checks >=20 > 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 > Continuity checks are used to verify the liveness of a connection = or > a path between two MPs, and are typically sent proactively, though > they can be invoked on-demand as well. >=20 > A connectivity verification function allows an MP to check whether = it > is connected to a peer MP or not. This function also allows the MP = to > verify that messages from the peer MP are received through the > correct path, thereby verifying not only that the two MPs are > connected, but also that they are connected through the expected > path. This allows detection of unexpected topology changes. A > connectivity verification (CV) protocol typically uses a CV = message, > followed by a CV reply that is sent back to the originator. A CV > function can be applied proactively or on-demand. >=20 > Connectivity verification and continuity checks are considered > complementary mechanisms, and are often used in conjunction with = each > other. >=20 > 2.2.6. Failures >=20 > The terms Failure, Fault, and Defect are used interchangeably in = the > standards, referring to a malfunction that can be detected by a > connectivity or a continuity check. In some standards, such as > [IEEE802.1ag], there is no distinction between these terms, while = in >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 15] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > other standards each of these terms refers to a different type of > malfunction. >=20 > The terminology used in IETF MPLS-TP OAM takes after the ITU-T, = which > distinguishes between these terms in [ITU-T-G.806]; The term Fault > refers to an inability to perform a required action, e.g., an > unsuccessful attempt to deliver a packet. The term Defect refers to > an interruption in the normal operation, such as a consecutive = period > of time where no packets are delivered successfully. The term = Failure > refers to the termination of the required function. While a Defect > typically refers to a limited period of time, a failure refers to a > long period of time. >=20 > 3. OAM Tools >=20 > 3.1. IP Ping and Traceroute >=20 > 3.1.1. Ping >=20 > Ping is a common network diagnosis application for IP networks that > uses ICMP. The ICMP Echo request/reply exchange is a connectivity > verification function for the Internet Protocol. The originator > transmits an ICMP Echo request packet, and the receiver replies = with > an Echo reply. ICMP ping is defined in two variants, [ICMPv4] is = used > for IPv4, and [ICMPv6] is used for IPv6. >=20 > 3.1.2. Traceroute >=20 > Traceroute ([TCPIP-Tools], [NetTools]) is an application that = allows > users to discover the path between an IP source and an IP > destination. Traceroute sends a sequence of UDP packets to UDP port > 33434 at the destination. By default, Traceroute begins by sending > three packets (the number of packets is configurable in most > Traceroute implementations), each with an IP Time-To-Live (TTL) = value > of one to the destination. These packets expire as soon as they = reach > the first router in the path. That router responds by sending three > ICMP Time Exceeded Messages to the Traceroute application. = Traceroute > now sends another three UDP packets, each with the TTL value of 2. > These messages cause the second router to return ICMP messages. = This > process continues, with ever increasing values for the TTL field, > until the packets actually reach the destination. Because no > application listens to port 33434 at the destination, the = destination > returns ICMP Destination Unreachable Messages indicating an > unreachable port. This event indicates to the Traceroute = application > that it is finished. The Traceroute program displays the = round-trip > delay associated with each of the attempts. >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 16] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > Note that IP routing may be asymmetric. While Traceroute reveals = the > path between a source and destination, it may not reveal the = reverse > path. >=20 > A few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have been > defined in the context of Traceroute. These extensions augment the > ICMP Destination Unreachable message, and can be used by Traceroute > applications. >=20 > 3.2. Bidirectional Forwarding Detection (BFD) >=20 > 3.2.1. Overview >=20 > While multiple OAM mechanisms have been defined for various = protocols > in the protocol stack, Bidirectional Forwarding Detection [BFD], > defined by the IETF BFD working group, is a generic OAM mechanism > that can be deployed over various encapsulating protocols, and in > various medium types. The IETF has defined variants of the protocol > for IP ([BFD-IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for = PWE3 > [BFD-VCCV]. The usage of BFD in MPLS-TP is defined in [MPLS-TP-CC- > CV]. >=20 > BFD includes two main OAM functions, using two types of BFD = packets: > BFD Control packets, and BFD Echo packets. >=20 > 3.2.2. BFD Control >=20 > BFD supports a bidirectional continuity check, using BFD control > packets, that are exchanged within a BFD session. BFD sessions > operate in one of two modes: >=20 > o Asynchronous mode (i.e. proactive): in this mode BFD control > packets are sent periodically. When the receiver detects that no > BFD control packet have been received during a predetermined > period of time, a failure is detected. >=20 > o Demand mode: in this mode, BFD control packets are sent = on-demand. > Upon need, a system initiates a series of BFD control packets to > verify the liveness of the session. BFD control packets are sent > independently in each direction. >=20 > Each of the end-points of the monitored path maintains its own > session identification, called a Discriminator, both of which are > included in the BFD Control Packets that are exchanged between the > end-points. At the time of session establishment, the = Discriminators > are exchanged between the two-end points. In addition, the > transmission (and reception) rate is negotiated between the two = end- >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 17] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > points, based on information included in the control packets. = These > transmission rates may be renegotiated during the session. >=20 > During normal operation of the session, i.e. no failures are > detected, the BFD session is in the Up state. If no BFD Control > packets are received during a fixed period of time, called the >=20 > TOM: Fixed, pre-configured or negotiated period of time (i.e.: BFD = interval) >=20 > Detection Time, the session is declared to be Down. The detection > time is a function of the negotiated transmission time, and a > parameter called Detect Mult. Detect Mult determines the number of > missing BFD Control packets that cause the session to be declared = as > Down. This parameter is included in the BFD Control packet. >=20 > 3.2.3. BFD Echo >=20 > A BFD echo packet is sent to a peer system, and is looped back to = the > originator. The echo function can be used proactively, or = on-demand. >=20 > The BFD echo function has been defined in BFD for IPv4 and IPv6 > ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD = for > MPLS-TP. >=20 > 3.3. MPLS OAM >=20 > The IETF MPLS working group has defined OAM for MPLS LSPs. The > requirements and framework of this effort are defined in [MPLS-OAM- > FW] and [MPLS-OAM], respectively. The corresponding OAM mechanism > defined, in this context, is LSP Ping [LSP-Ping]. >=20 > LSP Ping is based on ICMP Ping and just like its predecessor may be > used in one of two modes: >=20 > o "Ping" mode: In this mode LSP ping is used for end-to-end > connectivity verification between two LERs. >=20 > o "Traceroute" mode: This mode is used for hop-by-hop fault > isolation. >=20 > LSP Ping extends the basic ICMP Ping operation (of data-plane > connectivity verification) with functionality to verify data-plane > vs. control-plane consistency for a Forwarding Equivalence Class > (FEC) and also Maximum Transmission Unit (MTU) problems. The > traceroute functionality may be used to isolate and localize the = MPLS > faults, using the Time-to-live (TTL) indicator to incrementally > identify the sub-path of the LSP that is successfully traversed > before the faulty link or node. >=20 >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 18] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > It should be noted that LSP Ping supports unique identification of > the LSP within an addressing domain. The identification is checked > using the full FEC identification. LSP Ping is easily extensible to > include additional information needed to support new functionality, > by use of Type-Length-Value (TLV) constructs. The usage of TLVs is > typically not easy to perform in hardware, and is thus typically > handled by the control plane. >=20 > LSP Ping supports both asynchronous, as well as, on-demand > activation. >=20 > 3.4. MPLS-TP OAM >=20 > 3.4.1. Overview >=20 > The MPLS working group is currently working on defining the OAM > toolset that fulfills the requirements for MPLS-TP OAM. The full = set > of requirements for MPLS-TP OAM are defined in [MPLS-TP-OAM], and > include both general requirements for the behavior of the OAM > mechanisms and a set of operations that should be supported by the > OAM toolset. The set of mechanisms required are further elaborated > in [TP-OAM-FW], which describes the general architecture of the OAM > system as well as giving overviews of the functionality of the OAM > toolset. >=20 > Some of the basic requirements for the OAM toolset for MPLS-TP are: >=20 > o MPLS-TP OAM must be able to support both an IP based and non-IP > based environment. If the network is IP based, i.e. IP routing = and > forwarding are available, then the MPLS-TP OAM toolset should = rely > on the IP routing and forwarding capabilities. On the other = hand, > in environments where IP functionality is not available, the OAM > tools must still be able to operate without dependence on IP > forwarding and routing. >=20 > o OAM packets and the user traffic are required to be congruent > (i.e. OAM packets are transmitted in-band) and there is a need = to > differentiate OAM packets from user-plane ones. Inherent in this > requirement is the principle that MPLS-TP OAM be independent of > any existing control-plane, although it should not preclude use = of > the control-plane functionality. >=20 > 3.4.2. Generic Associated Channel >=20 > In order to address the requirement for in-band transmission of = MPLS- > TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), > defined in [G-ACh] for LSP-based OAM traffic. This mechanism is = based >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 19] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > on the same concepts as the PWE3 ACH and VCCV mechanisms. However, > to address the needs of LSPs as differentiated from PW, the = following > concepts were defined for [G-ACh]: >=20 > o An Associated Channel Header (ACH), that uses a format similar to > the PW Control Word, is a 4-byte header that is prepended to OAM > packets. >=20 > o A Generic Associated Label (GAL). The GAL is a reserved MPLS = label > value (13) that indicates that the packet is an ACH packet and = the > payload follows immediately after the label stack. >=20 > 3.4.3. MPLS-TP OAM Toolset >=20 > To address the functionality that is required of the OAM toolset, = the > MPLS WG conducted an analysis of the existing IETF and ITU-T OAM > mechanisms and their ability to fulfill the required functionality. > The conclusions of this analysis are documented in [OAM-Analys]. = The > MPLS working group currently plans to use a mixture of OAM = mechanisms > that are based on various existing standards, and adapt them to the > requirements of [MPLS-TP-OAM]. Some of the main building blocks of > this solution are based on: >=20 > o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for > proactive continuity check and connectivity verification. >=20 > o LSP Ping as defined in [LSP-Ping] for on-demand connectivity > verification. >=20 > o New protocol packets, using G-ACH, to address different > functionality. >=20 > o Performance measurement protocols that are based on the > functionality that is described in [ITU-T-Y1731]. >=20 > The following sub-sections describe the OAM tools defined for = MPLS-TP > as described in [TP-OAM-FW]. >=20 > 3.4.3.1. Continuity Check and Connectivity Verification >=20 > Continuity Check and Connectivity Verification are presented in > Section 2.2.5. of this document. As presented there, these tools = may > be used either proactively or on-demand. When using these tools > proactively, they are generally used in tandem. >=20 > For MPLS-TP there are two distinct tools, the proactive tool is > defined in [TP-CC-CV] while the on-demand tool is defined in >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 20] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > [OnDemand-CV].Proactively [MPLS-TP-OAM] states that the function > should allow the MEPs to monitor the liveness and connectivity of a > transport path. In on-demand mode, this function should support > monitoring between the MEPs and, in addition, between a MEP and = MIP. > [TP-OAM-FW] highlights, when performing Connectivity Verification, > the need for the CC-V messages to include unique identification of > the MEG that is being monitored and the MEP that originated the > message. >=20 > The proactive tool [TP-CC-CV] is based on extensions to BFD (see > Section 3.2. ) with the additional limitation that the transmission > and receiving rates are based on configuration by the operator. = The > on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see > Section 3.3. ) for the required behavior of MPLS-TP. >=20 > 3.4.3.2. Route Tracing >=20 > [MPLS-TP-OAM] defines that there is a need for functionality that > would allow a path end-point to identify the intermediate and end- > points of the path. This function would be used in on-demand mode. > Normally, this path will be used for bidirectional PW, LSP, and > sections, however, unidirectional paths may be supported only if a > return path exists. The tool for this is based on the LSP Ping = (see > Section 3.3. ) functionality and is described in [OnDemand-CV]. >=20 > 3.4.3.3. Lock Instruct >=20 > The Lock Instruct function [Lock-Loop] is used to notify a = transport > path end-point of an administrative need to disable the transport > path. This functionality will generally be used in conjunction = with > some intrusive OAM function, e.g. Performance measurement, = Diagnostic > testing, to minimize the side-effect on user data traffic. >=20 > 3.4.3.4. Lock Reporting >=20 > Lock Reporting is a function used by an end-point of a path to = report > to its far-end end-point that a lock condition has been affected on > the path. >=20 > 3.4.3.5. Alarm Reporting >=20 > Alarm Reporting is a function used by an intermediate point of a > path, that becomes aware of a fault on the path, to report to the > end-points of the path. [TP-OAM-FW] states that this may occur as a > result of a defect condition discovered at a server sub-layer. This > generates an Alarm Indication Signal (AIS) that continues until the >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 21] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > fault is cleared. The consequent action of this function is = detailed > in [TP-OAM-FW]. >=20 > 3.4.3.6. Remote Defect Indication >=20 > Remote Defect Indication (RDI) is used proactively by a path end- > point to report to its peer end-point that a defect is detected on = a > bidirectional connection between them. [MPLS-TP-OAM] points out = that > this function may be applied to a unidirectional LSP only if there = a > return path exists. [TP-OAM-FW] points out that this function is > associated with the proactive CC-V function. >=20 > 3.4.3.7. Client Failure Indication >=20 > Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to = allow > the propagation information from one edge of the network to the > other. The information concerns a defect to a client, in the case > that the client does not support alarm notification. >=20 > 3.4.3.8. Packet Loss Measurement (LM) >=20 > Packet Loss Measurement is a function used to verify the quality of > the service. This function indicates the ratio of packets that are > not delivered out of all packets that are transmitted by the path > source. >=20 > There are two possible ways of determining this measurement: >=20 > o Using OAM packets, it is possible to compute the statistics based > on a series of OAM packets. This, however, has the disadvantage = of > being artificial, and may not be representative since part of = the > packet loss may be dependent upon packet sizes. >=20 > TOM: Not just packet sizes. Things like implementation (as I mentioned = above with the comment about the accuracy or truthfulness of the data = plane processing of OAM packets). Doing very accurate RTT as a simple = example, with just IP Pings, is a tricky thing to make work. Also, it = is important to mention that the scale in terms of number of packets, = number of tests, etc=85 can and will impact these parameters too. >=20 >=20 > o Sending delimiting messages for the start and end of a = measurement > period during which the source and sink of the path count the > packets transmitted and received. After the end delimiter, the > ratio would be calculated by the path OAM entity. >=20 > 3.4.3.9. Packet Delay Measurement (DM) >=20 > Packet Delay Measurement is a function that is used to measure one- > way or two-way delay of a packet transmission between a pair of the > end-points of a path (PW, LSP, or Section). Where: >=20 >=20 >=20 >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 22] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > o One-way packet delay is the time elapsed from the start of > transmission of the first bit of the packet by a source node = until > the reception of the last bit of that packet by the destination > node. >=20 > o Two-way packet delay is the time elapsed from the start of > transmission of the first bit of the packet by a source node = until > the reception of the last bit of the loop-backed packet by the > same source node, when the loopback is performed at the packet's > destination node. >=20 > Similarly to the packet loss measurement this could be performed in > either of the two ways outlined above. >=20 > 3.5. PWE3 OAM >=20 > 3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV) >=20 > VCCV, as defined in [VCCV], provides a means for end-to-end fault > detection and diagnostics tools to be extended for PWs (regardless = of > the underlying tunneling technology). The VCCV switching function > provides a control channel associated with each PW (based on the PW > Associated Channel Header (ACH) which is defined in [PW-ACH]), and > allows transmitting the OAM packets in-band with PW data (using CC > Type 1: In-band VCCV). >=20 > VCCV currently supports the following OAM mechanisms: ICMP Ping, = LSP > Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being > sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of > encapsulation - either IP/UDP encapsulated (with IP/UDP header) or > PW-ACH encapsulated (with no IP/UDP header) and provides support to > signal the AC status. The use of the VCCV control channel provides > the context, based on the MPLS-PW label, required to bind and > bootstrap the BFD session to a particular pseudo wire (FEC), > eliminating the need to exchange Discriminator values. >=20 > VCCV consists of two components: (1) signaled component to > communicate VCCV capabilities as part of VC label, and (2) = switching > component to cause the PW payload to be treated as a control = packet. >=20 > VCCV is not directly dependent upon the presence of a control = plane. > The VCCV capability negotiation may be performed as part of the PW > signaling when LDP is used. In case of manual configuration of the > PW, it is the responsibility of the operator to set consistent > options at both ends. >=20 > TOM: Might be helpful to note that the static mode was created = specifically to handle the MPLS-TP cases where no control plane was a = requirement. However, new use cases such as pure mobile backhaul, etc=85 = find this functionality useful too. >=20 >=20 >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 23] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > 3.5.2. PWE3 OAM using G-ACh >=20 > As mentioned above, VCCV enables OAM for PWs by using a control > channel for OAM packets. When PWs are used in MPLS-TP networks, > rather than the control channels defined in VCCV, the G-ACh can be > used as an alternative control channel. The usage of the G-ACh for > PWs is defined in [PW-G-ACh]. >=20 > 3.6. OWAMP and TWAMP >=20 > 3.6.1. Overview >=20 > The IPPM working group in the IETF defines common criteria and > metrics for measuring performance of IP traffic ([IPPM-FW]). Some = of > the key RFCs published by this working group have defined metrics = for > measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), > and packet loss [IPPM-1LM]. >=20 > Alternative protocols for performance measurement are defined, for > example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet > OAM [ITU-T-Y1731]. >=20 > The IPPM working group has defined not only metrics for performance > measurement, but also protocols that define how the measurement is > carried out. The One-way Active Measurement Protocol [OWAMP] and = the > Two-Way Active Measurement Protocol [TWAMP] define a method and > protocol for measuring delay and packet loss in IP networks. >=20 > OWAMP [OWAMP] enables measurement of one-way characteristics of IP > networks, such as one-way packet loss and one-way delay. For its > proper operation OWAMP requires accurate time of day setting at its > end points. >=20 > TWAMP [TWAMP] is a similar protocol that enables measurement of = two- > way (round trip) characteristics. TWAMP does not require accurate > time of day, and, furthermore, allows the use of a simple session > reflector, making it an attractive alternative to OWAMP. >=20 > OWAMP and TWAMP use two separate protocols: a Control plane = protocol, > and a Test plane protocol. >=20 > 3.6.2. Control and Test Protocols >=20 > OWAMP and TWAMP control protocols run over TCP, while the test > protocols run over UDP. The purpose of the control protocols is to > initiate, start, and stop test sessions, and for OWAMP to fetch > results. The test protocols introduce test packets (which contain >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 24] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > sequence numbers and timestamps) along the IP path under test > according to a schedule, and record statistics of packet arrival. > Multiple sessions may be simultaneously defined, each with a = session > identifier, and defining the number of packets to be sent, the = amount > of padding to be added (and thus the packet size), the start time, > and the send schedule (which can be either a constant time between > test packets or exponentially distributed pseudo-random). = Statistics > recorded conform to the relevant IPPM RFCs. >=20 > OWAMP and TWAMP test traffic is designed with security in mind. = Test > packets are hard to detect because they are simply UDP streams > between negotiated port numbers, with potentially nothing static in > the packets. OWAMP and TWAMP also include optional authentication > and encryption for both control and test packets. >=20 > 3.6.3. OWAMP >=20 > OWAMP defines the following logical roles: Session-Sender, Session- > Receiver, Server, Control-Client, and Fetch-Client. The Session- > Sender originates test traffic that is received by the Session- > Receiver. The Server configures and manages the session, as well = as > returning the results. The Control-Client initiates requests for > test sessions, triggers their start, and may trigger their > termination. The Fetch-Client requests the results of a completed > session. Multiple roles may be combined in a single host - for > example, one host may play the roles of Control-Client, = Fetch-Client, > and Session-Sender, and a second playing the roles of Server and > Session-Receiver. >=20 > In a typical OWAMP session the Control-Client establishes a TCP > connection to port 861 of the Server, which responds with a server > greeting message indicating supported security/integrity modes. The > Control-Client responds with the chosen communications mode and the > Server accepts the modes. The Control-Client then requests and = fully > describes a test session to which the Server responds with its > acceptance and supporting information. More than one test session > may be requested with additional messages. The Control-Client then > starts a test session and the Server acknowledges. The Session- > Sender then sends test packets with pseudorandom padding to the > Session-Receiver until the session is complete or until the = Control- > client stops the session. Once finished, the Fetch-Client sends a > fetch request to the server, which responds with an acknowledgement > and immediately thereafter the result data. >=20 >=20 >=20 >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 25] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > 3.6.4. TWAMP >=20 > TWAMP defines the following logical roles: session-sender, session- > reflector, server, and control-client. These are similar to the > OWAMP roles, except that the Session-Reflector does not collect any > packet information, and there is no need for a Fetch-Client. >=20 > In a typical TWAMP session the Control-Client establishes a TCP > connection to port 862 of the Server, and mode is negotiated as in > OWAMP. The Control-Client then requests sessions and starts them. > The Session-Sender sends test packets with pseudorandom padding to > the Session-Reflector which returns them with insertion of > timestamps. >=20 > 3.7. Summary of OAM Functions >=20 > Table 3 summarizes the OAM functions that are supported in each of > the categories that were analyzed in this section. >=20 > = +-----------+-------+--------+--------+-----------+-------+--------+ > | Standard |Continu|Connecti|Path |Defect |Perform|Other = | > | |ity |vity |Discover|Indications|ance = |Function| > | |Check |Verifica|y | |Monitor|s = | > | | |tion | | |ing | = | > = +-----------+-------+--------+--------+-----------+-------+--------+ > |IP Ping | |Echo | | | | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |IP | | |Tracerou| | | = | > |Traceroute | | |te | | | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |BFD |BFD |BFD | | | | = | > | |Control|Echo | | | | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |MPLS OAM | |"Ping" |"Tracero| | | = | > |(LSP Ping) | |mode |ute" | | | = | > | | | |mode | | | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |MPLS-TP |CC |CV/pro- |Route |-Alarm |-LM = |-Diagnos| > |OAM | |active |Tracing | Reporting |-DM | tic = Tes| > | | |or on- | |-Client | | t = | > | | |demand | | Failure | |-Lock = | > | | | | | Indication| | = | > | | | | |-Remote | | = | >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 26] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > | | | | | Defect | | = | > | | | | | Indication| | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |PWE3 OAM |BFD |-BFD |LSP-Ping| | | = | > | | |-ICMP | | | | = | > | | | Ping | | | | = | > | | |-LSP- | | | | = | > | | | Ping | | | | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |OWAMP and | | | | |-Delay | = | > |TWAMP | | | | | measur| = | > | | | | | | ement | = | > | | | | | |-Packet| = | > | | | | | | loss | = | > | | | | | | measur| = | > | | | | | | ement | = | > = +-----------+-------+--------+--------+-----------+-------+--------+ > Table 3 Summary of OAM Functions >=20 > 4. Security Considerations >=20 > This memo presents an overview of existing OAM mechanisms, and > proposes no new OAM mechanisms. Therefore, this document introduces > no security considerations. However, the OAM mechanism reviewed in > this document can and do present security issues. The reader is > encouraged to review the Security Considerations section of each > document reference by this memo. >=20 > 5. IANA Considerations >=20 > There are no new IANA considerations implied by this document. >=20 > 6. Acknowledgments >=20 > The authors gratefully acknowledge Sasha Vainshtein, Carlos > Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other > members of the OPSAWG mailing list for their helpful comments. >=20 > This document was prepared using 2-Word-v2.0.template.dot. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 27] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > 7. References >=20 > 7.1. Normative References >=20 > [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol > Label Switched (MPLS) Data Plane Failures", RFC 4379, > February 2006. >=20 > [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., > Matsushima, S., "Operations and Management (OAM) > Requirements for Multi-Protocol Label Switched (MPLS) > Networks", RFC 4377, February 2006. >=20 > [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for = Multi-Protocol > Label Switching (MPLS) Operations and Management > (OAM)", RFC 4378, February 2006. >=20 > [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for > Multiprotocol Label Switching Architecture (MPLS) > Operation and Maintenance (OAM) Functions", RFC 3429, > November 2002. >=20 > [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for > OAM in MPLS Transport Networks", RFC 5860, May 2010. >=20 > [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic > Associated Channel", RFC 5586, June 2009. >=20 > [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual = Circuit > Connectivity Verification (VCCV): A Control Channel > for Pseudowires", RFC 5085, December 2007. >=20 > [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., > "Pseudowire Emulation Edge-to-Edge (PWE3) Control = Word > for Use over an MPLS PSN", RFC 4385, February 2006. >=20 > [ICMPv4] Postel, J., "Internet Control Message Protocol", STD = 5, > RFC 792, September 1981. >=20 > [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet = Control > Message Protocol (ICMPv6) for the Internet Protocol > Version 6 (IPv6) Specification", RFC 4443, March = 2006. >=20 > [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T., > "Operations and Management (OAM) Requirements for > Point-to-Multipoint MPLS Networks", RFC 4687, > September 2006. >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 28] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP > Extensions for Multiprotocol Label Switching", RFC > 4950, August 2007. >=20 > [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro, C., > "Extended ICMP to Support Multi-Part Messages", RFC > 4884, April 2007. >=20 > [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., = Rivers, > JR., "Extending ICMP for Interface and Next-Hop > Identification", RFC 5837, April 2010. >=20 > [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and > TCP/IP Tools and Utilities", RFC 2151, June 1997. >=20 > [NetTools] Stine, R., "FYI on a Network Management Tool Catalog: > Tools for Monitoring and Debugging TCP/IP Internets > and Interconnected Devices", RFC 1147, April 1990. >=20 > [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., > "Framework for IP Performance Metrics", RFC 2330, May > 1998. >=20 > [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring > Connectivity", RFC 2678, September 1999. >=20 > [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way > Delay Metric for IPPM", RFC 2679, September 1999. >=20 > [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way > Packet Loss Metric for IPPM", RFC 2680, September > 1999. >=20 > [IPPM-2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A = Round-trip > Delay Metric for IPPM", RFC 2681, September 1999. >=20 > [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., = and > Zekauskas, M., "A One-way Active Measurement Protocol > (OWAMP)", RFC 4656, September 2006. >=20 > [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and > Babiarz, J., "A Two-Way Active Measurement Protocol > (TWAMP)", RFC 5357, October 2008. >=20 > [BFD] Katz, D., Ward, D., "Bidirectional Forwarding = Detection > (BFD)", RFC 5880, June 2010. >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 29] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding = Detection > (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June > 2010. >=20 > [BFD-Gen] Katz, D., Ward, D., "Generic Application of > Bidirectional Forwarding Detection (BFD)", RFC 5882, > June 2010. >=20 > [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding = Detection > (BFD) for Multihop Paths", RFC 5883, June 2010. >=20 > [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, > G., "Bidirectional Forwarding Detection (BFD) for = MPLS > Label Switched Paths (LSPs)", RFC 5884, June 2010. >=20 > [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding > Detection (BFD) for the Pseudowire Virtual Circuit > Connectivity Verification (VCCV)", RFC 5885, June > 2010. >=20 > [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration and > Maintenance Framework for MPLS-based Transport > Networks ", RFC 6371, September 2011. >=20 > [TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive > Connectivity Verification, Continuity Check and = Remote > Defect indication for MPLS Transport Profile", RFC > 6428, November 2011. >=20 > [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. = "MPLS > On-Demand Connectivity Verification and Route > Tracing", RFC 6426, November 2011. >=20 > [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay > Measurement for MPLS Networks", RFC 6374, September > 2011. >=20 > [TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay > Measurement Profile for MPLS-Based Transport > Networks", RFC 6375, September 2011. >=20 > [TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, = S., > "MPLS Fault Management Operations, Administration, = and > Maintenance (OAM)", RFC 6427, November 2011. >=20 >=20 >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 30] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, > M., Dai, X., "MPLS Transport Profile Lock Instruct = and > Loopback Functions", RFC 6435, November 2011. >=20 > [ITU-T-CT] Betts, M., "Allocation of a Generic Associated = Channel > Type for ITU-T MPLS Transport Profile Operation, > Maintenance, and Administration (MPLS-TP OAM)", RFC > 6671, November 2012. >=20 > [PW-Map] M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. > Nadeau, "Pseudowire (PW) Operations, Administration, > and Maintenance (OAM) Message Mapping", RFC 6310, = July > 2011. >=20 > [PW-G-ACh] Li, H., Martini, L., He, J., Huang, F., "Using the > Generic Associated Channel Label for Pseudowire in = the > MPLS Transport Profile (MPLS-TP)", RFC 6423, November > 2011. >=20 > 7.2. Informative References >=20 > [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., = Romascanu, > D., Mansfield, S., "Guidelines for the use of the OAM > acronym in the IETF ", RFC 6291, June 2011. >=20 > [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool > Set for MPLS based Transport Networks", RFC 6669, > July 2012. >=20 > [TP-Term] Van Helvoort, H., Andersson, L., Sprecher, N., "A > Thesaurus for the Terminology used in Multiprotocol > Label Switching Transport Profile (MPLS-TP) > drafts/RFCs and ITU-T's Transport Network > Recommendations", work-in-progress, draft-ietf-mpls- > tp-rosetta-stone, July 2012. >=20 > [IEEE802.1ag] IEEE 802.1Q, "IEEE Standard for Local and = metropolitan > area networks - Media Access Control (MAC) Bridges = and > Virtual Bridged Local Area Networks", October 2012. >=20 > [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions = and > Mechanisms for Ethernet-based Networks", July 2011. >=20 > [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance > mechanism for MPLS networks", February 2004. >=20 >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 31] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology = - > Local and metropolitan area networks - Carrier sense > multiple access with collision detection (CSMA/CD) > access method and physical layer specifications", > clause 57, December 2008. >=20 > [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of > transport equipment - Description methodology and > generic functionality", January 2009. >=20 > [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, > administration and maintenance mechanisms for MPLS-TP > networks using the tools defined for MPLS", November > 2012. >=20 > [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, > Administration and Maintenance mechanism for MPLS-TP > in Packet Transport Network (PTN)", November 2012. >=20 >=20 >=20 > Authors' Addresses >=20 > Tal Mizrahi > Marvell > 6 Hamada St. > Yokneam, 20692 > Israel >=20 > Email: talmi@marvell.com >=20 >=20 > Nurit Sprecher > Nokia Siemens Networks > 3 Hanagar St. Neve Ne'eman B > Hod Hasharon, 45241 > Israel >=20 > Email: nurit.sprecher@nsn.com >=20 >=20 > Elisa Bellagamba > Ericsson > 6 Farogatan St. > Stockholm, 164 40 > Sweden >=20 >=20 >=20 > Mizrahi, et al. Expires July 9, 2013 [Page 32] > Internet-Draft Overview of OAM Mechanisms January 2013 >=20 >=20 > Phone: +46 761440785 > Email: elisa.bellagamba@ericsson.com >=20 >=20 > Yaacov Weingarten > 34 Hagefen St. > Karnei Shomron, 4485500 > Israel >=20 > Email: wyaacov@gmail.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> draft-ietf-opsawg-oam-overview authors, >>=20 >> Here is my feedback on this document. >>=20 >> 1. >> Is this document in line with = http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?=20 >> * For example, the following definitions could be reused. >> Fault: The term Fault refers to an inability to perform a required >> action, e.g., an unsuccessful attempt to deliver a packet. >>=20 >> Defect: The term Defect refers to an interruption in the normal >> operation, such that over a period of time no packets are = delivered >> successfully. >>=20 >> Failure: The term Failure refers to the termination of the = required >> function over a longer period of time. Persistence of a defect for = a >> period of time is interpreted as a failure. >>=20 >> * For example, on the basic abstract=20 >> Abstract >>=20 >> Operations, Administration, and Maintenance (OAM) is a general = term >> that refers to a toolset that can be used for fault detection and >> isolation, and for performance measurement. OAM mechanisms have = been >> defined for various layers in the protocol stack, and are used = with a >> variety of protocols. >>=20 >> Abstract (draft-ietf-trill-oam-req-04) >>=20 >> OAM (Operations, Administration and Maintenance) is a general term >> used to identify functions and toolsets to troubleshoot and = monitor >> networks. This document presents, OAM Requirements applicable to >> TRILL.=20 >>=20 >> So, as an example: does OAM include function?=20 >> I advice to review draft-ietf-trill-oam-req-04 >>=20 >> 2.=20 >> draft-ietf-trill-oam is not mentioned, while the abstract mentions: >> This document presents an overview of the OAM mechanisms that have >> been defined and are currently being defined by the IETF. >> Search for OAM in the current draft names = (https://datatracker.ietf.org/), and you will find many references. >> Ok, I see later on:=09 >> This document focuses on IETF >> documents that have been published as RFCs, while other ongoing = OAM- >> related work is outside the scope. >> Ok, fine then: we don't need a reference to all the drafts.=20 >> However, draft-ietf-trill-oam is closed to be a RFC, and should be = mentioned. >>=20 >>=20 >> 3. >> Section 1 >> The term OAM in this document refers to Operations, Administration >> and Maintenance [OAM-Def], focusing on the forwarding plane of = OAM. >> What does it mean "focusing on the forwarding plane of OAM"? >> Do you take a subset of the definition for this document? >> Btw, I don't see a definition in the terminology section. >> In section 2.2.3 >> A Maintenance Point (MP) is a functional entity that is defined at = a >> node in the network, and either initiates or reacts to OAM = messages. >> Which plane is MP? >>=20 >> 4. >> Section 1, Introduction >> "Hence, management aspects are outside the scope of this document." >> I don't understand which management aspects we speak about here. >> 5. >> Clarifying question regarding 1.2 >> If speak about OWAMP or TWAMP 'synthetic traffic), is that data = plane, control plane, or management plane? >> Note that I found later on in the draft: >> OWAMP and TWAMP use two separate protocols: a Control plane = protocol, >> and a Test plane protocol. >> Interestingly enough, after reading the document, I reviewed = http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, = and saw the same feedback from Stewart Bryant: >> Provide a clear view of OAM functionality and its relationship >> to various =93planes=94 of networking (data plane, control plane, >> management plane). In particular, the importance of >> fate-sharing of OAM and user traffic flows in packet networks >> should be explained. >> 6. >> I see a multiplication of "plane" terms in the IETF document, and in = this document in particular. >> I could find: forwarding plane, management plane, control plane, data = plane, user plane, and test plane. >> Way too many. >> Please be consistent >> 7. >> Table 1 summarizes the IETF OAM related RFCs discussed in this >> document. >>=20 >> Table 2 summarizes the OAM standards mentioned in this document.=20= >>=20 >> You need to change the Table 2 description. Do you want to say = something along the lines of: >> Table 2 summarizes the OAM standards specified by other Standard = Development Organization=20 >> (SDO) than the IETF, along with IETF references where applicable. >>=20 >>=20 >> 8. >> Section 2.2.1 >> For a formal definition of each term, refer to the references at = the end of >> this document. >> Without a reference to a specific RFC, this is the type of statement = which is not useful: you have 5 pages of references. >> You position this document as "An Overview of Operations, = Administration, and Maintenance (OAM) Mechanisms", but you tell the = reader: "if you want to know about the terms, >> just read first all references!" >>=20 >> 9. >> You specify some terms and some OAM categories,=20 >> 2.2.2. OAM Maintenance Entities .......................... 13 >> 2.2.3. OAM Maintenance Points ............................ = 14 >> 2.2.4. Proactive and On-demand activation ................ = 15 >> 2.2.5. Connectivity Verification and Continuity Checks ... = 15 >> 2.2.6. Failures .......................................... = 15 >> ... but you don't use them in the section 3 >>=20 >> Just one example with section 3.2.2 >> - >> o Demand mode: in this mode, BFD control packets are sent = on-demand. >> Upon need, a system initiates a series of BFD control packets = to >> verify the liveness of the session >> Instead of liveness, you have defined Connectivity Verification and = Continuity Checks in section 2.2.5 >> - OLD: >> Each of the end-points of the monitored path maintains its own >> session identification >> NEW: >> Each of the MEP maintains its own session identification >> OR NEW (actually I don't know) >> Each of the MP maintains its own session identification >> - OLD >> A BFD echo packet is sent to a peer system >> Peer system =3D MEP, MP, or something else? >> - etc...=20 >>=20 >> 10.=20 >> This document is composed of a list of OAM content and references, = but I'm really missing the document "scope and target audience". >> When we did RFC 6632, which is the companion document, we had = http://tools.ietf.org/html/rfc6632#section-1.1 >> =20 >> The target audience of the document is, on the one hand, IETF = working >> groups, which aim to select appropriate standard management = protocols >> and data models to address their needs concerning network = management. >> On the other hand, the document can be used as an overview and >> guideline by non-IETF Standards Development Organizations (SDOs) >> planning to use IETF management technologies and data models for = the >> realization of management applications. The document can also be >> used to initiate a discussion between the bodies with the goal to >> gather new requirements and to detect possible gaps. Finally, = this >> document is directed to all interested parties that seek to get an >> overview of the current set of the IETF network management = protocols >> such as network administrators or newcomers to the IETF. >>=20 >> You should have something similar. >>=20 >>=20 >> 11. >> Section 3.6.1, put the paragraph 2 at the end of the section. The = "alternative" in the following sentence would then make sense >> Alternative protocols for performance measurement are defined, for >> example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in = Ethernet >> OAM [ITU-T-Y1731]. >>=20 >>=20 >> My conclusions: this document still needs some work >>=20 >> Regards, Benoit >> =20 >>> The IESG has received a request from the Operations and Management = Area >>> Working Group WG (opsawg) to consider the following document: >>> - 'An Overview of Operations, Administration, and Maintenance (OAM) >>> Mechanisms' >>> as Informational RFC >>>=20 >>> The IESG plans to make a decision in the next few weeks, and = solicits >>> final comments on this action. Please send substantive comments to = the >>> ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments = may be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>>=20 >>> Abstract >>>=20 >>>=20 >>> Operations, Administration, and Maintenance (OAM) is a general = term >>> that refers to a toolset that can be used for fault detection and >>> isolation, and for performance measurement. OAM mechanisms have = been >>> defined for various layers in the protocol stack, and are used = with a >>> variety of protocols. >>>=20 >>> This document presents an overview of the OAM mechanisms that = have >>> been defined and are currently being defined by the IETF. >>>=20 >>>=20 >>>=20 >>>=20 >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ >>>=20 >>> IESG discussion can be tracked via >>> = http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ >>>=20 >>>=20 >>> No IPR declarations have been submitted directly on this I-D. >>>=20 >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_37D55104-A690-4711-87D5-FDCA45807A2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Reviewing the current version of = the draft (12), many of the comments below are still not = addressed.

= --Tom



=20 =20
Here is Tom Nadeau's feedback, forwarded with permission:

Regards, Benoit

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Some general comments:

  1. I did not find any discussion around use of configuration within OAM mechanisms. This is clearly something that is happening in groups like PWE3 and CCAMP. The motivation for this should be explained and documented to at least guide these efforts.
2. There is no real discussion around the security aspects of these tools. Should there be?

3. While the document provides a nice taxonomy of various OAM tools, it does not really discuss the techniques for using them. I do not expect anything in detail, but it is not obvious that many of these tools can be orchestrated to form a "toolset" that can be used to do multi-layer OAM functions for services such as carrier Ethernet over VPLS over MPLS, for example.

4. It might be useful to at least mention in the performance metrics section, a discussion around the accuracy of these tools and how it depends on scale, implementation and network configurations.


My detailed comments inline starting with TOM:

--Tom






Expires: July 2013           =                     =  Nokia Siemens Networks
                =                     =                        E. Bellagamba
                =                     =                             Ericsson
                =                     =                        Y. Weingarten

                =                     =                      January 9, 2013

                =               An Overview of
        Operations, Administration, = and Maintenance (OAM) Mechanisms
                =    draft-ietf-opsawg-oam-overview-08.txt


Abstract

   Operations, Administration, and = Maintenance (OAM) is a general term
   that refers to a toolset that can be used = for fault detection and
   isolation, and for performance = measurement. OAM mechanisms have been
   defined for various layers in the protocol = stack, and are used with a
   variety of protocols.

   This document presents an overview of the = OAM mechanisms that have
   been defined and are currently being = defined by the IETF.

Status of this Memo

   This Internet-Draft is submitted to IETF = in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of = the Internet Engineering
   Task Force (IETF), its areas, and its = working groups.  Note that
   other groups may also distribute working = documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid = for a maximum of six months
   and may be updated, replaced, or obsoleted = by other documents at any
   time.  It is inappropriate to use = Internet-Drafts as reference
   material or to cite them other than as = "work in progress."

   The list of current Internet-Drafts can be = accessed at

   The list of Internet-Draft Shadow = Directories can be accessed at

   This Internet-Draft will expire on July 9, = 2013.



Mizrahi, et al.         Expires = July 9, 2013                  [Page 1]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


Copyright Notice

   Copyright (c) 2013 IETF Trust and the = persons identified as the
   document authors. All rights = reserved.

   This document is subject to BCP 78 and the = IETF Trust's Legal
   Provisions Relating to IETF = Documents
   publication of this document. Please = review these documents
   carefully, as they describe your rights = and restrictions with respect
   to this document. Code Components = extracted from this document must
   include Simplified BSD License text as = described in Section 4.e of
   the Trust Legal Provisions and are = provided without warranty as
   described in the Simplified BSD = License.

Table of Contents


   1. Introduction ................................................. 3
      1.1. The Building Blocks of OAM .............................. 3
      1.2. Forwarding Plane vs. = Management Plane ................... 4
      1.3. The OAM toolsets ........................................ 4
      1.4. IETF OAM Documents ...................................... 6
      1.5. Non-IETF OAM Documents ................................. 10
   2. Basic Terminology ........................................... 12
      2.1. Abbreviations .......................................... 12
      2.2. Terminology used in OAM = Standards ...................... 13
         2.2.1. General Terms ..................................... 13
         2.2.2. OAM = Maintenance Entities .......................... 13
         2.2.3. OAM = Maintenance Points ............................ 14
         2.2.4. Proactive and = On-demand activation ................ 15
         2.2.5. Connectivity = Verification and Continuity Checks ... 15
         2.2.6. Failures .......................................... 15
   3. OAM Tools ................................................... = 16
      3.1. IP Ping and Traceroute ................................. 16
         3.1.1. Ping .............................................. 16
         3.1.2. Traceroute......................................... = 16
      3.2. Bidirectional Forwarding = Detection (BFD) ............... 17
         3.2.1. Overview .......................................... 17
         3.2.2. BFD Control ....................................... 17
         3.2.3. BFD Echo .......................................... 18
      3.3. MPLS OAM ............................................... 18
      3.4. MPLS-TP OAM ............................................ 19
         3.4.1. Overview .......................................... 19
         3.4.2. Generic = Associated Channel ........................ 19
         3.4.3. MPLS-TP OAM = Toolset ............................... 20
            3.4.3.1. = Continuity Check and Connectivity Verification 20


Mizrahi, et al.         Expires = July 9, 2013                  [Page 2]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


            3.4.3.2. = Route Tracing ................................ 21
            3.4.3.3. Lock = Instruct ................................ 21
            3.4.3.4. Lock = Reporting ............................... 21
            3.4.3.5. = Alarm Reporting .............................. 21
            3.4.3.6. = Remote Defect Indication ..................... 22
            3.4.3.7. = Client Failure Indication .................... 22
            3.4.3.8. = Packet Loss Measurement (LM) ................. 22
            3.4.3.9. = Packet Delay Measurement (DM) ................ 22
      3.5. PWE3 OAM ............................................... 23
         3.5.1. PWE3 OAM using = Virtual Circuit Connectivity Verification
         (VCCV) ................................................... = 23
         3.5.2. PWE3 OAM using = G-ACh .............................. 24
      3.6. OWAMP and TWAMP......................................... 24
         3.6.1. Overview .......................................... 24
         3.6.2. Control and = Test Protocols ........................ 24
         3.6.3. OWAMP ............................................. 25
         3.6.4. TWAMP ............................................. 26
      3.7. Summary of OAM Functions ............................... 26
   4. Security Considerations ..................................... 27
   5. IANA Considerations ......................................... 27
   6. Acknowledgments ............................................. 27
   7. References .................................................. = 28
      7.1. Normative References ................................... 28
      7.2. Informative References ................................. 31

1. Introduction

   OAM is a general term that refers to a = toolset for detecting,
   isolating and reporting connection = failures and performance
   degradation.

   This document summarizes the OAM tools and mechanisms defined in the
   IETF.

   The term OAM in this document refers to = Operations, Administration
   and Maintenance [OAM-Def], focusing on the forwarding plane of OAM.
   Hence, management aspects are outside the = scope of this document.

TOM: This is a curious sentence to me since to me, OAM is management, or a subset of it.   Also, if you look at the referenced documents, there are many indirect references to MIBs, Netconf, etc=85 making this sentence further confusing. It might be helpful to explain more clearly that the authors here intended to not cover those things explicitly rather than grouping them arbitrarily under the definition of "management aspects"  Further, to clarify, it might be useful to expand = on what "forwarding plane" is here just to be clear.   That = is, is this "in band" or "out-of band" or both? Some of the tools referred to here also are part of the control AND data = planes. 

1.1. The Building Blocks of OAM

   An OAM protocol is run in the context of a Maintenance Domain,
   consisting of two or more nodes that run = the OAM protocol, referred
   to as Maintenance Points (MP).

   This subsection provides a brief summary = of the common tools used by
   OAM protocols. An OAM protocol typically = supports one or more of the
   tools described below.


Mizrahi, et al.         Expires = July 9, 2013                  [Page 3]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   o Continuity Checking (CC):
      Used for verifying the liveness of = a connection between two MPs.

   o Connectivity Verification (CV):
      Allows an MP to check whether it = is connected to a peer MP, and to
      verify that messages from the peer = MP are received through the
      expected path.

   o Path Discovery / Fault = Localization:
      An MP uses this mechanism to trace = the route to a peer MP, i.e.,
      to identify the nodes along the = path to the peer MP. When a
      connection fails, this mechanism = also allows the MP to detect the
      location of the failure.

TOM: The definition calls this "path discovery" but then talks about tracing routes. A better way of describing this in the paragraph would be that there I a use of path tracing in order to discover (or re-discover) paths that have been changed, created or destroyed.  


   o Performance Monitoring:
      Consists of 3 main functions

        o Loss Measurement (LM) - = monitors the packet loss rate of a
          connection.

        o Delay Measurement (DM) - = monitors the delay and delay
          variation between = MPs.

        o Throughput measurement - = monitors the throughput of a
          connection.

TOM: Along with the discussion above around path trace/discovery, it is imperative that paths be discovered (one way or another) in order to successfully d performance monitoring on those paths.

1.2. Forwarding Plane vs. Management Plane

   While the OAM tools may, and quite often = do, work in conjunction with
   a control-plane or management plane, they = are usually defined to be
   independent of the control-plane. =  The OAM tools communicate with the
   management plane to raise alarms, and = often the on-demand tools may
   be activated by the management, e.g. to = locate and localize problems.

   The considerations of the control-plane = maintenance tools or the
   functionality of the management-plane are = out of scope for this
   document, which will concentrate on = presenting the forwarding-plane
   tools that are used for OAM.

TOM: What about the data plane? For example, the GACH OAM type is such an example. VCCV also operates within the data plane after its configuration capabilities have been signaled.  It should also be mentioned that it is imperative that = when required, OAM tools are capable of testing the actual data plane in as much accuracy as possible, but that they all should note how accurate.   Not all OAM tools are created equal.


1.3. The OAM toolsets

   This memo provides an overview of the = different sets of OAM
   mechanisms defined by the IETF. It is = intended for those with little
   or no familiarity with the described = mechanisms. The set of OAM
   mechanisms described in this memo are = applicable to IP unicast, MPLS,
   pseudowires, and MPLS for the transport = environment (MPLS-TP). While
   OAM mechanisms that are applicable to = other technologies exist, they


Mizrahi, et al.         Expires = July 9, 2013                  [Page 4]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   are beyond the scope of this memo. This = document focuses on IETF
   documents that have been published as = RFCs, while other ongoing OAM-
   related work is outside the scope.

   The IETF has defined OAM protocols and = mechanisms in several
   different fronts:

   o IP Ping and Traceroute:
      Ping is a very simple and common = application for failure diagnosis

TOM: I am not sure the term "common" is necessary.

      that uses ICMP Echo requests, as = defined in [ICMPv4], and
      [ICMPv6].
      Traceroute ([TCPIP-Tools], = [NetTools]) is an application that
      allows users to trace the path = between an IP source and an IP
      destination, i.e., to identify the = nodes along the path.

   o BFD:
      Bidirectional Forwarding Detection = (BFD) is defined in [BFD] as a
      framework for a lightweight = generic OAM mechanism.  The intention
      is to define a base mechanism that = can be used with various
      encapsulation types, network = environments, and in various medium
      types.

   o MPLS OAM:
      MPLS LSP Ping, as defined in = [MPLS-OAM], [MPLS-OAM-FW] and [LSP-
      Ping], is an OAM mechanism for = point to point MPLS LSPs. It
      includes two main functions: Ping = and Traceroute.

   o MPLS-TP OAM:
      MPLS-TP OAM is defined in a set of = RFCs. The OAM requirements for
      MPLS Transport Profile (MPLS-TP) = are defined in [MPLS-TP-OAM].
      Each of the tools in the OAM = toolset is defined in its own RFC, as
      specified in Section 1.4.

   o PWE3 OAM:
      The PWE3 OAM architecture defines = control channels that support
      the use of existing IETF OAM tools = to be used for a pseudowire
      (PW).  The control channels = that are defined in [VCCV] and [PW-G-
      ACH] may be used in conjunction = with ICMP Ping, LSP Ping, and BFD
      to perform CC and CV = functionality.  In addition the channels
      support use of any of the MPLS-TP = based OAM tools for completing
      their respective OAM functionality = for a PW.

   o OWAMP and TWAMP:
      The One Way Active Measurement = Protocol (OWAMP) and the Two Way
      Active Measurement Protocols = (TWAMP) are two protocols defined in
      the IP Performance Metrics (IPPM) = working group in the IETF. These
      protocols allow delay and packet = loss measurement in IP networks.


Mizrahi, et al.         Expires = July 9, 2013                  [Page 5]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   This document summarizes the OAM = mechanisms defined by the IETF. We
   first present a comparison of the = terminology used in various OAM
   standards, and then summarize the OAM = functions that each OAM
   standard provides.

1.4. IETF OAM Documents

   Table 1 summarizes the IETF OAM related = RFCs discussed in this
   document.

   The table includes a "Type" column, = specifying the nature of each of
   the listed documents:

   o Tool: documents that define an OAM tool = or mechanism.

   o Prof.: documents that define a profile = or a variant for an OAM
      tool that is defined in other = documents.

   o Inf.: documents that define an = infrastructure that is used by OAM
      tools.

   o Misc.: other OAM related documents, = e.g., OAM requirement and
      framework documents.

  =  +-----------+--------------------------------------+-----+----------= +
   |           | = Title                   =              |Type | RFC      |
  =  +-----------+--------------------------------------+-----+----------= +
   |IP Ping and| Internet Control Message = Protocol    |Tool | RFC 792  |
   |Traceroute | [ICMPv4]     =                     =     |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Internet Control Message Protocol    |Tool | RFC 4443 |
   |           | = (ICMPv6) for the Internet Protocol   |     |          |
   |           | = Version 6 (IPv6) Specification       |     |          |
   |           | = [ICMPv6]                   =           |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | A = Primer On Internet and TCP/IP      |Tool | RFC 2151 |
   |           | = Tools and Utilities [TCPIP-Tools]    |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | FYI = on a Network Management Tool     |Tool | RFC 1147 |
   |           | = Catalog: Tools for Monitoring and    |     |          |
   |           | = Debugging TCP/IP Internets and       |     |          |
   |           | = Interconnected Devices [NetTools]    |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Extended ICMP to Support Multi-Part  |Tool | RFC 4884 |


Mizrahi, et al.         Expires = July 9, 2013                  [Page 6]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   |           | = Messages [ICMP-MP]               =     |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = ICMP Extensions for Multiprotocol    |Tool | RFC 4950 |
   |           | = Label Switching [ICMP-Ext]           |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Extending ICMP for Interface and     |Tool | RFC 5837 |
   |           | = Next-Hop Identification [ICMP-Int]   |     |          |
  =  +-----------+--------------------------------------+-----+----------= +
   |BFD        | = Bidirectional Forwarding Detection   |Tool | RFC 5880 |
   |           | = [BFD]                   =              |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Bidirectional Forwarding Detection   |Prof.| RFC 5881 |
   |           | = (BFD) for IPv4 and IPv6 (Single Hop) |     |          |
   |           | = [BFD-IP]                   =           |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Generic Application of Bidirectional |Misc.| RFC 5882 |
   |           | = Forwarding Detection [BFD-Gen]       |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Bidirectional Forwarding Detection   |Prof.| RFC 5883 |
   |           | = (BFD) for Multihop Paths [BFD-Multi] |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Bidirectional Forwarding Detection   |Prof.| RFC 5884 |
   |           | for = MPLS Label Switched Paths (LSPs) |     |          |
   |           | = [BFD-LSP]                   =          |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Bidirectional Forwarding Detection   |Prof.| RFC 5885 |
   |           | for = the Pseudowire Virtual Circuit   |     |          |
   |           | = Connectivity Verification (VCCV)     |     |          |
   |           | = [BFD-VCCV]                 =           |     |          |
  =  +-----------+--------------------------------------+-----+----------= +
   |MPLS OAM   | Operations and = Management (OAM)      |Misc.| RFC 4377 |
   |           | = Requirements for Multi-Protocol Label|     |          |
   |           | = Switched (MPLS) Networks [MPLS-OAM]  |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | A = Framework for Multi-Protocol       |Misc.| RFC 4378 |
   |           | = Label Switching (MPLS) Operations    |     |          |
   |           | and = Management (OAM) [MPLS-OAM-FW]   |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Detecting Multi-Protocol Label       |Tool | RFC 4379 |
   |           | = Switched (MPLS) Data Plane Failures  |     |          |
   |           | = [LSP-Ping]                 =           |     |          |


Mizrahi, et al.         Expires = July 9, 2013                  [Page 7]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   |           = +--------------------------------------+-----+----------+
   |           | = Operations and Management (OAM)      |Misc.| RFC 4687 |
   |           | = Requirements for Point-to-Multipoint |     |          |
   |           | = MPLS Networks [MPLS-P2MP]            |     |          |
  =  +-----------+--------------------------------------+-----+----------= +
   |MPLS-TP    | Requirements for = OAM in MPLS-TP      |Misc.| RFC 5860 |
   |OAM        | = [MPLS-TP-OAM]                 =        |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = MPLS Generic Associated Channel      |Inf. | RFC 5586 |
   |           | = [G-ACh]                   =            |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = MPLS-TP OAM Framework                |Misc.| RFC 6371 |
   |           | = [TP-OAM-FW]                 =          |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Proactive Connectivity Verification, |Tool | RFC 6428 |
   |           | = Continuity Check, and Remote Defect  |     |          |
   |           | = Indication for the MPLS Transport    |     |          |
   |           | = Profile [TP-CC-CV]               =     |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = MPLS On-Demand Connectivity          |Tool | RFC 6426 |
   |           | = Verification and Route Tracing       |     |          |
   |           | = [OnDemand-CV]                 =        |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = MPLS Fault Management Operations,    |Tool | RFC 6427 |
   |           | = Administration, and Maintenance (OAM)|     |          |
   |           | = [TP-Fault]                 =           |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = MPLS Transport Profile Lock Instruct |Tool | RFC 6435 |
   |           | and = Loopback Functions [Lock-Loop]   |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Packet Loss and Delay Measurement for|Tool | RFC 6374 |
   |           | = MPLS Networks [MPLS-LM-DM]           |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | A = Packet Loss and Delay Measurement  |Prof.| RFC 6375 |
   |           | = Profile for MPLS-Based Transport     |     |          |
   |           | = Networks [TP-LM-DM]               =    |     |          |
  =  +-----------+--------------------------------------+-----+----------= +
   |PWE3 OAM   | Pseudowire Virtual = Circuit           |Inf. | RFC 5085 |
   |           | = Connectivity Verification (VCCV):    |     |          |
   |           | A = Control Channel for Pseudowires    |     |          |
   |           | = [VCCV]                   =             |     |          |


Mizrahi, et al.         Expires = July 9, 2013                  [Page 8]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   |           = +--------------------------------------+-----+----------+
   |           | = Bidirectional Forwarding Detection   |Prof.| RFC 5885 |
   |           | for = the Pseudowire Virtual Circuit   |     |          |
   |           | = Connectivity Verification (VCCV)     |     |          |
   |           | = [BFD-VCCV]                 =           |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Using the Generic Associated Channel |Inf. | RFC 6423 |
   |           | = Label for Pseudowire in the MPLS     |     |          |
   |           | = Transport Profile (MPLS-TP)          |     |          |
   |           | = [PW-G-ACh]                 =           |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Pseudowire (PW) Operations,          |Misc.| RFC 6310 |
   |           | = Administration, and Maintenance (OAM)|     |          |
   |           | = Message Mapping [PW-Map]             |     |          |
  =  +-----------+--------------------------------------+-----+----------= +
   |OWAMP and  | A One-way Active = Measurement Protocol|Tool | RFC 4656 |
   |TWAMP      | [OWAMP] =                     =          |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | A = Two-Way Active Measurement Protocol|Tool | RFC 5357 |
   |           | = [TWAMP]                   =            |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = Framework for IP Performance Metrics |Misc.| RFC 2330 |
   |           | = [IPPM-FW]                   =          |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | = IPPM Metrics for Measuring           |Misc.| RFC 2678 |
   |           | = Connectivity [IPPM-Con]             =  |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | A = One-way Delay Metric for IPPM      |Misc.| RFC 2679 |
   |           | = [IPPM-1DM]                 =           |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | A = One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 |
   |           | = [IPPM-1LM]                 =           |     |          |
   |           = +--------------------------------------+-----+----------+
   |           | A = Round-trip Delay Metric for IPPM   |Misc.| RFC 2681 |
   |           | = [IPPM-2DM]                 =           |     |          |
  =  +-----------+--------------------------------------+-----+----------= +
                =  Table 1 Summary of IETF OAM Related RFCs







Mizrahi, et al.         Expires = July 9, 2013                  [Page 9]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


1.5. Non-IETF OAM Documents

   In addition to the OAM mechanisms defined = by the IETF, the IEEE and
   ITU-T have also defined various OAM = mechanisms that focus on
   Ethernet, and various other transport = network environments. These
   various mechanisms, defined by the three = standard organizations, are
   often tightly coupled, and have had a = mutual effect on each other.
   The ITU-T and IETF have both defined OAM = mechanisms for MPLS LSPs,
   [ITU-T-Y1711] and [LSP-Ping]. The = following OAM standards by the IEEE
   and ITU-T are to some extent linked to = IETF OAM mechanisms listed
   above and are mentioned here only as = reference material:

   o OAM mechanisms for Ethernet based = networks have been defined by
      both the ITU-T in [ITU-T-Y1731], = and by the IEEE in [IEEE802.1ag].
      The IEEE 802.3 standard defines = OAM for one-hop Ethernet links
      [IEEE802.3ah].

   o The ITU-T has defined OAM for MPLS LSPs = in [ITU-T-Y1711], and
      MPLS-TP OAM in [ITU-G8113.1] and = [ITU-G8113.2].

   Table 2 summarizes the OAM standards = mentioned in this document. This
   document focuses on IETF OAM standards, = but these non-IETF standards
   are referenced where relevant.

  =  +-----------+--------------------------------------+---------------+=
   |           | = Title                   =              |Standard/Draft |
  =  +-----------+--------------------------------------+---------------+=
   |ITU-T      | Operation = & Maintenance mechanism    | ITU-T Y.1711  |
   |MPLS OAM   | for MPLS networks = [ITU-T-Y1711]      |               |
   |           = +--------------------------------------+---------------+
   |           | = Assignment of the 'OAM Alert Label'  | RFC 3429      |
   |           | for = Multiprotocol Label Switching    |               |
   |           | = Architecture (MPLS) Operation and    |               |
   |           | = Maintenance (OAM) Functions          |               |
   |           | = [OAM-Label]                 =          |               |
   |           | =                     =                  |               |
   |           | =  Note: although this is an IETF      |               |
   |           | =  document, it is listed as one of the|               |
   |           | =  non-IETF OAM standards, since it    |               |
   |           | =  was defined as a complementary part |               |
   |           | =  of ITU-T Y.1711.               =      |               |
  =  +-----------+--------------------------------------+---------------+=
   |ITU-T      | Operations, = administration and       |ITU-T G.8113.2 |
   |MPLS-TP OAM| Maintenance mechanisms for = MPLS-TP   |               |


Mizrahi, et al.         Expires = July 9, 2013                 [Page 10]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   |           | = networks using the tools defined for |               |
   |           | = MPLS [ITU-G8113.2]               =     |               |
   |           | =                     =                  |               |
   |           | =  Note: this document describes the   |               |
   |           | =  OAM toolset defined by the IETF for |               |
   |           | =  MPLS-TP, whereas ITU-T G.8113.1     |               |
   |           | =  describes the OAM toolset defined   |               |
   |           | =  by the ITU-T.               =         |               |
   |           = +--------------------------------------+---------------+
   |           | = Operations, Administration and       |ITU-T G.8113.1 |
   |           | = Maintenance mechanism for MPLS-TP in |               |
   |           | = Packet Transport Network (PTN)       |               |
   |           = +--------------------------------------+---------------+
   |           | = Allocation of a Generic Associated   | RFC 6671      |
   |           | = Channel Type for ITU-T MPLS Transport|               |
   |           | = Profile Operation, Maintenance, and  |               |
   |           | = Administration (MPLS-TP OAM)         |               |
   |           | = [ITU-T-CT]                 =           |               |
   |           | =                     =                  |               |
   |           | =  Note: although this is an IETF      |               |
   |           | =  document, it is listed as one of the|               |
   |           | =  non-IETF OAM standards, since it    |               |
   |           | =  was defined as a complementary part |               |
   |           | =  of ITU-T G.8113.1.             =      |               |
  =  +-----------+--------------------------------------+---------------+=
   |ITU-T      | OAM Functions = and Mechanisms for     |[ITU-T-Y1731]  |
   |Ethernet   | Ethernet-based Networks =              |               |
   |OAM        |   =                     =                |               |
  =  +-----------+--------------------------------------+---------------+=
   |IEEE       | Connectivity = Fault Management        | IEEE 802.1ag  |
   |CFM        | = [IEEE802.1ag]                 =        |               |
   |           | =                     =                  |               |
   |           | =  Note: CFM was originally published  |               |
   |           | =  as IEEE 802.1ag, but is now         |               |
   |           | =  incorporated in the 802.1Q standard.|               |
  =  +-----------+--------------------------------------+---------------+=
   |IEEE       | Media Access = Control Parameters,     | IEEE 802.3ah  |
   |802.3      | Physical = Layers, and Management      |               |
   |link level | Parameters for Subscriber = Access     |               |
   |OAM        | Networks = [IEEE802.3ah]               |               |
   |           | =                     =                  |               |


Mizrahi, et al.         Expires = July 9, 2013                 [Page 11]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   |           | =  Note: link level OAM was originally |               |
   |           | =  defined in IEEE 802.3ah, and is now |               |
   |           | =  incorporated in the 802.3 standard. |               |
  =  +-----------+--------------------------------------+---------------+=
         Table 2 Non-IETF OAM = Standards Mentioned in this Document

2. Basic Terminology

2.1. Abbreviations

   ACH    Associated Channel = Header

   AIS    Alarm Indication = Signal

   BFD    Bidirectional Forwarding = Detection

   CC     Continuity Check

   CV     Connectivity = Verification

   DM     Delay Measurement

   FEC    Forwarding Equivalence = Class

   GAL    Generic Associated = Label

   ICMP   Internet Control Message = Protocol

   LDP    Label Distribution = Protocol

   LM     Loss Measurement

   LSP    Label Switched Path

   ME     Maintenance Entity

   MEG    Maintenance Entity = Group

   MEP    MEG End Point

   MIP    MEG Intermediate = Point

   MP     Maintenance Point

   MPLS   Multiprotocol Label = Switching



Mizrahi, et al.         Expires = July 9, 2013                 [Page 12]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   MPLS-TP MPLS Transport Profile

   MTU    Maximum Transmission = Unit

   OAM    Operations, = Administration, and Maintenance

   PW     Pseudowire

   PWE3   Pseudowire Emulation = Edge-to-Edge

   RDI    Remote Defect = Indication

   TTL    Time To Live

   VCCV   Virtual Circuit Connectivity = Verification


TOM: Why is this section not at the top of this document, as is customary for RFCs?  


2.2. Terminology used in OAM Standards

2.2.1. General Terms

   A wide variety of terms is used in various = OAM standards. Each of the
   OAM standards listed in the reference = section includes a section that
   defines terms relevant to that tool. A = thesaurus of terminology for
   MPLS-TP terms is presented in [TP-Term], = and provides a good summary
   of some of the OAM related = terminology.

   This section presents a comparison of the = terms used in various OAM
   standards, without fully quoting the = definition of each term. For a
   formal definition of each term, refer to = the references at the end of
   this document.

2.2.2. OAM Maintenance Entities

   OAM tools are designed to monitor and = manage a Maintenance Entity
   (ME).  An ME, as defined in = [TP-OAM-FW], defines a relationship
   between two points of a transport path to = which maintenance and
   monitoring operations apply.

   The following related terms are also = quoted from [TP-OAM-FW]:

   o MEP: The two points that define a = maintenance entity.

   o MEG: The collection of one or more MEs = that belongs to the same
      transport path and that are = maintained and monitored as a group
      are known as a Maintenance Entity = Group (MEG).




Mizrahi, et al.         Expires = July 9, 2013                 [Page 13]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   o MIP: In between MEPs, there are zero or = more intermediate points,
      called Maintenance Entity Group = Intermediate Points (MIPs).

   A pair of MEPs engaged in an ME are = connected by a communication
   link, which may be one of several types of connection, e.g. a single
   physical connection, a set of physical = connections, or a virtual link
   such as an MPLS LSP.

   The term Maintenance Entity (ME) is used = in ITU-T Recommendations
   (e.g. [ITU-T-Y1731]), as well as in the = MPLS-TP terminology ([TP-OAM-
   FW]). Various terms are used to refer to = an ME. For example, BFD does
   not explicitly use a term that is = equivalent to ME, but rather uses
   the term "session", referring to the = relationship between two nodes
   using a BFD protocol. The MPLS LSP Ping = ([LSP-Ping]) terminology
   simply uses the term "LSP" in this = context.

   MPLS-TP has defined the terms ME and = Maintenance Entity Group (MEG)
   in [TP-OAM-FW], similar to the terms = defined by ITU-T.  A MEG allows
   the monitoring of a compound set of MEs, = for example when monitoring
   a p2mp MEG that is considered to be the = set of MEs between the root
   and each individual destination MEP.

2.2.3. OAM Maintenance Points

   A Maintenance Point (MP) is a functional = entity that is defined at a
   node in the network, and either initiates = or reacts to OAM messages.
   A Maintenance End Point (MEP) is one of = the end points of an ME, and
   can initiate OAM messages and respond to = them. A Maintenance
   Intermediate Point (MIP) is an = intermediate point between two MEPs,
   that does not generally initiate OAM = frames (one exception to this is
   the use of AIS notifications), but is able = to respond to OAM frames
   that are destined to it. A MIP in MPLS-TP = identifies OAM packets
   destined to it by the value of the TTL = field in the OAM packet. The
   term Maintenance Point is a general term = for MEPs and MIPs.

   The 802.1ag defines a finer distinction = between Up MPs and Down MPs.
   An MP is a bridge interface, that is = monitored by an OAM protocol
   either in the direction facing the = network, or in the direction
   facing the bridge. A Down MP is an MP that = receives OAM packets from,
   and transmits them to the direction of the = network. An Up MP receives
   OAM packets from, and transmits them to = the direction of the bridging
   entity.

   MPLS-TP ([TP-OAM-FW]) uses a similar = distinction on the placement of
   the MP - either at the ingress, egress, or forwarding function of the
   node (Down / Up MPs).  This placement = is important for localization
   of a connection failure.


Mizrahi, et al.         Expires = July 9, 2013                 [Page 14]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


2.2.4. Proactive and On-demand activation

   The different OAM tools may be used in one = of two basic types of
   activation:

   o Proactive activation - indicates that = the tool is activated on a
      continual basis periodically, = where messages are sent between the
      two MEPs, and errors are detected = when a certain number of
      expected messages are not = received.

   o On-demand activation - indicates that = the tool is activated
      "manually" to detect a specific = anomaly.  In this activation a
      small number of OAM messages are = sent by a MEP and the reply
      message is received.

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.

   Continuity checks are used to verify the = liveness of a connection or
   a path between two MPs, and are typically = sent proactively, though
   they can be invoked on-demand as = well.

   A connectivity verification function = allows an MP to check whether it
   is connected to a peer MP or not. This = function also allows the MP to
   verify that messages from the peer MP are = received through the
   correct path, thereby verifying not only = that the two MPs are
   connected, but also that they are = connected through the expected
   path. This allows detection of unexpected = topology changes. A
   connectivity verification (CV) protocol = typically uses a CV message,
   followed by a CV reply that is sent back = to the originator. A CV
   function can be applied proactively or = on-demand.

   Connectivity verification and continuity = checks are considered
   complementary mechanisms, and are often = used in conjunction with each
   other.

2.2.6. Failures

   The terms Failure, Fault, and Defect are = used interchangeably in the
   standards, referring to a malfunction that = can be detected by a
   connectivity or a continuity check. In = some standards, such as
   [IEEE802.1ag], there is no distinction = between these terms, while in



Mizrahi, et al.         Expires = July 9, 2013                 [Page 15]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   other standards each of these terms refers = to a different type of
   malfunction.

   The terminology used in IETF MPLS-TP OAM = takes after the ITU-T, which
   distinguishes between these terms in = [ITU-T-G.806]; The term Fault
   refers to an inability to perform a = required action, e.g., an
   unsuccessful attempt to deliver a packet. = The term Defect refers to
   an interruption in the normal operation, = such as a consecutive period
   of time where no packets are delivered = successfully. The term Failure
   refers to the termination of the required = function. While a Defect
   typically refers to a limited period of = time, a failure refers to a
   long period of time.

3. OAM Tools

3.1. IP Ping and Traceroute

3.1.1. Ping

   Ping is a common network diagnosis = application for IP networks that
   uses ICMP. The ICMP Echo request/reply = exchange is a connectivity
   verification function for the Internet = Protocol. The originator
   transmits an ICMP Echo request packet, and = the receiver replies with
   an Echo reply. ICMP ping is defined in two = variants, [ICMPv4] is used
   for IPv4, and [ICMPv6] is used for = IPv6.

3.1.2. Traceroute

   Traceroute ([TCPIP-Tools], [NetTools]) is = an application that allows
   users to discover the path between an IP = source and an IP
   destination. Traceroute sends a sequence = of UDP packets to UDP port
   33434 at the destination. By default, = Traceroute begins by sending
   three packets (the number of packets is = configurable in most
   Traceroute implementations), each with an = IP Time-To-Live (TTL) value
   of one to the destination. These packets = expire as soon as they reach
   the first router in the path. That router = responds by sending three
   ICMP Time Exceeded Messages to the = Traceroute application. Traceroute
   now sends another three UDP packets, each = with the TTL value of 2.
   These messages cause the second router to = return ICMP messages. This
   process continues, with ever increasing = values for the TTL field,
   until the packets actually reach the = destination. Because no
   application listens to port 33434 at the destination, the destination
   returns ICMP Destination Unreachable = Messages indicating an
   unreachable port. This event indicates to = the Traceroute application
   that it is finished.  The Traceroute = program displays the round-trip
   delay associated with each of the = attempts.



Mizrahi, et al.         Expires = July 9, 2013                 [Page 16]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   Note that IP routing may be asymmetric. = While Traceroute reveals the
   path between a source and destination, it = may not reveal the reverse
   path.

   A few ICMP extensions ([ICMP-Ext], = [ICMP-MP], [ICMP-Int]) have been
   defined in the context of Traceroute. = These extensions augment the
   ICMP Destination Unreachable message, and = can be used by Traceroute
   applications.

3.2. Bidirectional Forwarding Detection (BFD)

3.2.1. Overview

   While multiple OAM mechanisms have been = defined for various protocols
   in the protocol stack, Bidirectional = Forwarding Detection [BFD],
   defined by the IETF BFD working group, is = a generic OAM mechanism
   that can be deployed over various = encapsulating protocols, and in
   various medium types. The IETF has defined = variants of the protocol
   for IP ([BFD-IP], [BFD-Multi]), for MPLS = LSPs [BFD-LSP], and for PWE3
   [BFD-VCCV]. The usage of BFD in MPLS-TP is = defined in [MPLS-TP-CC-
   CV].

   BFD includes two main OAM functions, using = two types of BFD packets:
   BFD Control packets, and BFD Echo = packets.

3.2.2. BFD Control

   BFD supports a bidirectional continuity = check, using BFD control
   packets, that are exchanged within a BFD = session. BFD sessions
   operate in one of two modes:

   o Asynchronous mode (i.e. proactive): in = this mode BFD control
      packets are sent periodically. = When the receiver detects that no
      BFD control packet have been = received during a predetermined
      period of time, a failure is = detected.

   o Demand mode: in this mode, BFD control = packets are sent on-demand.
      Upon need, a system initiates a = series of BFD control packets to
      verify the liveness of the = session. BFD control packets are sent
      independently in each = direction.

   Each of the end-points of the monitored = path maintains its own
   session identification, called a = Discriminator, both of which are
   included in the BFD Control Packets that = are exchanged between the
   end-points.  At the time of session = establishment, the Discriminators
   are exchanged between the two-end points. =  In addition, the
   transmission (and reception) rate is = negotiated between the two end-


Mizrahi, et al.         Expires = July 9, 2013                 [Page 17]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   points, based on information included in = the control packets.  These
   transmission rates may be renegotiated = during the session.

   During normal operation of the session, = i.e. no failures are
   detected, the BFD session is in the Up = state.  If no BFD Control
   packets are received during a fixed period = of time, called the

TOM: Fixed, pre-configured or negotiated period of time (i.e.: BFD interval)

   Detection Time, the session is declared to = be Down. The detection
   time is a function of the negotiated = transmission time, and a
   parameter called Detect Mult. Detect Mult = determines the number of
   missing BFD Control packets that cause the = session to be declared as
   Down. This parameter is included in the = BFD Control packet.

3.2.3. BFD Echo

   A BFD echo packet is sent to a peer = system, and is looped back to the
   originator. The echo function can be used proactively, or on-demand.

   The BFD echo function has been defined in = BFD for IPv4 and IPv6
   ([BFD-IP]), but is not used in BFD for = MPLS LSPs, PWs, or in BFD for
   MPLS-TP.

3.3. MPLS OAM

   The IETF MPLS working group has defined = OAM for MPLS LSPs. The
   requirements and framework of this effort = are defined in [MPLS-OAM-
   FW] and [MPLS-OAM], respectively. The = corresponding OAM mechanism
   defined, in this context, is LSP Ping = [LSP-Ping].

   LSP Ping is based on ICMP Ping and just = like its predecessor may be
   used in one of two modes:

   o "Ping" mode: In this mode LSP ping is = used for end-to-end
      connectivity verification between = two LERs.

   o "Traceroute" mode: This mode is used for hop-by-hop fault
      isolation.

   LSP Ping extends the basic ICMP Ping = operation (of data-plane
   connectivity verification) with = functionality to verify data-plane
   vs. control-plane consistency for a = Forwarding Equivalence Class
   (FEC) and also Maximum Transmission Unit = (MTU) problems. The
   traceroute functionality may be used to = isolate and localize the MPLS
   faults, using the Time-to-live (TTL) = indicator to incrementally
   identify the sub-path of the LSP that is successfully traversed
   before the faulty link or node.




Mizrahi, et al.         Expires = July 9, 2013                 [Page 18]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   It should be noted that LSP Ping supports = unique identification of
   the LSP within an addressing domain. The identification is checked
   using the full FEC identification. LSP = Ping is easily extensible to
   include additional information needed to = support new functionality,
   by use of Type-Length-Value (TLV) = constructs. The usage of TLVs is
   typically not easy to perform in hardware, = and is thus typically
   handled by the control plane.

   LSP Ping supports both asynchronous, as = well as, on-demand
   activation.

3.4. MPLS-TP OAM

3.4.1. Overview

   The MPLS working group is currently = working on defining the OAM
   toolset that fulfills the requirements for = MPLS-TP OAM. The full set
   of requirements for MPLS-TP OAM are = defined in [MPLS-TP-OAM], and
   include both general requirements for the = behavior of the OAM
   mechanisms and a set of operations that = should be supported by the
   OAM toolset.  The set of mechanisms = required are further elaborated
   in [TP-OAM-FW], which describes the = general architecture of the OAM
   system as well as giving overviews of the functionality of the OAM
   toolset.

   Some of the basic requirements for the OAM = toolset for MPLS-TP are:

   o MPLS-TP OAM must be able to support both = an IP based and non-IP
      based environment. If the network = is IP based, i.e. IP routing and
      forwarding are available, then the = MPLS-TP OAM toolset should rely
      on the IP routing and forwarding = capabilities. On the other hand,
      in environments where IP = functionality is not available, the OAM
      tools must still be able to = operate without dependence on IP
      forwarding and routing.

   o OAM packets and the user traffic are = required to be congruent
      (i.e. OAM packets are transmitted = in-band) and there is a need to
      differentiate OAM packets from = user-plane ones. Inherent in this
      requirement is the principle that = MPLS-TP OAM be independent of
      any existing control-plane, = although it should not preclude use of
      the control-plane = functionality.

3.4.2. Generic Associated Channel

   In order to address the requirement for = in-band transmission of MPLS-
   TP OAM traffic, MPLS-TP uses a Generic = Associated Channel (G-ACh),
   defined in [G-ACh] for LSP-based OAM = traffic. This mechanism is based


Mizrahi, et al.         Expires = July 9, 2013                 [Page 19]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   on the same concepts as the PWE3 ACH and = VCCV mechanisms.  However,
   to address the needs of LSPs as = differentiated from PW, the following
   concepts were defined for [G-ACh]:

   o An Associated Channel Header (ACH), that = uses a format similar to
      the PW Control Word, is a 4-byte = header that is prepended to OAM
      packets.

   o A Generic Associated Label (GAL). The = GAL is a reserved MPLS label
      value (13) that indicates that the = packet is an ACH packet and the
      payload follows immediately after = the label stack.

3.4.3. MPLS-TP OAM Toolset

   To address the functionality that is = required of the OAM toolset, the
   MPLS WG conducted an analysis of the = existing IETF and ITU-T OAM
   mechanisms and their ability to fulfill = the required functionality.
   The conclusions of this analysis are = documented in [OAM-Analys]. The
   MPLS working group currently plans to use = a mixture of OAM mechanisms
   that are based on various existing = standards, and adapt them to the
   requirements of [MPLS-TP-OAM]. Some of the = main building blocks of
   this solution are based on:

   o Bidirectional Forwarding Detection = ([BFD], [BFD-LSP]) for
      proactive continuity check and = connectivity verification.

   o LSP Ping as defined in [LSP-Ping] for = on-demand connectivity
      verification.

   o New protocol packets, using G-ACH, to = address different
      functionality.

   o Performance measurement protocols that = are based on the
      functionality that is described in = [ITU-T-Y1731].

   The following sub-sections describe the = OAM tools defined for MPLS-TP
   as described in [TP-OAM-FW].

3.4.3.1. Continuity Check and Connectivity = Verification

   Continuity Check and Connectivity = Verification are presented in
   Section 2.2.5. of this document.  As = presented there, these tools may
   be used either proactively or on-demand. =  When using these tools
   proactively, they are generally used in = tandem.

   For MPLS-TP there are two distinct tools, = the proactive tool is
   defined in [TP-CC-CV] while the on-demand = tool is defined in


Mizrahi, et al.         Expires = July 9, 2013                 [Page 20]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   [OnDemand-CV].Proactively [MPLS-TP-OAM] = states that the function
   should allow the MEPs to monitor the = liveness and connectivity of a
   transport path. In on-demand mode, this = function should support
   monitoring between the MEPs and, in = addition, between a MEP and MIP.
   [TP-OAM-FW] highlights,  when = performing Connectivity Verification,
   the need for the CC-V messages to include = unique identification of
   the MEG that is being monitored and the = MEP that originated the
   message.

   The proactive tool [TP-CC-CV] is based on = extensions to BFD (see
   Section 3.2. ) with the additional = limitation that the transmission
   and receiving rates are based on = configuration by the operator.  The
   on-demand tool [OnDemand-CV] is an = adaptation of LSP Ping (see
   Section 3.3. ) for the required behavior = of MPLS-TP.

3.4.3.2. Route Tracing

   [MPLS-TP-OAM] defines that there is a need = for functionality that
   would allow a path end-point to identify = the intermediate and end-
   points of the path. This function would be = used in on-demand mode.
   Normally, this path will be used for = bidirectional PW, LSP, and
   sections, however, unidirectional paths = may be supported only if a
   return path exists.  The tool for = this is based on the LSP Ping (see
   Section 3.3. ) functionality and is = described in [OnDemand-CV].

3.4.3.3. Lock Instruct

   The Lock Instruct function [Lock-Loop] is = used to notify a transport
   path end-point of an administrative need = to disable the transport
   path.  This functionality will = generally be used in conjunction with
   some intrusive OAM function, e.g. = Performance measurement, Diagnostic
   testing, to minimize the side-effect on = user data traffic.

3.4.3.4. Lock Reporting

   Lock Reporting is a function used by an = end-point of a path to report
   to its far-end end-point that a lock = condition has been affected on
   the path.

3.4.3.5. Alarm Reporting

   Alarm Reporting is a function used by an intermediate point of a
   path, that becomes aware of a fault on the = path, to report to the
   end-points of the path. [TP-OAM-FW] states = that this may occur as a
   result of a defect condition discovered at = a server sub-layer. This
   generates an Alarm Indication Signal (AIS) = that continues until the



Mizrahi, et al.         Expires = July 9, 2013                 [Page 21]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   fault is cleared. The consequent action of = this function is detailed
   in [TP-OAM-FW].

3.4.3.6. Remote Defect Indication

   Remote Defect Indication (RDI) is used = proactively by a path end-
   point to report to its peer end-point that = a defect is detected on a
   bidirectional connection between them. = [MPLS-TP-OAM] points out that
   this function may be applied to a = unidirectional LSP only if there a
   return path exists.  [TP-OAM-FW] = points out that this function is
   associated with the proactive CC-V = function.

3.4.3.7. Client Failure Indication

   Client Failure Indication (CFI) is defined = in [MPLS-TP-OAM] to allow
   the propagation information from one edge = of the network to the
   other. The information concerns a defect = to a client, in the case
   that the client does not support alarm = notification.

3.4.3.8. Packet Loss Measurement (LM)

   Packet Loss Measurement is a function used = to verify the quality of
   the service. This function indicates the = ratio of packets that are
   not delivered out of all packets that are transmitted by the path
   source.

   There are two possible ways of determining = this measurement:

   o Using OAM packets, it is possible to = compute the statistics based
      on a series of OAM packets. This, = however, has the disadvantage of
      being artificial, and may not be = representative since part of the
      packet loss may be dependent upon = packet sizes.

TOM: Not just packet sizes. Things like implementation (as I mentioned above with the comment about the accuracy or truthfulness of the data plane processing of OAM packets).  Doing very accurate RTT as a simple example, with just IP Pings, is a tricky thing to make work.  Also, it is = important to mention that the scale in terms of number of packets, number of tests, etc=85 can and will impact these parameters too.


   o Sending delimiting messages for the = start and end of a measurement
      period during which the source and = sink of the path count the
      packets transmitted and received. = After the end delimiter, the
      ratio would be calculated by the = path OAM entity.

3.4.3.9. Packet Delay Measurement (DM)

   Packet Delay Measurement is a function = that is used to measure one-
   way or two-way delay of a packet = transmission between a pair of the
   end-points of a path (PW, LSP, or = Section). Where:






Mizrahi, et al.         Expires = July 9, 2013                 [Page 22]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   o One-way packet delay is the time elapsed = from the start of
      transmission of the first bit of = the packet by a source node until
      the reception of the last bit of = that packet by the destination
      node.

   o Two-way packet delay is the time elapsed = from the start of
      transmission of the first bit of = the packet by a source node until
      the reception of the last bit of = the loop-backed packet by the
      same source node, when the = loopback is performed at the packet's
      destination node.

   Similarly to the packet loss measurement = this could be performed in
   either of the two ways outlined = above.

3.5. PWE3 OAM

3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV)

   VCCV, as defined in [VCCV], provides a = means for end-to-end fault
   detection and diagnostics tools to be = extended for PWs (regardless of
   the underlying tunneling technology). The = VCCV switching function
   provides a control channel associated with = each PW (based on the PW
   Associated Channel Header (ACH) which is = defined in [PW-ACH]), and
   allows transmitting the OAM packets = in-band with PW data (using CC
   Type 1: In-band VCCV).

   VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP
   Ping, and BFD. ICMP and LSP Ping are IP = encapsulated before being
   sent over the PW ACH. BFD for VCCV = [BFD-VCCV] supports two modes of
   encapsulation - either IP/UDP encapsulated = (with IP/UDP header) or
   PW-ACH encapsulated (with no IP/UDP = header) and provides support to
   signal the AC status. The use of the VCCV = control channel provides
   the context, based on the MPLS-PW label, = required to bind and
   bootstrap the BFD session to a particular = pseudo wire (FEC),
   eliminating the need to exchange = Discriminator values.

   VCCV consists of two components: (1) = signaled component to
   communicate VCCV capabilities as part of = VC label, and (2) switching
   component to cause the PW payload to be = treated as a control packet.

   VCCV is not directly dependent upon the = presence of a control plane.
   The VCCV capability negotiation may be = performed as part of the PW
   signaling when LDP is used. In case of = manual configuration of the
   PW, it is the responsibility of the = operator to set consistent
   options at both ends.

TOM: Might be helpful to note that the static mode was created specifically to handle the MPLS-TP cases where no control plane was a requirement. However, new use cases such as pure mobile backhaul, etc=85 find this functionality useful = too.





Mizrahi, et al.         Expires = July 9, 2013                 [Page 23]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


3.5.2. PWE3 OAM using G-ACh

   As mentioned above, VCCV enables OAM for = PWs by using a control
   channel for OAM packets. When PWs are used = in MPLS-TP networks,
   rather than the control channels defined = in VCCV, the G-ACh can be
   used as an alternative control channel. = The usage of the G-ACh for
   PWs is defined in [PW-G-ACh].

3.6. OWAMP and TWAMP

3.6.1. Overview

   The IPPM working group in the IETF defines = common criteria and
   metrics for measuring performance of IP = traffic ([IPPM-FW]). Some of
   the key RFCs published by this working = group have defined metrics for
   measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]),
   and packet loss [IPPM-1LM].

   Alternative protocols for performance = measurement are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], = [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].

   The IPPM working group has defined not = only metrics for performance
   measurement, but also protocols that = define how the measurement is
   carried out. The One-way Active = Measurement Protocol [OWAMP] and the
   Two-Way Active Measurement Protocol = [TWAMP] define a method and
   protocol for measuring delay and packet = loss in IP networks.

   OWAMP [OWAMP] enables measurement of = one-way characteristics of IP
   networks, such as one-way packet loss and = one-way delay.  For its
   proper operation OWAMP requires accurate = time of day setting at its
   end points.

   TWAMP [TWAMP] is a similar protocol that = enables measurement of two-
   way (round trip) characteristics. =  TWAMP does not require accurate
   time of day, and, furthermore, allows the = use of a simple session
   reflector, making it an attractive = alternative to OWAMP.

   OWAMP and TWAMP use two separate = protocols: a Control plane protocol,
   and a Test plane protocol.

3.6.2. Control and Test Protocols

   OWAMP and TWAMP control protocols run over = TCP, while the test
   protocols run over UDP.  The purpose = of the control protocols is to
   initiate, start, and stop test sessions, = and for OWAMP to fetch
   results.  The test protocols = introduce test packets (which contain


Mizrahi, et al.         Expires = July 9, 2013                 [Page 24]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   sequence numbers and timestamps) along the = IP path under test
   according to a schedule, and record = statistics of packet arrival.
   Multiple sessions may be simultaneously = defined, each with a session
   identifier, and defining the number of = packets to be sent, the amount
   of padding to be added (and thus the = packet size), the start time,
   and the send schedule (which can be either = a constant time between
   test packets or exponentially distributed pseudo-random). Statistics
   recorded conform to the relevant IPPM = RFCs.

   OWAMP and TWAMP test traffic is designed = with security in mind.  Test
   packets are hard to detect because they = are simply UDP streams
   between negotiated port numbers, with = potentially nothing static in
   the packets.  OWAMP and TWAMP also = include optional authentication
   and encryption for both control and test = packets.

3.6.3. OWAMP

   OWAMP defines the following logical roles: Session-Sender, Session-
   Receiver, Server, Control-Client, and = Fetch-Client.  The Session-
   Sender originates test traffic that is = received by the Session-
   Receiver.  The Server configures and = manages the session, as well as
   returning the results.  The = Control-Client initiates requests for
   test sessions, triggers their start, and = may trigger their
   termination.  The Fetch-Client = requests the results of a completed
   session.  Multiple roles may be = combined in a single host - for
   example, one host may play the roles of Control-Client, Fetch-Client,
   and Session-Sender, and a second playing = the roles of Server and
   Session-Receiver.

   In a typical OWAMP session the = Control-Client establishes a TCP
   connection to port 861 of the Server, = which responds with a server
   greeting message indicating supported security/integrity modes. The
   Control-Client responds with the chosen communications mode and the
   Server accepts the modes.  The = Control-Client then requests and fully
   describes a test session to which the = Server responds with its
   acceptance and supporting information. =  More than one test session
   may be requested with additional messages. =  The Control-Client then
   starts a test session and the Server = acknowledges.  The Session-
   Sender then sends test packets with = pseudorandom padding to the
   Session-Receiver until the session is = complete or until the Control-
   client stops the session.  Once = finished, the Fetch-Client sends a
   fetch request to the server, which = responds with an acknowledgement
   and immediately thereafter the result = data.






Mizrahi, et al.         Expires = July 9, 2013                 [Page 25]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


3.6.4. TWAMP

   TWAMP defines the following logical roles: session-sender, session-
   reflector, server, and control-client. =  These are similar to the
   OWAMP roles, except that the = Session-Reflector does not collect any
   packet information, and there is no need = for a Fetch-Client.

   In a typical TWAMP session the = Control-Client establishes a TCP
   connection to port 862 of the Server, and = mode is negotiated as in
   OWAMP.  The Control-Client then = requests sessions and starts them.
   The Session-Sender sends test packets with pseudorandom padding to
   the Session-Reflector which returns them = with insertion of
   timestamps.

3.7. Summary of OAM Functions

   Table 3 summarizes the OAM functions that = are supported in each of
   the categories that were analyzed in this = section.

  =  +-----------+-------+--------+--------+-----------+-------+--------+=
   | Standard  |Continu|Connecti|Path =    |Defect     |Perform|Other   |
   |           |ity =    |vity    |Discover|Indications|ance   |Function|
   |           = |Check  |Verifica|y       |       =     |Monitor|s       |
   |           | =       |tion    |        | =           |ing    |        |
  =  +-----------+-------+--------+--------+-----------+-------+--------+=
   |IP Ping    |     =   |Echo    |        |     =       |       |        |
   + --------- + ----- + ------ + ------ + = --------- + ----- + ------ +
   |IP         |   =     |        |Tracerou|     =       |       |        |
   |Traceroute |       | =        |te      |     =       |       |        |
   + --------- + ----- + ------ + ------ + = --------- + ----- + ------ +
   |BFD        |BFD =    |BFD     |        |   =         |       |        |
   |           = |Control|Echo    |        |     =       |       |        |
   + --------- + ----- + ------ + ------ + = --------- + ----- + ------ +
   |MPLS OAM   |       = |"Ping"  |"Tracero|           |       |        |
   |(LSP Ping) |       |mode =    |ute"    |           |       |        |
   |           | =       |        |mode    | =           |       |        |
   + --------- + ----- + ------ + ------ + = --------- + ----- + ------ +
   |MPLS-TP    |CC     = |CV/pro- |Route   |-Alarm     |-LM    |-Diagnos|
   |OAM        |   =     |active  |Tracing | Reporting |-DM    | tic Tes|
   |           | =       |or on-  |        |-Client =    |       | t      |
   |           | =       |demand  |        | = Failure   |       |-Lock   |
   |           | =       |        |       =  | Indication|       |        |
   |           | =       |        |       =  |-Remote    |       |        |



Mizrahi, et al.         Expires = July 9, 2013                 [Page 26]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   |           | =       |        |       =  | Defect    |       |        |
   |           | =       |        |       =  | Indication|       |        |
   + --------- + ----- + ------ + ------ + = --------- + ----- + ------ +
   |PWE3 OAM   |BFD    |-BFD =    |LSP-Ping|           |       |        |
   |           | =       |-ICMP   |        |   =         |       |        |
   |           | =       | Ping   |        |   =         |       |        |
   |           | =       |-LSP-   |        |   =         |       |        |
   |           | =       | Ping   |        |   =         |       |        |
   + --------- + ----- + ------ + ------ + = --------- + ----- + ------ +
   |OWAMP and  |       | =        |        |     =       |-Delay |        |
   |TWAMP      |     =   |        |        | =           | measur|        |
   |           | =       |        |       =  |           | ement |        |
   |           | =       |        |       =  |           |-Packet|        |
   |           | =       |        |       =  |           | loss  |        |
   |           | =       |        |       =  |           | measur|        |
   |           | =       |        |       =  |           | ement |        |
  =  +-----------+-------+--------+--------+-----------+-------+--------+=
                =      Table 3 Summary of OAM Functions

4. Security Considerations

   This memo presents an overview of existing = OAM mechanisms, and
   proposes no new OAM mechanisms. Therefore, = this document introduces
   no security considerations. However, the = OAM mechanism reviewed in
   this document can and do present security = issues. The reader is
   encouraged to review the Security = Considerations section of each
   document reference by this memo.

5. IANA Considerations

   There are no new IANA considerations = implied by this document.

6. Acknowledgments

   The authors gratefully acknowledge Sasha = Vainshtein, Carlos
   Pignataro, David Harrington, Dan = Romascanu, Ron Bonica and other
   members of the OPSAWG mailing list for = their helpful comments.

   This document was prepared using 2-Word-v2.0.template.dot.







Mizrahi, et al.         Expires = July 9, 2013                 [Page 27]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


7. References

7.1. Normative References

   [LSP-Ping]    Kompella, K., = Swallow, G., "Detecting Multi-Protocol
                =  Label Switched (MPLS) Data Plane Failures", RFC 4379,
                =  February 2006.

   [MPLS-OAM]    Nadeau, T., = Morrow, M., Swallow, G., Allan, D.,
                =  Matsushima, S., "Operations and Management (OAM)
                =  Requirements for Multi-Protocol Label Switched (MPLS)
                =  Networks", RFC 4377, February 2006.

   [MPLS-OAM-FW] Allan, D., Nadeau, T., "A = Framework for Multi-Protocol
                =  Label Switching (MPLS) Operations and Management
                =  (OAM)", RFC 4378, February 2006.

   [OAM-Label]   Ohta, H., "Assignment = of the 'OAM Alert Label' for
                =  Multiprotocol Label Switching Architecture (MPLS)
                =  Operation and Maintenance (OAM) Functions", RFC 3429,
                =  November 2002.

   [MPLS-TP-OAM] Vigoureux, M., Ward, D., = Betts, M., "Requirements for
                =  OAM in MPLS Transport Networks", RFC 5860, May 2010.

   [G-ACh]       Bocci, M., = Vigoureux, M., Bryant, S., "MPLS Generic
                =  Associated Channel", RFC 5586, June 2009.

   [VCCV]        Nadeau, = T., Pignataro, C., "Pseudowire Virtual Circuit
                =  Connectivity Verification (VCCV): A Control Channel
                =  for Pseudowires", RFC 5085, December 2007.

   [PW-ACH]      Bryant, S., = Swallow, G., Martini, L., McPherson, D.,
                =  "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
                =  for Use over an MPLS PSN", RFC 4385, February 2006.

   [ICMPv4]      Postel, J., = "Internet Control Message Protocol", STD 5,
                =  RFC 792, September 1981.

   [ICMPv6]      Conta, A., = Deering, S., and M. Gupta, "Internet Control
                =  Message Protocol (ICMPv6) for the Internet Protocol
                =  Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [MPLS-P2MP]   Yasukawa, S., Farrel, = A., King, D., Nadeau, T.,
                =  "Operations and Management (OAM) Requirements for
                =  Point-to-Multipoint MPLS Networks", RFC 4687,
                =  September 2006.


Mizrahi, et al.         Expires = July 9, 2013                 [Page 28]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   [ICMP-Ext]    Bonica, R., Gan, = D., Tappan, D., Pignataro, C., "ICMP
                =  Extensions for Multiprotocol Label Switching", RFC
                =  4950, August 2007.

   [ICMP-MP]     Bonica, R., Gan, = D., Tappan, D., Pignataro, C.,
                =  "Extended ICMP to Support Multi-Part Messages", RFC
                =  4884, April 2007.

   [ICMP-Int]    Atlas, A., Bonica, = R., Pignataro, C., Shen, N., Rivers,
                =  JR., "Extending ICMP for Interface and Next-Hop
                =  Identification", RFC 5837, April 2010.

   [TCPIP-Tools] Kessler, G., Shepard, S., "A = Primer On Internet and
                =  TCP/IP Tools and Utilities", RFC 2151, June 1997.

   [NetTools]    Stine, R., "FYI on = a Network Management Tool Catalog:
                =  Tools for Monitoring and Debugging TCP/IP Internets
                =  and Interconnected Devices", RFC 1147, April 1990.

   [IPPM-FW]     Paxson, V., Almes, = G., Mahdavi, J., and Mathis, M.,
                =  "Framework for IP Performance Metrics", RFC 2330, May
                =  1998.

   [IPPM-Con]    Mahdavi, J., = Paxson, V., "IPPM Metrics for Measuring
                =  Connectivity", RFC 2678, September 1999.

   [IPPM-1DM]    Almes, G., = Kalidindi, S., Zekauskas, M., "A One-way
                =  Delay Metric for IPPM", RFC 2679, September 1999.

   [IPPM-1LM]    Almes, G., = Kalidindi, S., Zekauskas, M., "A One-way
                =  Packet Loss Metric for IPPM", RFC 2680, September
                =  1999.

   [IPPM-2DM]    Almes, G., = Kalidindi, S., Zekauskas, M., "A Round-trip
                =  Delay Metric for IPPM", RFC 2681, September 1999.

   [OWAMP]       Shalunov, S., = Teitelbaum, B., Karp, A., Boote, J., and
                =  Zekauskas, M., "A One-way Active Measurement Protocol
                =  (OWAMP)", RFC 4656, September 2006.

   [TWAMP]       Hedayat, K., = Krzanowski, R., Morton, A., Yum, K., and
                =  Babiarz, J., "A Two-Way Active Measurement Protocol
                =  (TWAMP)", RFC 5357, October 2008.

   [BFD]         Katz, = D., Ward, D., "Bidirectional Forwarding Detection
                =  (BFD)", RFC 5880, June 2010.



Mizrahi, et al.         Expires = July 9, 2013                 [Page 29]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   [BFD-IP]      Katz, D., = Ward, D., "Bidirectional Forwarding Detection
                =  (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
                =  2010.

   [BFD-Gen]     Katz, D., Ward, = D., "Generic Application of
                =  Bidirectional Forwarding Detection (BFD)", RFC 5882,
                =  June 2010.

   [BFD-Multi]   Katz, D., Ward, D., = "Bidirectional Forwarding Detection
                =  (BFD) for Multihop Paths", RFC 5883, June 2010.

   [BFD-LSP]     Aggarwal, R., = Kompella, K., Nadeau, T., and Swallow,
                =  G., "Bidirectional Forwarding Detection (BFD) for MPLS
                =  Label Switched Paths (LSPs)", RFC 5884, June 2010.

   [BFD-VCCV]    Nadeau, T., = Pignataro, C., "Bidirectional Forwarding
                =  Detection (BFD) for the Pseudowire Virtual Circuit
                =  Connectivity Verification (VCCV)", RFC 5885, June
                =  2010.

   [TP-OAM-FW]   Busi, I., Allan, D., = "Operations, Administration and
                =  Maintenance Framework for MPLS-based Transport
                =  Networks ", RFC 6371, September 2011.

   [TP-CC-CV]    Allan, D., = Swallow, G., Drake, J., "Proactive
                =  Connectivity Verification, Continuity Check and Remote
                =  Defect indication for MPLS Transport Profile", RFC
                =  6428, November 2011.

   [OnDemand-CV] Gray, E., Bahadur, N., = Boutros, S., Aggarwal, R. "MPLS
                =  On-Demand Connectivity Verification and Route
                =  Tracing", RFC 6426, November 2011.

   [MPLS-LM-DM]  Frost, D., Bryant, S., = "Packet Loss and Delay
                =  Measurement for MPLS Networks", RFC 6374, September
                =  2011.

   [TP-LM-DM]    Frost, D., Bryant, = S., "A Packet Loss and Delay
                =  Measurement Profile for MPLS-Based Transport
                =  Networks", RFC 6375, September 2011.

   [TP-Fault]    Swallow, G., = Fulignoli, A., Vigoureux, M., Boutros, S.,
                =  "MPLS Fault Management Operations, Administration, and
                =  Maintenance (OAM)", RFC 6427, November 2011.





Mizrahi, et al.         Expires = July 9, 2013                 [Page 30]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   [Lock-Loop]   Boutros, S., Sivabalan, = S., Aggarwal, R., Vigoureux,
                =  M., Dai, X., "MPLS Transport Profile Lock Instruct and
                =  Loopback Functions", RFC 6435, November 2011.

   [ITU-T-CT]    Betts, M., = "Allocation of a Generic Associated Channel
                =  Type for ITU-T MPLS Transport Profile Operation,
                =  Maintenance, and Administration (MPLS-TP OAM)", RFC
                =  6671, November 2012.

   [PW-Map]      M. Aissaoui, = P. Busschbach, L. Martini, M. Morrow, T.
                =  Nadeau, "Pseudowire (PW) Operations, Administration,
                =  and Maintenance (OAM) Message Mapping", RFC 6310, July
                =  2011.

   [PW-G-ACh]    Li, H., Martini, = L., He, J., Huang, F., "Using the
                =  Generic Associated Channel Label for Pseudowire in the
                =  MPLS Transport Profile (MPLS-TP)", RFC 6423, November
                =  2011.

7.2. Informative References

   [OAM-Def]     Andersson, L., Van = Helvoort, H., Bonica, R., Romascanu,
                =  D., Mansfield, S., "Guidelines for the use of the OAM
                =  acronym in the IETF ", RFC 6291, June 2011.

   [OAM-Analys]  Sprecher, N., Fang, L., = "An Overview of the OAM Tool
                =  Set for  MPLS based Transport Networks", RFC 6669,
                =  July 2012.

   [TP-Term]     Van Helvoort, H., = Andersson, L., Sprecher, N., "A
                =  Thesaurus for the Terminology used in Multiprotocol
                =  Label Switching Transport Profile (MPLS-TP)
                =  drafts/RFCs and ITU-T's Transport Network
                =  Recommendations", work-in-progress, draft-ietf-mpls-
                =  tp-rosetta-stone, July 2012.

   [IEEE802.1ag] IEEE 802.1Q, "IEEE Standard = for Local and metropolitan
                =  area networks - Media Access Control (MAC) Bridges and
                =  Virtual Bridged Local Area Networks", October 2012.

   [ITU-T-Y1731] ITU-T Recommendation = G.8013/Y.1731, "OAM Functions and
                =  Mechanisms for Ethernet-based Networks", July 2011.

   [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance
                =  mechanism for MPLS networks", February 2004.




Mizrahi, et al.         Expires = July 9, 2013                 [Page 31]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   [IEEE802.3ah] IEEE 802.3, "IEEE Standard = for Information technology -
                =  Local and metropolitan area networks - Carrier sense
                =  multiple access with collision detection (CSMA/CD)
                =  access method and physical layer specifications",
                =  clause 57, December 2008.

   [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of
                =  transport equipment - Description methodology and
                =  generic functionality", January 2009.

   [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations,
                =  administration and maintenance mechanisms for MPLS-TP
                =  networks using the tools defined for MPLS", November
                =  2012.

   [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations,
                =  Administration and Maintenance mechanism for MPLS-TP
                =  in Packet Transport Network (PTN)", November 2012.



Authors' Addresses

   Tal Mizrahi
   Marvell
   6 Hamada St.
   Yokneam, 20692
   Israel

   Email: talmi@marvell.com


   Nurit Sprecher
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel



   Elisa Bellagamba
   Ericsson
   6 Farogatan St.
   Stockholm,   164 40
   Sweden



Mizrahi, et al.         Expires = July 9, 2013                 [Page 32]
Internet-Draft       Overview of OAM = Mechanisms           January 2013


   Phone: +46 761440785


   Yaacov Weingarten
   34 Hagefen St.
   Karnei Shomron,   4485500
   Israel

   Email: wyaacov@gmail.com









draft-ietf-opsawg-oam-overview authors,

Here is my feedback on this document.

1.
Is this document in line with http://too= ls.ietf.org/html/draft-ietf-trill-oam-req-04?
* For example, the following definitions could be reused.
   Fault: The term Fault refers to an =
inability to perform a required
   action, e.g., an unsuccessful attempt to deliver a packet.

   Defect: The term Defect refers to an interruption in the normal
   operation, such that over a period of time no packets are delivered
   successfully.

   Failure: The term Failure refers to the termination of the required
   function over a longer period of time. Persistence of a defect for a
   period of time is interpreted as a failure.

* For example, on the basic abstract=20
Abstract

   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

Abstract (draft-ietf-trill-oam-req-04)

   OAM (Operations, Administration and Maintenance) is a general term
   used to identify functions and toolsets to troubleshoot and monitor
   networks. This document presents, OAM Requirements applicable to
   TRILL.=20

So, as an example: does OAM include function?=20
I advice to review draft-ietf-trill-oam-req-04

2.=20
draft-ietf-trill-oam is not mentioned, while the abstract mentions:
   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.
Search for OAM in the current draft names (https://datatracker.ietf.org/),=
 and you will find many references.
Ok, I see later on:=09
   This document focuses on IETF
   documents that have been published as RFCs, while other ongoing OAM-
   related work is outside the scope.
Ok, fine then: we don't need a reference to all the drafts.=20
However, draft-ietf-trill-oam is closed to be a RFC, and should be =
mentioned.


3.
Section 1
   The term OAM in this document refers to Operations, Administration
   and Maintenance [OAM-Def], focusing on the forwarding plane of OAM.
What does it mean "focusing on the forwarding plane of OAM"?
Do you take a subset of the definition for this document?
Btw, I don't see a definition in the terminology section.
In section 2.2.3
   A Maintenance Point (MP) is a functional entity that is defined at a
   node in the network, and either initiates or reacts to OAM messages.
Which plane is MP?

4.
Section 1, Introduction
"Hence, management aspects are outside the scope of this document."
I don't understand which management aspects we speak about here.
5.
Clarifying question regarding 1.2
If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, control plane, or management plane?
Note that I found later on in the draft:
   OWAMP and TWAMP use two separate =
protocols: a Control plane protocol,
   and a Test plane protocol.
Interestingly enough, after reading the document, I reviewed http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballo= t/, and saw the same feedback from Stewart Bryant:
Provide a clear view of OAM functionality and its =
relationship
to various =93planes=94 of networking (data plane, control plane,
management plane). In particular, the importance of
fate-sharing of OAM and user traffic flows in packet networks
should be explained.
6.
I see a multiplication of "plane" terms =
in the IETF document, and in this document in particular.
I could find: forwarding plane, management plane, control plane, data =
plane, user plane, and test plane.
Way too many.
Please be consistent
7.
   Table 1 summarizes the IETF OAM =
related RFCs discussed in this
   document.

   Table 2 summarizes the OAM standards mentioned in this document.=20

You need to change the Table 2 description. Do you want to say something =
along the lines of:
   Table 2 summarizes the OAM standards specified by other Standard =
Development Organization=20
   (SDO) than the IETF, along with IETF references where applicable.


8.
Section 2.2.1
   For a formal definition of each term, refer to the references at the =
end of
   this document.
Without a reference to a specific RFC, this is the type of statement =
which is not useful: you have 5 pages of references.
You position this document as "An Overview of =
Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know =
about the terms,
just read first all references!"

9.
You specify some terms and some OAM categories,=20
   2.2.2. OAM Maintenance Entities .......................... =
13
         2.2.3. OAM Maintenance Points ............................ =
14
         2.2.4. Proactive and On-demand activation ................ =
15
         2.2.5. Connectivity Verification and Continuity Checks ... =
15
         2.2.6. Failures .......................................... =
15
... but you don't use them in the section 3

Just one example with section 3.2.2
-
   o Demand mode: in this mode, BFD control packets are sent on-demand.
      Upon need, a system initiates a series of BFD control packets to
      verify the liveness of the session
Instead of liveness, you have defined Connectivity Verification and =
Continuity Checks in section 2.2.5
- OLD:
   Each of the end-points of the monitored path maintains its own
   session identification
NEW:
   Each of the MEP maintains its own session identification
OR NEW (actually I don't know)
   Each of the MP maintains its own session identification
- OLD
	A BFD echo packet is sent to a peer system
Peer system =3D MEP, MP, or something else?
- etc...=20

10.=20
This document is composed of a list of OAM content and references, but =
I'm really missing the document "scope and target audience".
When we did RFC 6632, which is the companion document, we had http://tools.ietf.=
org/html/rfc6632#section-1.1
 
   The target audience of the document is, on the one hand, IETF working
   groups, which aim to select appropriate standard management protocols
   and data models to address their needs concerning network management.
   On the other hand, the document can be used as an overview and
   guideline by non-IETF Standards Development Organizations (SDOs)
   planning to use IETF management technologies and data models for the
   realization of management applications.  The document can also be
   used to initiate a discussion between the bodies with the goal to
   gather new requirements and to detect possible gaps.  Finally, this
   document is directed to all interested parties that seek to get an
   overview of the current set of the IETF network management protocols
   such as network administrators or newcomers to the IETF.

You should have something similar.


11.
Section 3.6.1, put the paragraph 2 at the end of the section. The =
"alternative" in the following sentence would then make sense
   Alternative protocols for performance measurement are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].


My conclusions: this document still needs some work

Regards, Benoit
 

The IESG has received a request from the =
Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'An Overview of Operations, Administration, and Maintenance (OAM)
   Mechanisms'
  <draft-ietf-opsawg-oam-overview-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by =
2013-01-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, =
please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.




The file can be obtained via
h=
ttp://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballo=
t/


No IPR declarations have been submitted directly on this I-D.



= --Apple-Mail=_37D55104-A690-4711-87D5-FDCA45807A2C-- --Apple-Mail=_6B2B593D-96C5-4FE4-AD09-6076CE6AEF7A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS3UDHAAoJEPcO+I7eiUJZr1wP/isACdDIAyERf+o4mDqjf1vP udmoX7qa+RGpKPmB2UtmQVka36EJxOmU7Kvc/8hDpw3M+VYpJ3I/Y2008xbWdFbm cSmggU4TaVufE/b6BvUll+cKL0z+RPsDR4YS1iVV9FMBF+FXREwPTsSqhZrvFzAP s5sQ3S4ZRgkaM0EnjdmuZdicnVXHn/+q0BTeUqsiPG5gRDKoW4MMUHhC9SjNU8VD hDKSamIrz29KTVBOFuGcpbTjqaZ4xLpCnfvX+AkMmMjclKyeku8fcxKafnBalPJb RIuu0CoZEwEIWP7X0VJgcCXlkY/47VHWBIk9Ks/ZyW0EmjNH1Ze+6HZF35eurJaY tR0cIkjyb9qeIvIwNQLM5ooFQX0XWupdUVNO5F+6XDy7g0tPH3GPBygmmf8p3Fwj ZW9GpnOAzw5SKrgwoDEWomlbT/kKYta/3lrGv2MGwP0UhZ7QC22lz+zH77pVWqTW 2DhCJ1CgfRZ2BYUA+N2/V/8M1HFbn/I9MP9t94+y8Kuw45BEpkm6dhDrACOd4Q/L j7fPwIGJLI9YlJlaWz+leQN2XQ4NQ216UpkK+42voKcPrxUPnWrV1m3gD6Si8LRR OM/FPg2f8MyvyFdAKGLm4oCMTs0F0bN+z0niZe5un0xjzA6+KnRxYtfhdMeKDBo5 7snjH3V2QiGhe5/237/j =ApCx -----END PGP SIGNATURE----- --Apple-Mail=_6B2B593D-96C5-4FE4-AD09-6076CE6AEF7A-- From tnadeau@lucidvision.com Mon Jan 20 07:30:10 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9E01A01B4 for ; Mon, 20 Jan 2014 07:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.588 X-Spam-Level: *** X-Spam-Status: No, score=3.588 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_LITTLE=1.555, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_24=0.6, RP_MATCHES_RCVD=-0.535, T_FRT_LITTLE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb6R8GrHJe0t for ; Mon, 20 Jan 2014 07:29:55 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 110331A01C0 for ; Mon, 20 Jan 2014 07:29:54 -0800 (PST) Received: from [192.168.1.115] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DE80C26BF082; Mon, 20 Jan 2014 10:29:53 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_91D8F787-6B8B-45C4-94EA-54D49191EA94"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9F93307@IL-MB01.marvell.com> Date: Mon, 20 Jan 2014 10:29:53 -0500 Message-Id: <73851B1F-3FC5-4DBF-BD09-2C4DD74DF383@lucidvision.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9F93307@IL-MB01.marvell.com> To: Tal Mizrahi X-Mailer: Apple Mail (2.1827) X-Mailman-Approved-At: Mon, 20 Jan 2014 07:32:08 -0800 Cc: Thomas Narten , "Carlos Pignataro \(cpignata\)" , Alexander Vainshtein , "MORTON JR., ALFRED C \(AL\)" , "opsawg-chairs@tools.ietf.org" , Sam Aldrin , "opsawg@ietf.org" , Elwyn Davies Subject: Re: [OPSAWG] Updated draft-ietf-opsawg-oam-overview X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 15:30:10 -0000 --Apple-Mail=_91D8F787-6B8B-45C4-94EA-54D49191EA94 Content-Type: multipart/alternative; boundary="Apple-Mail=_ECDDC72D-A55D-40B8-BA92-8852834B4501" --Apple-Mail=_ECDDC72D-A55D-40B8-BA92-8852834B4501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Apologies but I just realized I hadn't reviewed this document = post the Vancouver IETF meeting when I was asked. My comments are = included. I do not feel this document is ready to go forward as there = are some major omissions as noted below. --Tom I have reviewed this document. Comments inline start with TOM:. =20= General comments are: 1) Psedowire OAM message mapping and ethernet OAM are missing. 2) There is no discussion about OAM for L2VPN or L3VPN explicitly here. = It is important to explain this applicability. 3) BFD for MPLS is not explained. It is a very viable replacement for CV = instead of LSP Ping. --Tom Operations and Management Area Working Group T. Mizrahi Internet Draft Marvell Intended status: Informational N. Sprecher Expires: July 2014 NSN E. Bellagamba Ericsson Y. Weingarten January 9, 2014 An Overview of Operations, Administration, and Maintenance (OAM) Tools draft-ietf-opsawg-oam-overview-12.txt Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS for the transport profile (MPLS-TP), pseudowires, and TRILL. This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators and standard development organizations, and can be used as an index to some of the main OAM tools defined in the IETF. This document provides a brief description of each of the OAM tools in the IETF. At the end of the document a list of the OAM toolsets and a list of the OAM functions are presented as a summary. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Mizrahi, et al. Expires July 9, 2014 [Page 1] Internet-Draft Overview of OAM Tools January 2014 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 4 1.1. Background .............................................. 4 1.2. Target Audience.......................................... 5 1.3. OAM-related Work in the IETF ............................ 5 1.4. Focusing on the Data Plane .............................. 6 2. Terminology .................................................. 7 2.1. Abbreviations ........................................... 7 2.2. Terminology used in OAM Standards ....................... 9 2.2.1. General Terms ...................................... 9 2.2.2. Operations, Administration and Maintenance ......... 9 2.2.3. Functions, Tools and Protocols .................... 10 2.2.4. Data Plane, Control Plane and Management Plane .... 10 2.2.5. The Players ....................................... 11 2.2.6. Proactive and On-demand Activation ................ 12 2.2.7. Connectivity Verification and Continuity Checks ... 12 2.2.8. Connection Oriented vs. Connectionless Communication13 2.2.9. Point-to-point vs. Point-to-multipoint Services ... 14 Mizrahi, et al. Expires July 9, 2014 [Page 2] Internet-Draft Overview of OAM Tools January 2014 2.2.10. Failures ......................................... 15 3. OAM Functions ............................................... 15 4. OAM Tools in the IETF - a Detailed Description .............. 16 4.1. IP Ping ................................................ 16 4.2. IP Traceroute .......................................... 17 4.3. Bidirectional Forwarding Detection (BFD) ............... 18 4.3.1. Overview .......................................... 18 4.3.2. Terminology ....................................... 18 4.3.3. BFD Control ....................................... 18 4.3.4. BFD Echo .......................................... 19 4.4. MPLS OAM ............................................... 19 4.5. MPLS-TP OAM ............................................ 20 4.5.1. Overview .......................................... 20 4.5.2. Terminology ....................................... 21 4.5.3. Generic Associated Channel ........................ 22 4.5.4. MPLS-TP OAM Toolset ............................... 23 4.5.4.1. Continuity Check and Connectivity Verification 23 4.5.4.2. Route Tracing ................................ 24 4.5.4.3. Lock Instruct ................................ 24 4.5.4.4. Lock Reporting ............................... 24 4.5.4.5. Alarm Reporting .............................. 24 4.5.4.6. Remote Defect Indication ..................... 24 4.5.4.7. Client Failure Indication .................... 25 4.5.4.8. Performance Monitoring ....................... 25 4.5.4.8.1. Packet Loss Measurement (LM) ............ 25 4.5.4.8.2. Packet Delay Measurement (DM) ........... 25 4.6. Pseudowire OAM ......................................... 26 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification (VCCV) ...................................... 26 4.6.2. Pseudowire OAM using G-ACh ........................ 27 4.6.3. Attachment Circuit - Pseudowire Mapping ........... 27 4.7. OWAMP and TWAMP......................................... 27 4.7.1. Overview .......................................... 27 4.7.2. Control and Test Protocols ........................ 28 4.7.3. OWAMP ............................................. 29 4.7.4. TWAMP ............................................. 29 4.8. TRILL .................................................. 30 5. Summary ..................................................... 30 5.1. Summary of OAM Tools ................................... 31 5.2. Summary of OAM Functions ............................... 33 5.3. Guidance to Network Equipment Vendors .................. 34 6. Security Considerations ..................................... 34 7. IANA Considerations ......................................... 34 8. Acknowledgments ............................................. 35 9. References .................................................. 35 9.1. Informative References ................................. 35 Appendix A. List of OAM Documents .............................. 40 Mizrahi, et al. Expires July 9, 2014 [Page 3] Internet-Draft Overview of OAM Tools January 2014 A.1. List of IETF OAM Documents ............................. 40 A.2. List of Selected Non-IETF OAM Documents ................ 45 1. Introduction OAM is a general term that refers to a toolset for detecting, isolating and reporting failures and for monitoring the network performance. There are several different interpretations to the "OAM" acronym. This document refers to Operations, Administration and Maintenance, as recommended in Section 3 of [OAM-Def]. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS for the transport profile (MPLS-TP), pseudowires, and TRILL. This document focuses on tools for detecting and isolating failures and for performance monitoring. Hence, this document focuses on the tools used for monitoring and measuring the data plane; control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. 1.1. Background OAM was originally used in traditional communication technologies such as E1 and T1, evolving into PDH and then later in SONET/SDH. ATM was probably the first technology to include inherent OAM support from day one, while in other technologies OAM was typically defined in an ad hoc manner after the technology was already defined and deployed. Packet-based networks were traditionally considered unreliable and best-effort, but as packet-based networks evolved, they have become the common transport for both data and telephony, replacing traditional transport protocols. Consequently, packet-based networks were expected to provide a similar "carrier grade" experience, and specifically to support OAM. As typical networks have a multi-layer architecture, the set of OAM protocols similarly take a multi-layer structure; each layer has its own OAM protocols. Moreover, OAM can be used at different levels of hierarchy in the network to form a multi-layer OAM solution, as shown in the example in Figure 1. Figure 1 illustrates a network in which IP traffic between two customer edges is transported over an MPLS provider network. MPLS OAM Mizrahi, et al. Expires July 9, 2014 [Page 4] Internet-Draft Overview of OAM Tools January 2014 is used at the provider-level for monitoring the connection between the two provider edges, while IP OAM is used at the customer-level for monitoring the end-to-end connection between the two customer edges. |<-------------- Customer-level OAM -------------->| IP OAM (Ping, Traceroute, OWAMP, TWAMP) |<- Provider-level OAM ->| MPLS OAM (LSP Ping) +-----+ +----+ +----+ +-----+ | | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D| | | | | |-------| | MPLS | |-------| | | | IP | | | | IP | | +-----+ +----+ +----+ +-----+ Customer Provider Provider Customer Edge Edge Edge Edge Figure 1 Example: Multi-layer OAM 1.2. Target Audience The target audience of this document includes: o Standard development organizations - both IETF working groups and non-IETF organizations can benefit from this document when designing new OAM protocols, or when looking to reuse existing OAM tools for new technologies. o Network equipment vendors and network operators - can use this document as an index to some of the common IETF OAM tools. It should be noted that this document is not necessarily suitable for beginners without any background in OAM. 1.3. OAM-related Work in the IETF This memo provides an overview of the different sets of OAM tools defined by the IETF. The set of OAM tools described in this memo are applicable to IP unicast, MPLS, pseudowires, MPLS for the transport profile (MPLS-TP), and TRILL. While OAM tools that are applicable to other technologies exist, they are beyond the scope of this memo. Mizrahi, et al. Expires July 9, 2014 [Page 5] Internet-Draft Overview of OAM Tools January 2014 This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM-related work is outside the scope. The IETF has defined OAM protocols and tools in several different contexts. We roughly categorize these efforts into a few sets of OAM- related RFCs, listed in Table 1. Each set defines a logically-coupled set of RFCs, although the sets are in some cases intertwined by common tools and protocols. The discussion in this document is ordered according to these sets. +--------------+------------+ | Toolset | Transport | | | Technology | +--------------+------------+ |IP Ping | IPv4/IPv6 | +--------------+------------+ |IP Traceroute | IPv4/IPv6 | +--------------+------------+ |BFD | generic | +--------------+------------+ |MPLS OAM | MPLS | +--------------+------------+ |MPLS-TP OAM | MPLS-TP | +--------------+------------+ |Pseudowire OAM| Pseudowires| +--------------+------------+ |OWAMP and | IPv4/IPv6 | |TWAMP | | +--------------+------------+ |TRILL OAM | TRILL | +--------------+------------+ Table 1 OAM Toolset Packages in the IETF Documents This document focuses on OAM tools that have been developed in the IETF. A short summary of some of the significant OAM standards that have been developed in other standard organizations is presented in Appendix A.2. 1.4. Focusing on the Data Plane OAM tools may, and quite often do, work in conjunction with a control plane and/or management plane. OAM provides instrumentation tools for measuring and monitoring the data plane. OAM tools often use Mizrahi, et al. Expires July 9, 2014 [Page 6] Internet-Draft Overview of OAM Tools January 2014 control plane functions, e.g., to initialize OAM sessions and to exchange various parameters. The OAM tools communicate with the management plane to raise alarms, and often OAM tools may be activated by the management (as well as by the control plane), e.g. to locate and localize problems. The considerations of the control plane maintenance tools and the functionality of the management plane are out of scope for this document, which concentrates on presenting the data plane tools that are used for OAM. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. Since OAM protocols are used for monitoring the data plane, it is imperative for OAM tools to be capable of testing the actual data plane in as much accuracy as possible. Thus, it is important to enforce fate-sharing between OAM traffic that monitors the data plane and the data plane traffic it monitors. 2. Terminology 2.1. Abbreviations ACH Associated Channel Header AIS Alarm Indication Signal ATM Asynchronous Transfer Mode BFD Bidirectional Forwarding Detection CC Continuity Check CV Connectivity Verification DM Delay Measurement ECMP Equal Cost Multiple Paths FEC Forwarding Equivalence Class FRR Fast Reroute G-ACh Generic Associated Channel GAL Generic Associated Label Mizrahi, et al. Expires July 9, 2014 [Page 7] Internet-Draft Overview of OAM Tools January 2014 ICMP Internet Control Message Protocol L2TP Layer Two Tunneling Protocol LCCE L2TP Control Connection Endpoint LDP Label Distribution Protocol LER Label Edge Router LM Loss Measurement LSP Label Switched Path LSR Label Switched Router ME Maintenance Entity MEG Maintenance Entity Group MEP MEG End Point MIP MEG Intermediate Point MP Maintenance Point MPLS Multiprotocol Label Switching MPLS-TP MPLS Transport Profile MTU Maximum Transmission Unit OAM Operations, Administration, and Maintenance OWAMP One-way Active Measurement Protocol PDH Plesiochronous Digital Hierarchy PE Provider Edge PW Pseudowire PWE3 Pseudowire Emulation Edge-to-Edge RBridge Routing Bridge RDI Remote Defect Indication Mizrahi, et al. Expires July 9, 2014 [Page 8] Internet-Draft Overview of OAM Tools January 2014 SDH Synchronous Digital Hierarchy SONET Synchronous Optical Networking TRILL Transparent Interconnection of Lots of Links TTL Time To Live TWAMP Two-way Active Measurement Protocol VCCV Virtual Circuit Connectivity Verification 2.2. Terminology used in OAM Standards 2.2.1. General Terms A wide variety of terms is used in various OAM standards. This section presents a comparison of the terms used in various OAM standards, without fully quoting the definition of each term. An interesting overview of the term OAM and its derivatives is presented in [OAM-Def]. A thesaurus of terminology for MPLS-TP terms is presented in [TP-Term], and provides a good summary of some of the OAM related terminology. 2.2.2. Operations, Administration and Maintenance The following definition of OAM is quoted from [OAM-Def]: The components of the "OAM" acronym (and provisioning) are defined as follows: o Operations - Operation activities are undertaken to keep the network (and the services that the network provides) up and running. It includes monitoring the network and finding problems. Ideally these problems should be found before users are affected. o Administration - Administration activities involve keeping track of resources in the network and how they are used. It includes all the bookkeeping that is necessary to track networking resources and the network under control. Mizrahi, et al. Expires July 9, 2014 [Page 9] Internet-Draft Overview of OAM Tools January 2014 o Maintenance - Maintenance activities are focused on facilitating repairs and upgrades -- for example, when equipment must be replaced, when a router needs a patch for an operating system image, or when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run more effectively, e.g., adjusting device configuration and parameters. 2.2.3. Functions, Tools and Protocols OAM Function An OAM function is an instrumentation measurement type or diagnostic. OAM functions are the atomic building blocks of OAM, where each function defines an OAM capability. Typical examples of OAM functions are presented in Section 3. OAM Protocol A protocol used for implementing one or more OAM functions. The OWAMP-Test [OWAMP] is an example of an OAM protocol. OAM Tool An OAM tool is a specific means of applying one or more OAM functions. In some cases an OAM protocol *is* an OAM tool, e.g., OWAMP-Test. In other cases an OAM tool uses a set of protocols that are not strictly OAM-related; for example, Traceroute (Section 4.2.) can be implemented using UDP and ICMP messages, without using an OAM protocol per se. 2.2.4. Data Plane, Control Plane and Management Plane Data Plane The data plane is the set of functions used to transfer data in the stratum or layer under consideration [ITU-Terms]. The Data Plane is also known as the Forwarding Plane or the User Plane. Mizrahi, et al. Expires July 9, 2014 [Page 10] Internet-Draft Overview of OAM Tools January 2014 Control Plane The control plane is the set of protocols and mechanisms that enable routers to efficiently learn how to forward packets towards their final destination (based on [Comp]). Management Plane The term Management Plane, as described in [Mng], is used to describe the exchange of management messages through management protocols (often transported by IP and by IP transport protocols) between management applications and the managed entities such as network nodes. Data Plane vs. Control Plane vs. Management Plane The distinction between the planes is at times a bit vague. For example, the definition of "Control Plane" above may imply that OAM tools such as ping, BFD and others are in fact in the control plane. This document focuses on tools used for monitoring the data plane. While these tools could arguably be considered to be in the control plane, these tools monitor the data plane, and hence it is imperative to have fate-sharing between OAM traffic that monitors the data plane and the data plane traffic it monitors. Another potentially vague distinction is between the management plane and control plane. The management plane should be seen as separate from, but possibly overlapping with, the control plane (based on [Mng]). 2.2.5. The Players An OAM tool is used between two (or more) "players". Various terms are used in IETF documents to refer to the players that take part in OAM. Table 2 summarizes the terms used in each of the toolsets discussed in this document. +--------------------------+--------------------------+ | Toolset | Terms | +--------------------------+--------------------------+ | Ping / Traceroute |-Host | | ([ICMPv4], [ICMPv6], |-Node | | [TCPIP-Tools]) |-Interface | | |-Gateway | Mizrahi, et al. Expires July 9, 2014 [Page 11] Internet-Draft Overview of OAM Tools January 2014 + ------------------------ + ------------------------ + | BFD [BFD] | System | + ------------------------ + ------------------------ + | MPLS OAM [MPLS-OAM-FW] | LSR | + ------------------------ + ------------------------ + | MPLS-TP OAM [TP-OAM-FW] |-End Point - MEP | | |-Intermediate Point - MIP | + ------------------------ + ------------------------ + | Pseudowire OAM [VCCV] |-PE | | |-LCCE | + ------------------------ + ------------------------ + | OWAMP and TWAMP |-Host | | ([OWAMP], [TWAMP]) |-End system | + ------------------------ + ------------------------ + | TRILL OAM [TRILL-OAM] |-RBridge | +--------------------------+--------------------------+ Table 2 Maintenance Point Terminology 2.2.6. Proactive and On-demand Activation The different OAM tools may be used in one of two basic types of activation: Proactive Proactive activation - indicates that the tool is activated on a continual basis, where messages are sent periodically, and errors are detected when a certain number of expected messages are not received. On-demand On-demand activation - indicates that the tool is activated "manually" to detect a specific anomaly. 2.2.7. 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. Continuity Check Mizrahi, et al. Expires July 9, 2014 [Page 12] Internet-Draft Overview of OAM Tools January 2014 Continuity checks are used to verify that a destination is reachable, and are typically sent proactively, though they can be invoked on- demand as well. Connectivity Verification A connectivity verification function allows Alice to check whether she is connected to Bob or not. It is noted that while the CV function is performed in the data plane, the "expected path" is predetermined either in the control plane or in the management plane. A connectivity verification (CV) protocol typically uses a CV message, followed by a CV reply that is sent back to the originator. A CV function can be applied proactively or on-demand. Connectivity Verification tools often perform path verification as well, allowing Alice to verify that messages from Bob are received through the correct path, thereby verifying not only that the two MPs are connected, but also that they are connected through the expected path, allowing detection of unexpected topology changes. Connectivity verification and continuity checks are considered complementary mechanisms, and are often used in conjunction with each other. 2.2.8. Connection Oriented vs. Connectionless Communication Connection Oriented In Connection Oriented technologies an end-to-end connection is established (by a control protocol or provisioned by a management system) prior to the transmission of data. Typically a connection identifier is used to identify the connection. In connection oriented technologies it is often the case (although not always) that all packets belonging to a specific connection use the same route through the network. Connectionless In Connectionless technologies data is typically sent between end points without prior arrangement. Packets are routed independently based on their destination address, and hence different packets may be routed in a different way across the network. Discussion Mizrahi, et al. Expires July 9, 2014 [Page 13] Internet-Draft Overview of OAM Tools January 2014 The OAM tools described in this document include tools that support connection oriented technologies, as well as tools for connectionless technologies. In connection oriented technologies OAM is used to monitor a *specific* connection; OAM packets are forwarded through the same route as the data traffic and receive the same treatment. In connectionless technologies, OAM is used between a source and destination pair without defining a specific connection. Moreover, in some cases the route of OAM packets may differ from the one of the data traffic. For example, the connectionless IP Ping (Section 4.1.) tests the reachability from a source to a given destination, while the connection oriented LSP Ping (Section 4.4.) is used for monitoring a specific LSP (connection), and provides the capability to monitor all the available paths used by an LSP. It should be noted that in some cases connectionless protocols are monitored by connection oriented OAM protocols. For example, while IP is a connectionless protocol, it can monitored by BFD (Section 4.3. ), which is connection oriented. 2.2.9. Point-to-point vs. Point-to-multipoint Services Point-to-point (P2P) A P2P service delivers data from a single source to a single destination. Point-to-multipoint (P2MP) A P2MP service delivers data from a single source to a one or more destinations (based on [Signal]). An MP2MP service is a service that delivers data from more than one source to one or more receivers (based on [Signal]). Note: the two definitions for P2MP and MP2MP are quoted from [Signal]. Although [Signal] describes a specific case of P2MP and MP2MP which is MPLS-specific, these two definitions also apply to non-MPLS cases. Discussion The OAM tools described in this document include tools for P2P services, as well as tools for P2MP services. Mizrahi, et al. Expires July 9, 2014 [Page 14] Internet-Draft Overview of OAM Tools January 2014 The distinction between P2P services and P2MP services affects the corresponding OAM tools. A P2P service is typically simpler to monitor, as it consists of a single pair of end points. P2MP services present several challenges. For example, in a P2MP service, the OAM mechanism not only verifies that each of the destinations is reachable from the source, but also verifies that the P2MP distribution tree is intact and loop-free. 2.2.10. Failures The terms Failure, Fault, and Defect are used interchangeably in the standards, referring to a malfunction that can be detected by a connectivity or a continuity check. In some standards, such as 802.1ag [IEEE802.1Q] , there is no distinction between these terms, while in other standards each of these terms refers to a different type of malfunction. The terminology used in IETF MPLS-TP OAM is based on the ITU-T terminology, which distinguishes between these three terms in [ITU-T-G.806]; Fault The term Fault refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. Defect The term Defect refers to an interruption in the normal operation, such as a consecutive period of time where no packets are delivered successfully. Failure The term Failure refers to the termination of the required function. While a Defect typically refers to a limited period of time, a failure refers to a long period of time. 3. OAM Functions This subsection provides a brief summary of the common OAM functions used in OAM-related standards. These functions are used as building blocks in the OAM standards described in this document. o Connectivity Verification (CV), Path Verification and Continuity Checks (CC): As defined in Section 2.2.7. Mizrahi, et al. Expires July 9, 2014 [Page 15] Internet-Draft Overview of OAM Tools January 2014 o Path Discovery / Fault Localization: This function can be used to trace the route to a destination, i.e., to identify the nodes along the route to the destination. When more than one route is available to a specific destination, this function traces one of the available routes. When a failure occurs, this function also allows to detect the location of the failure. Note that the term route tracing (or Traceroute) that is used in the context of IP and MPLS, is sometimes referred to as path tracing in the context of other protocols, such as TRILL. o Performance Monitoring: Typically refers to: o Loss Measurement (LM) - monitors the packet loss rate. o Delay Measurement (DM) - monitors the delay and delay variation. 4. OAM Tools in the IETF - a Detailed Description This section presents a detailed description of the sets of OAM- related tools in each of the toolsets in Table 1. 4.1. IP Ping Ping is a common network diagnosis application for IP networks that uses ICMP. According to [NetTerms], 'Ping' is an abbreviation for Packet internet groper, although the term has been so commonly used that it stands on its own. As defined in [NetTerms], it is a program used to test reachability of destinations by sending them an ICMP echo request and waiting for a reply. The ICMP Echo request/reply exchange in Ping is used as a continuity check function for the Internet Protocol. The originator transmits an ICMP Echo request packet, and the receiver replies with an Echo reply. ICMP ping is defined in two variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6. Ping implementations typically use ICMP messages. UDP Ping is a variant that uses UDP messages instead of ICMP echo messages. Ping is a single-ended continuity check, i.e., it allows the *initiator* of the Echo request to test the reachability. If it is desirable for both ends to test the reachability, both ends have to invoke Ping independently. Mizrahi, et al. Expires July 9, 2014 [Page 16] Internet-Draft Overview of OAM Tools January 2014 Note that since ICMP filtering is deployed in some routers and firewalls, the usefulness of Ping is sometimes limited in the wider internet. This limitation is equally relevant to Traceroute. 4.2. IP Traceroute Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to discover a path between an IP source and an IP destination. The most common way to implement Traceroute [TCPIP-Tools] is described as follows. Traceroute sends a sequence of UDP packets to UDP port 33434 at the destination. By default, Traceroute begins by sending three packets (the number of packets is configurable in most Traceroute implementations), each with an IP Time-To-Live (or Hop Limit in IPv6) value of one to the destination. These packets expire as soon as they reach the first router in the path. Consequently, that router sends three ICMP Time Exceeded Messages back to the Traceroute application. Traceroute now sends another three UDP packets, each with the TTL value of 2. These messages cause the second router to return ICMP messages. This process continues, with ever increasing values for the TTL field, until the packets actually reach the destination. Because no application listens to port 33434 at the destination, the destination returns ICMP Destination Unreachable Messages indicating an unreachable port. This event indicates to the Traceroute application that it is finished. The Traceroute program displays the round-trip delay associated with each of the attempts. While Traceroute is a tool that finds *a* path from A to B, it should be noted that traffic from A to B is often forwarded through Equal Cost Multiple Paths (ECMP). Paris Traceroute [PARIS] is an extension to Traceroute that attempts to discovers all the available paths from A to B by scanning different values of header fields (such as UDP ports) in the probe packets. It is noted that Traceroute is an application, and not a protocol. As such, it has various different implementations. One of the most common ones uses UDP probe packets, as described above. Other implementations exist that use other types of probe messages, such as ICMP or TCP. Note that IP routing may be asymmetric. While Traceroute discovers a path between a source and destination, it does not reveal the reverse path. A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in the context of Traceroute. These documents define several extensions, Mizrahi, et al. Expires July 9, 2014 [Page 17] Internet-Draft Overview of OAM Tools January 2014 including extensions to the ICMP Destination Unreachable message, that can be used by Traceroute applications. 4.3. Bidirectional Forwarding Detection (BFD) 4.3.1. Overview While multiple OAM tools have been defined for various protocols in the protocol stack, Bidirectional Forwarding Detection [BFD], defined by the IETF BFD working group, is a generic OAM tool that can be deployed over various encapsulating protocols, and in various medium types. The IETF has defined variants of the protocol for IP ([BFD- IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires [BFD- VCCV]. The usage of BFD in MPLS-TP is defined in [TP-CC-CV]. BFD includes two main OAM functions, using two types of BFD packets: BFD Control packets, and BFD Echo packets. 4.3.2. Terminology BFD operates between *systems*. The BFD protocol is run between two or more systems after establishing a *session*. 4.3.3. BFD Control BFD supports a bidirectional continuity check, using BFD control packets, that are exchanged within a BFD session. BFD sessions operate in one of two modes: o Asynchronous mode (i.e. proactive): in this mode BFD control packets are sent periodically. When the receiver detects that no BFD control packets have been received during a predetermined period of time, a failure is detected. o Demand mode: in this mode, BFD control packets are sent on-demand. Upon need, a system initiates a series of BFD control packets to check the continuity of the session. BFD control packets are sent independently in each direction. Each of the end-points (referred to as systems) of the monitored path maintains its own session identification, called a Discriminator, both of which are included in the BFD Control Packets that are exchanged between the end-points. At the time of session establishment, the Discriminators are exchanged between the two-end points. In addition, the transmission (and reception) rate is negotiated between the two end-points, based on information included Mizrahi, et al. Expires July 9, 2014 [Page 18] Internet-Draft Overview of OAM Tools January 2014 in the control packets. These transmission rates may be renegotiated during the session. During normal operation of the session, i.e. no failures are detected, the BFD session is in the Up state. If no BFD Control packets are received during a period of time called the Detection Time, the session is declared to be Down. The detection time is a function of the pre-configured or negotiated transmission time, and a parameter called Detect Mult. Detect Mult determines the number of missing BFD Control packets that cause the session to be declared as Down. This parameter is included in the BFD Control packet. 4.3.4. BFD Echo A BFD echo packet is sent to a peer system, and is looped back to the originator. The echo function can be used proactively, or on-demand. The BFD echo function has been defined in BFD for IPv4 and IPv6 ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for MPLS-TP. 4.4. MPLS OAM The IETF MPLS working group has defined OAM for MPLS LSPs. The requirements and framework of this effort are defined in [MPLS-OAM-FW] and [MPLS-OAM], respectively. The corresponding OAM tool defined, in this context, is LSP Ping [LSP-Ping]. OAM for P2MP services is defined in [MPLS-P2MP]. LSP Ping is modeled after the Ping/Traceroute paradigm and thus it may be used in one of two modes: o "Ping" mode: In this mode LSP Ping is used for end-to-end connectivity verification between two LERs. o "Traceroute" mode: This mode is used for hop-by-hop fault isolation. LSP Ping extends the basic ICMP Ping operation (of data-plane connectivity verification) with functionality to verify data-plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC) and also Maximum Transmission Unit (MTU) problems. TOM: This is misleading. LSP Ping does not extend any part of ICMP = operation; its a completely new operation that is native to MPLS. It is = important not to conflate these two things, as there are proprietary = versions of ICMP ping extended for MPLS that DO NOT work in all cases. = This is why LSP Ping was invented (and trace). The Traceroute functionality may be used to isolate and localize the MPLS faults, using the Time-to-live (TTL) indicator to incrementally identify the sub-path of the LSP that is successfully traversed before the faulty link or node. TOM: There is more to the LSP Traceroute than just using TTL. Please = review the RFC for details. Mizrahi, et al. Expires July 9, 2014 [Page 19] Internet-Draft Overview of OAM Tools January 2014 The challenge in MPLS networks is that the traffic of a given LSP may be load balanced across Equal Cost Multiple paths (ECMP). LSP Ping monitors all the available paths of an LSP by monitoring its different Forwarding Equivalence Classes (FEC). Conversely, MPLS-TP does not use ECMP, and thus does not require OAM over multiple paths. TOM: Why "conversely"? You imply that MPLS-TP is "better" somehow with = that statement; its different. =20 Another challenge is that an MPLS LSP does not necessarily have a return path, and thus responding to an LSP Ping message is not TOM: Strictily speaking, an LSP does not have a return path. There is a = return route at the other end that is used to return the response = message. This can be a different MPLS LSP, IP or whatever. necessarily as trivial as in IP Ping, where the responder just swaps the source and destination IP addresses. Note that this challenge is not applicable to MPLS-TP, where a return path is always available. It should be noted that LSP Ping supports unique identification of the LSP within an addressing domain. The identification is checked using the full FEC identification. LSP Ping is easily extensible to include additional information needed to support new functionality, by use of Type-Length-Value (TLV) constructs. The usage of TLVs is typically not easy to perform in hardware, and is thus typically handled by the control plane. LSP Ping supports both asynchronous, as well as, on-demand activation. 4.5. MPLS-TP OAM 4.5.1. Overview The MPLS working group has defined the OAM toolset that fulfills the requirements for MPLS-TP OAM. The full set of requirements for MPLS- TP OAM are defined in [MPLS-TP-OAM], and include both general requirements for the behavior of the OAM tools and a set of operations that should be supported by the OAM toolset. The set of mechanisms required are further elaborated in [TP-OAM-FW], which describes the general architecture of the OAM system as well as giving overviews of the functionality of the OAM toolset. Some of the basic requirements for the OAM toolset for MPLS-TP are: o MPLS-TP OAM must be able to support both an IP based and non-IP based environment. If the network is IP based, i.e. IP routing and forwarding are available, then the MPLS-TP OAM toolset should rely on the IP routing and forwarding capabilities. On the other hand, in environments where IP functionality is not available, the OAM tools must still be able to operate without dependence on IP forwarding and routing. Mizrahi, et al. Expires July 9, 2014 [Page 20] Internet-Draft Overview of OAM Tools January 2014 o OAM packets and the user traffic are required to be congruent (i.e. OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from data plane ones. Inherent in this requirement is the principle that MPLS-TP OAM be independent of any existing control-plane, although it should not preclude use of the control-plane functionality. OAM packets are identified by the Generic Associated Label (GAL), which is a reserved MPLS label value (13). 4.5.2. Terminology Maintenance Entity (ME) The MPLS-TP OAM tools are designed to monitor and manage a Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a relationship between two points of a transport path to which maintenance and monitoring operations apply. The term Maintenance Entity (ME) is used in ITU-T Recommendations (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology ([TP-OAM-FW]). Maintenance Entity Group (MEG) The collection of one or more MEs that belongs to the same transport path and that are maintained and monitored as a group are known as a Maintenance Entity Group (based on [TP-OAM-FW]). Maintenance Point (MP) A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and can initiate and/or react to OAM messages. This document focuses on the data-plane functionality of MPs, while MPs interact with the control plane and with the management plane as well. The term MP is used in IEEE 802.1ag, and was similarly adopted in MPLS-TP ([TP-OAM-FW]). Maintenance End Point (MEP) A Maintenance End Point (MEP) is one of the end points of an ME, and can initiate OAM messages and respond to them (based on [TP-OAM-FW]). Maintenance Intermediate Point (MIP) Mizrahi, et al. Expires July 9, 2014 [Page 21] Internet-Draft Overview of OAM Tools January 2014 In between MEPs, there are zero or more intermediate points, called Maintenance Entity Group Intermediate Points (based on [TP-OAM-FW]). A Maintenance Intermediate Point (MIP) is an intermediate point that does not generally initiate OAM frames (one exception to this is the use of AIS notifications), but is able to respond to OAM frames that are destined to it. A MIP in MPLS-TP identifies OAM packets destined to it by the value of the TTL field in the OAM packet. The term Maintenance Point is a general term for MEPs and MIPs. Up and Down MEPs The IEEE 802.1ag [IEEE802.1Q] defines a distinction between Up MEPs and Down MEPs. A MEP is a bridge interface that is monitored by an OAM protocol either in the direction facing the network, or in the direction facing the bridge. A Down MEP is a MEP that receives OAM packets from, and transmits them to the direction of the network. An Up MEP receives OAM packets from, and transmits them to the direction of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the MEP - either at the ingress, egress, or forwarding function of the node (Down / Up MEPs). This placement is important for localization of a failure. The distinction between Up and Down MEPs was defined in [TP-OAM-FW], but has not been used in other MPLS-TP RFCs, as of the writing of this document. 4.5.3. Generic Associated Channel In order to address the requirement for in-band transmission of MPLS- TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based on the same concepts as the PWE3 ACH and VCCV mechanisms. However, to address the needs of LSPs as differentiated from PW, the following concepts were defined for [G-ACh]: o An Associated Channel Header (ACH), that uses a format similar to the PW Control Word, is a 4-byte header that is prepended to OAM packets. o A Generic Associated Label (GAL). The GAL is a reserved MPLS label value (13) that indicates that the packet is an ACH packet and the payload follows immediately after the label stack. It should be noted that while the G-ACh was defined as part of the MPLS-TP definition effort, the G-ACh is a generic tool that can be used in MPLS in general, and not only in MPLS-TP. Mizrahi, et al. Expires July 9, 2014 [Page 22] Internet-Draft Overview of OAM Tools January 2014 4.5.4. MPLS-TP OAM Toolset To address the functionality that is required of the OAM toolset, the MPLS WG conducted an analysis of the existing IETF and ITU-T OAM tools and their ability to fulfill the required functionality. The conclusions of this analysis are documented in [OAM-Analys]. The MPLS working group currently plans to use a mixture of OAM tools that are based on various existing standards, and adapt them to the requirements of [MPLS-TP-OAM]. Some of the main building blocks of this solution are based on: o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for proactive continuity check and connectivity verification. o LSP Ping as defined in [LSP-Ping] for on-demand connectivity verification. o New protocol packets, using G-ACH, to address different functionality. o Performance measurement protocols that are based on the functionality that is described in [ITU-T-Y1731]. The following sub-sections describe the OAM tools defined for MPLS-TP as described in [TP-OAM-FW]. 4.5.4.1. Continuity Check and Connectivity Verification Continuity Check and Connectivity Verification are presented in Section 2.2.7. of this document. As presented there, these tools may be used either proactively or on-demand. When using these tools proactively, they are generally used in tandem. For MPLS-TP there are two distinct tools, the proactive tool is defined in [TP-CC-CV] while the on-demand tool is defined in [OnDemand-CV]. In on-demand mode, this function should support monitoring between the MEPs and, in addition, between a MEP and MIP. [TP-OAM-FW] highlights, when performing Connectivity Verification, the need for the CC-V messages to include unique identification of the MEG that is being monitored and the MEP that originated the message. The proactive tool [TP-CC-CV] is based on extensions to BFD (see Section 4.3.) with the additional limitation that the transmission and receiving rates are based on configuration by the operator. The on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see Section 4.4.) for the required behavior of MPLS-TP. Mizrahi, et al. Expires July 9, 2014 [Page 23] Internet-Draft Overview of OAM Tools January 2014 4.5.4.2. Route Tracing [MPLS-TP-OAM] defines that there is a need for functionality that would allow a path end-point to identify the intermediate and end- points of the path. This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP, and sections, however, unidirectional paths may be supported only if a return path exists. The tool for this is based on the LSP Ping (see Section 4.4.) functionality and is described in [OnDemand-CV]. 4.5.4.3. Lock Instruct The Lock Instruct function [Lock-Loop] is used to notify a transport path end-point of an administrative need to disable the transport path. This functionality will generally be used in conjunction with some intrusive OAM function, e.g. Performance measurement, Diagnostic testing, to minimize the side-effect on user data traffic. 4.5.4.4. Lock Reporting Lock Reporting is a function used by an end-point of a path to report to its far-end end-point that a lock condition has been affected on the path. 4.5.4.5. Alarm Reporting Alarm Reporting [TP-Fault] provides the means to suppress alarms following detection of defect conditions at the server sub-layer. Alarm reporting is used by an intermediate point of a path, that becomes aware of a fault on the path, to report to the end-points of the path. [TP-OAM-FW] states that this may occur as a result of a defect condition discovered at a server sub-layer. This generates an Alarm Indication Signal (AIS) that continues until the fault is cleared. The consequent action of this function is detailed in [TP-OAM-FW]. 4.5.4.6. Remote Defect Indication Remote Defect Indication (RDI) is used proactively by a path end- point to report to its peer end-point that a defect is detected on a bidirectional connection between them. [MPLS-TP-OAM] points out that this function may be applied to a unidirectional LSP only if there a return path exists. [TP-OAM-FW] points out that this function is associated with the proactive CC-V function. Mizrahi, et al. Expires July 9, 2014 [Page 24] Internet-Draft Overview of OAM Tools January 2014 4.5.4.7. Client Failure Indication Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow the propagation information from one edge of the network to the other. The information concerns a defect to a client, in the case that the client does not support alarm notification. 4.5.4.8. Performance Monitoring The definition of MPLS performance monitoring was motivated by the MPLS-TP requirements [MPLS-TP-OAM], but was defined generically for MPLS in [MPLS-LM-DM]. An additional document [TP-LM-DM] defines a performance monitoring profile for MPLS-TP. 4.5.4.8.1. Packet Loss Measurement (LM) Packet Loss Measurement is a function used to verify the quality of the service. Packet loss, as defined in [IPPM-1LM] and [MPLS-TP-OAM], indicates the ratio of the number of user packets lost to the total number of user packets sent during a defined time interval. There are two possible ways of determining this measurement: o Using OAM packets, it is possible to compute the statistics based on a series of OAM packets. This, however, has the disadvantage of being artificial, and may not be representative since part of the packet loss may be dependent upon packet sizes and upon the implementation of the MEPs that take part in the protocol. o Sending delimiting messages for the start and end of a measurement period during which the source and sink of the path count the packets transmitted and received. After the end delimiter, the ratio would be calculated by the path OAM entity. 4.5.4.8.2. Packet Delay Measurement (DM) Packet Delay Measurement is a function that is used to measure one- way or two-way delay of a packet transmission between a pair of the end-points of a path (PW, LSP, or Section). Where: o One-way packet delay, as defined in [IPPM-1DM], is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of that packet by the destination node. Note that one-way delay measurement requires the clocks of the two end-points to be synchronized. Mizrahi, et al. Expires July 9, 2014 [Page 25] Internet-Draft Overview of OAM Tools January 2014 o Two-way packet delay, as defined in [IPPM-2DM], is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop-backed packet by the same source node, when the loopback is performed at the packet's destination node. Note that due to possible path asymmetry, the one-way packet delay from one end- point to another is not necessarily equal to half of the two-way packet delay. As opposed to one-way delay measurement, two-way delay measurement does not require the two end-points to be synchronized. For each of these two metrics, the DM function allows the MEP to measure the delay, as well as the delay variation. Delay measurement is performed by exchanging timestamped OAM packets between the participating MEPs. 4.6. Pseudowire OAM 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification (VCCV) VCCV, as defined in [VCCV], provides a means for end-to-end fault detection and diagnostics tools to be extended for PWs (regardless of TOM: Why "to be extended"? They've already been extended. the underlying tunneling technology). The VCCV switching function provides a control channel associated with each PW. [VCCV] defines three Control Channel (CC) types, i.e., three possible methods for transmitting and identifying OAM messages: o CC Type 1: In-band VCCV, as described in [VCCV], is also referred to as "PWE3 Control Word with 0001b as first nibble". It uses the PW Associated Channel Header [PW-ACH]. o CC Type 2: Out-of-band VCCV [VCCV], is also referred to as "MPLS Router Alert Label". In this case the control channel is created by using the MPLS router alert label [MPLS-ENCAPS] immediately above the PW label. o CC Type 3: TTL expiry VCCV [VCCV], is also referred to as "MPLS PW Label with TTL =3D=3D 1", i.e., the control channel is identified = when the value of the TTL field in the PW label is set to 1. VCCV currently supports the following OAM tools: ICMP Ping, LSP Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of encapsulation - either IP/UDP encapsulated (with IP/UDP header) or PW-ACH encapsulated (with no IP/UDP header) and provides support to signal the AC status. The use of the VCCV control channel provides Mizrahi, et al. Expires July 9, 2014 [Page 26] Internet-Draft Overview of OAM Tools January 2014 the context, based on the MPLS-PW label, required to bind and bootstrap the BFD session to a particular pseudo wire (FEC), eliminating the need to exchange Discriminator values. VCCV consists of two components: (1) signaled component to communicate VCCV capabilities as part of VC label, and (2) switching component to cause the PW payload to be treated as a control packet. VCCV is not directly dependent upon the presence of a control plane. The VCCV capability negotiation may be performed as part of the PW TOM: There is not really a capability "negotiation" per se; its a = capability advertisement with strict and explicit rules for what each = end should do when it receives capability advertisements.=20 signaling when LDP is used. In case of manual configuration of the PW, it is the responsibility of the operator to set consistent options at both ends. The manual option was created specifically to handle MPLS-TP use cases where no control plane was a requirement. However, new use cases such as pure mobile backhaul find this functionality useful too. The PWE3 working group has conducted an implementation survey of VCCV [VCCV-SURVEY], which analyzes which VCCV mechanisms are used in practice. 4.6.2. Pseudowire OAM using G-ACh As mentioned above, VCCV enables OAM for PWs by using a control channel for OAM packets. When PWs are used in MPLS-TP networks, rather than the control channels defined in VCCV, the G-ACh can be used as an alternative control channel. The usage of the G-ACh for PWs is defined in [PW-G-ACh]. 4.6.3. Attachment Circuit - Pseudowire Mapping The PWE3 working group has defined a mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. This mapping is of key importance to the end-to-end functionality. Specifically, the mapping is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and Section 5.3 of [ATM-L2] for ATM. 4.7. OWAMP and TWAMP 4.7.1. Overview The IPPM working group in the IETF defines common criteria and metrics for measuring performance of IP traffic ([IPPM-FW]). Some of the key RFCs published by this working group have defined metrics for measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), and packet loss [IPPM-1LM]. It should be noted that the work of the Mizrahi, et al. Expires July 9, 2014 [Page 27] Internet-Draft Overview of OAM Tools January 2014 IETF in the context of performance metrics is not limited to IP networks; [PM-CONS] presents general guidelines for considering new performance metrics. The IPPM working group has defined not only metrics for performance measurement, but also protocols that define how the measurement is carried out. The One-way Active Measurement Protocol [OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] define a method and protocol for measuring performance metrics in IP networks. OWAMP [OWAMP] enables measurement of one-way characteristics of IP networks, such as one-way packet loss and one-way delay. For its proper operation OWAMP requires accurate time of day setting at its end points. TWAMP [TWAMP] is a similar protocol that enables measurement of both one-way and two-way (round trip) characteristics. OWAMP and TWAMP are both comprised of two separate protocols: o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop test sessions and to fetch their results. Continuity Check and Connectivity Verification are tested and confirmed by establishing the OWAMP/TWAMP Control Protocol TCP connection. o OWAMP-Test/TWAMP-Test: used to exchange test packets between two measurement nodes. Enables the loss and delay measurement functions, as well as detection of other anomalies, such as packet duplication and packet reordering. It should be noted that while [OWAMP] and [TWAMP] define tools for performance measurement, they do not define the accuracy of these tools. The accuracy depends on scale, implementation and network configurations. Alternative protocols for performance monitoring are defined, for example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet OAM [ITU-T-Y1731]. 4.7.2. Control and Test Protocols OWAMP and TWAMP control protocols run over TCP, while the test protocols run over UDP. The purpose of the control protocols is to initiate, start, and stop test sessions, and for OWAMP to fetch results. The test protocols introduce test packets (which contain sequence numbers and timestamps) along the IP path under test according to a schedule, and record statistics of packet arrival. Mizrahi, et al. Expires July 9, 2014 [Page 28] Internet-Draft Overview of OAM Tools January 2014 Multiple sessions may be simultaneously defined, each with a session identifier, and defining the number of packets to be sent, the amount of padding to be added (and thus the packet size), the start time, and the send schedule (which can be either a constant time between test packets or exponentially distributed pseudo-random). Statistics recorded conform to the relevant IPPM RFCs. OWAMP and TWAMP test traffic is designed with security in mind. Test packets are hard to detect because they are simply UDP streams between negotiated port numbers, with potentially nothing static in the packets. OWAMP and TWAMP also include optional authentication and encryption for both control and test packets. 4.7.3. OWAMP OWAMP defines the following logical roles: Session-Sender, Session- Receiver, Server, Control-Client, and Fetch-Client. The Session- Sender originates test traffic that is received by the Session- Receiver. The Server configures and manages the session, as well as returning the results. The Control-Client initiates requests for test sessions, triggers their start, and may trigger their termination. The Fetch-Client requests the results of a completed session. Multiple roles may be combined in a single host - for example, one host may play the roles of Control-Client, Fetch-Client, and Session-Sender, and a second playing the roles of Server and Session-Receiver. In a typical OWAMP session the Control-Client establishes a TCP connection to port 861 of the Server, which responds with a server greeting message indicating supported security/integrity modes. The Control-Client responds with the chosen communications mode and the Server accepts the modes. The Control-Client then requests and fully describes a test session to which the Server responds with its acceptance and supporting information. More than one test session may be requested with additional messages. The Control-Client then starts a test session and the Server acknowledges. The Session- Sender then sends test packets with pseudorandom padding to the Session-Receiver until the session is complete or until the Control- client stops the session. Once finished, the Fetch-Client sends a fetch request to the server, which responds with an acknowledgement and immediately thereafter the result data. 4.7.4. TWAMP TWAMP defines the following logical roles: session-sender, session- reflector, server, and control-client. These are similar to the Mizrahi, et al. Expires July 9, 2014 [Page 29] Internet-Draft Overview of OAM Tools January 2014 OWAMP roles, except that the Session-Reflector does not collect any packet information, and there is no need for a Fetch-Client. In a typical TWAMP session the Control-Client establishes a TCP connection to port 862 of the Server, and mode is negotiated as in OWAMP. The Control-Client then requests sessions and starts them. The Session-Sender sends test packets with pseudorandom padding to the Session-Reflector which returns them with insertion of timestamps. 4.8. TRILL The requirements of OAM in TRILL are defined in [TRILL-OAM]. The challenge in TRILL OAM, much like in MPLS networks, is that traffic between RBridges RB1 and RB2 may be forwarded through more than one path. Thus, an OAM protocol between RBridges RB1 and RB2 must be able to monitor all the available paths between the two RBridge. During the writing of this document the detailed definition of the TRILL OAM tools are still work in progress. This subsection presents the main requirements of TRILL OAM. The main requirements defined in [TRILL-OAM] are: o Continuity Checking (CC) - the TRILL OAM protocol must support a function for CC between any two RBridges RB1 and RB2. o Connectivity Verification (CV) - connectivity between two RBridges RB1 and RB2 can be verified on a per-flow basis. o Path Tracing - allows an RBridge to trace all the available paths to a peer RBridge. o Performance monitoring - allows an RBridge to monitor the packet loss and packet delay to a peer RBridge. 5. Summary This section summarizes the OAM tools and functions presented in this document. This summary is an index to some of the main OAM tools defined in the IETF. This compact index that can be useful to all readers from network operators to standard development organizations. The summary includes a short subsection that presents some guidance to network equipment vendors. Mizrahi, et al. Expires July 9, 2014 [Page 30] Internet-Draft Overview of OAM Tools January 2014 5.1. Summary of OAM Tools This subsection provides a short summary of each of the OAM toolsets described in this document. A detailed list of the RFCs related to each toolset is given in Appendix A.1. +-----------+------------------------------------------+------------+ | Toolset | Description | Transport | | | | Technology | +-----------+------------------------------------------+------------+ |IP Ping | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6 | | | application for testing reachability that| | | | uses ICMP Echo messages ([ICMPv4], | | | | [ICMPv6]). | | +-----------+------------------------------------------+------------+ |IP | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 | |Traceroute | an application that allows users to trace| | | | the path between an IP source and an IP | | | | destination, i.e., to identify the nodes | | | | along the path. If more than one path | | | | exists between the source and destination| | | | Traceroute traces *a* path. The most | | | | common implementation of Traceroute | | | | uses UDP probe messages, although there | | | | are other implementations that use | | | | different probes, such as ICMP or TCP. | | +-----------+------------------------------------------+------------+ |BFD | Bidirectional Forwarding Detection (BFD) | generic | | | is defined in [BFD] as a framework for a | | | | lightweight generic OAM tool. The | | | | intention is to define a base tool | | | | that can be used with various | | | | encapsulation types, network | | | | environments, and in various medium | | | | types. | | +-----------+------------------------------------------+------------+ |MPLS OAM | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS | | | [MPLS-OAM-FW] and [LSP-Ping], is an OAM | | | | tool for point-to-point and | | | | point-to-multipoint MLPS LSPs. | | Mizrahi, et al. Expires July 9, 2014 [Page 31] Internet-Draft Overview of OAM Tools January 2014 | | It includes two main functions: Ping and | | | | Traceroute. | | | | It is noted that while this category | | | | focuses on LSP Ping, other OAM tools | | | | can be used in MPLS networks, e.g., BFD. | | +-----------+------------------------------------------+------------+ |MPLS-TP OAM| MPLS-TP OAM is defined in a set of RFCs. | MPLS-TP | | | The OAM requirements for MPLS Transport | | | | Profile (MPLS-TP) are defined in | | | | [MPLS-TP-OAM]. Each of the tools in the | | | | OAM toolset is defined in its own RFC, as| | | | specified in Section A.1. | | +-----------+------------------------------------------+------------+ |Pseudowire | The PWE3 OAM architecture defines control| Pseudowire | |OAM | channels that support the use of existing| | | | IETF OAM tools to be used for a pseudo- | | | | wire (PW). The control channels that are| | | | defined in [VCCV] and [PW-G-ACh] may be | | | | used in conjunction with ICMP Ping, LSP | | | | Ping, and BFD to perform CC and CV | | | | functionality. In addition the channels | | | | support use of any of the MPLS-TP based | | | | OAM tools for completing their respective| | | | OAM functionality for a PW. | | +-----------+------------------------------------------+------------+ |OWAMP and | The One Way Active Measurement Protocol | IPv4/IPv6 | |TWAMP | (OWAMP) and the Two Way Active Measure- | | | | ment Protocols (TWAMP) are two protocols | | | | defined in the IP Performance Metrics | | | | (IPPM) working group in the IETF. These | | | | protocols allow various performance | | | | metrics to be measured, such as packet | | | | loss, delay and delay variation, | | | | duplication and reordering. | | +-----------+------------------------------------------+------------+ |TRILL OAM | The requirements of OAM in TRILL are | TRILL | | | defined in [TRILL-OAM]. These | | | | requirements include continuity checking,| | | | connectivity verification, path tracing | | | | and performance monitoring. During the | | | | writing of this document the detailed | | Mizrahi, et al. Expires July 9, 2014 [Page 32] Internet-Draft Overview of OAM Tools January 2014 | | definition of the TRILL OAM tools | | | | is work in progress. | | +-----------+------------------------------------------+------------+ Table 3 Summary of OAM-related IETF Tools 5.2. Summary of OAM Functions Table 4 summarizes the OAM functions that are supported in each of the toolsets that were analyzed in this section. The columns of this tables are the typical OAM functions described in Section 1.3. +-----------+-------+--------+--------+-------+----------+ | |Continu|Connecti|Path |Perform|Other | | |ity |vity |Discover|ance |Function | | |Check |Verifica|y |Monitor|s | | Toolset | |tion | |ing | | +-----------+-------+--------+--------+-------+----------+ |IP Ping |Echo | | | | | + --------- + ----- + ------ + ------ + ----- + -------- + |IP | | |Tracerou| | | |Traceroute | | |te | | | + --------- + ----- + ------ + ------ + ----- + -------- + |BFD |BFD |BFD | | |RDI usi- | | |Control|Control | | |ng BFD | | |/ Echo | | | |Control | + --------- + ----- + ------ + ------ + ----- + -------- + |MPLS OAM | |"Ping" |"Tracero| | | |(LSP Ping) | |mode |ute" | | | | | | |mode | | | + --------- + ----- + ------ + ------ + ----- + -------- + |MPLS-TP |CC |CV/pro- |Route |-LM |-Diagnos- | |OAM | |active |Tracing |-DM | tic Test | | | |or on- | | |-Lock | | | |demand | | |-Alarm | | | | | | |Reporting | | | | | | |-Client | | | | | | |Failure | | | | | | |Indication| | | | | | |-RDI | + --------- + ----- + ------ + ------ + ----- + -------- + |Pseudowire |BFD |-BFD |LSP-Ping| | | |OAM | |-ICMP | | | | Mizrahi, et al. Expires July 9, 2014 [Page 33] Internet-Draft Overview of OAM Tools January 2014 | | | Ping | | | | | | |-LSP- | | | | | | | Ping | | | | + --------- + ----- + ------ + ------ + ----- + -------- + |OWAMP and | - control | |-Delay | | |TWAMP | protocol | | measur| | | | | | ement | | | | | |-Packet| | | | | | loss | | | | | | measur| | | | | | ement | | + --------- + ----- + ------ + ------ + ----- + -------- + |TRILL OAM |CC |CV |Path |-Delay | | | | | |tracing | measur| | | | | | | ement | | | | | | |-Packet| | | | | | | loss | | | | | | | measur| | | | | | | ement | | +-----------+-------+--------+--------+-------+----------+ Table 4 Summary of the OAM Functionality in IETF OAM Tools 5.3. Guidance to Network Equipment Vendors As mentioned in Section 1.4. , it is imperative for OAM tools to be capable of testing the actual data plane in as much accuracy as possible. While this guideline may appear obvious, it is worthwhile to emphasize the key importance of enforcing fate-sharing between OAM traffic that monitors the data plane and the data plane traffic it monitors. 6. Security Considerations This memo presents an overview of existing OAM tools, and proposes no new OAM tools. Therefore, this document introduces no security considerations. However, the OAM tools reviewed in this document can and do present security issues. The reader is encouraged to review the Security Considerations section of each document referenced by this memo. 7. IANA Considerations There are no new IANA considerations implied by this document. Mizrahi, et al. Expires July 9, 2014 [Page 34] Internet-Draft Overview of OAM Tools January 2014 8. Acknowledgments The authors gratefully acknowledge Sasha Vainshtein, Carlos Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other members of the OPSAWG mailing list for their helpful comments. This document was prepared using 2-Word-v2.0.template.dot. 9. References 9.1. Informative References [ATM-L2] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May 2006. [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [BFD-Gen] Katz, D., Ward, D., "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010. [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [Comp] Bonaventure, O., "Computer Networking: Principles, Protocols and Practice", 2008. [Dup] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009. Mizrahi, et al. Expires July 9, 2014 [Page 35] Internet-Draft Overview of OAM Tools January 2014 [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic Associated Channel", RFC 5586, June 2009. [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers, JR., "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010. [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007. [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [IEEE802.1Q] IEEE 802.1Q, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", October 2012. [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology - Local and metropolitan area networks - Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", clause 57, December 2008. [IntHost] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989. [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [IPPM-2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. Mizrahi, et al. Expires July 9, 2014 [Page 36] Internet-Draft Overview of OAM Tools January 2014 [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework for IP Performance Metrics", RFC 2330, May 1998. [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)", November 2012. [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS", November 2012. [ITU-T-CT] Betts, M., "Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)", RFC 6671, November 2012. [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January 2009. [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance mechanism for MPLS networks", February 2004. [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and Mechanisms for Ethernet-based Networks", July 2011. [ITU-Terms] ITU-R/ITU-T Terms and Definitions, online, 2013. [L2TP-EC] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values", RFC 5641, August 2009. [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., Dai, X., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011. [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [Mng] Farrel, A., "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, February 2011. Mizrahi, et al. Expires July 9, 2014 [Page 37] Internet-Draft Overview of OAM Tools January 2014 [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., Matsushima, S., "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006. [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T., "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006. [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for OAM in MPLS Transport Networks", RFC 5860, May 2010. [NetTerms] Jacobsen, O., Lynch, D., "A Glossary of Networking Terms", RFC 1208, March 1991. [NetTools] Enger, R., Reynolds, J., "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", RFC 1470, June 1993. [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool Set for MPLS based Transport Networks", RFC 6669, July 2012. [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, D., Mansfield, S., "Guidelines for the use of the OAM acronym in the IETF ", RFC 6291, June 2011. [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002. Mizrahi, et al. Expires July 9, 2014 [Page 38] Internet-Draft Overview of OAM Tools January 2014 [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011. [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and Zekauskas, M., "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, "Measuring Load-balanced Paths in the Internet", IMC, 2007. [PM-CONS] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011. [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [PW-G-ACh] Li, H., Martini, L., He, J., Huang, F., "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, November 2011. [PW-MAP] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011. [Reorder] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006. [Signal] Yasukawa, S., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006. [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and TCP/IP Tools and Utilities", RFC 2151, June 1997. [TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile", RFC 6428, November 2011. Mizrahi, et al. Expires July 9, 2014 [Page 39] Internet-Draft Overview of OAM Tools January 2014 [TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011. [TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011. [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration and Maintenance Framework for MPLS-based Transport Networks ", RFC 6371, September 2011. [TP-Term] Van Helvoort, H., Andersson, L., Sprecher, N., "A Thesaurus for the Terminology used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations", RFC 7087, December 2013. [TRILL-OAM] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve, R., "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, March 2013. [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and Babiarz, J., "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008. [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [VCCV-SURVEY] Del Regno, N., Malis, A., "The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", RFC 7079, November 2013. Appendix A. List of OAM Documents A.1. List of IETF OAM Documents Table 5 summarizes the OAM related RFCs published by the IETF. It is important to note that the table lists various RFCs that are different by nature. For example, some of these documents define OAM tools or OAM protocols (or both), while others define protocols that Mizrahi, et al. Expires July 9, 2014 [Page 40] Internet-Draft Overview of OAM Tools January 2014 are not strictly OAM-related, but are used by OAM tools. The table also includes RFCs that define the requirements or the framework of OAM in a specific context (e.g., MPLS-TP). The RFCs in the table are categorized in a few sets as defined in Section 1.3. +-----------+--------------------------------------+----------+ | Toolset | Title | RFC | +-----------+--------------------------------------+----------+ |IP Ping | Requirements for Internet Hosts -- | RFC 1122 | | | Communication Layers [IntHost] | | | +--------------------------------------+----------+ | | A Glossary of Networking Terms | RFC 1208 | | | [NetTerms] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 792 | | | [ICMPv4] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | Version 6 (IPv6) Specification | | | | [ICMPv6] | | +-----------+--------------------------------------+----------+ |IP | A Primer On Internet and TCP/IP | RFC 2151 | |Traceroute | Tools and Utilities [TCPIP-Tools] | | | +--------------------------------------+----------+ | | FYI on a Network Management Tool | RFC 1470 | | | Catalog: Tools for Monitoring and | | | | Debugging TCP/IP Internets and | | | | Interconnected Devices [NetTools] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 792 | | | [ICMPv4] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | Version 6 (IPv6) Specification | | | | [ICMPv6] | | | +--------------------------------------+----------+ | | Extended ICMP to Support Multi-Part | RFC 4884 | | | Messages [ICMP-MP] | | Mizrahi, et al. Expires July 9, 2014 [Page 41] Internet-Draft Overview of OAM Tools January 2014 | +--------------------------------------+----------+ | | Extending ICMP for Interface and | RFC 5837 | | | Next-Hop Identification [ICMP-Int] | | +-----------+--------------------------------------+----------+ |BFD | Bidirectional Forwarding Detection | RFC 5880 | | | [BFD] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5881 | | | (BFD) for IPv4 and IPv6 (Single Hop) | | | | [BFD-IP] | | | +--------------------------------------+----------+ | | Generic Application of Bidirectional | RFC 5882 | | | Forwarding Detection [BFD-Gen] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5883 | | | (BFD) for Multihop Paths [BFD-Multi] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5884 | | | for MPLS Label Switched Paths (LSPs) | | | | [BFD-LSP] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | Connectivity Verification (VCCV) | | | | [BFD-VCCV] | | +-----------+--------------------------------------+----------+ |MPLS OAM | Operations and Management (OAM) | RFC 4377 | | | Requirements for Multi-Protocol Label| | | | Switched (MPLS) Networks [MPLS-OAM] | | | +--------------------------------------+----------+ | | A Framework for Multi-Protocol | RFC 4378 | | | Label Switching (MPLS) Operations | | | | and Management (OAM) [MPLS-OAM-FW] | | | +--------------------------------------+----------+ | | Detecting Multi-Protocol Label | RFC 4379 | | | Switched (MPLS) Data Plane Failures | | | | [LSP-Ping] | | | +--------------------------------------+----------+ | | Operations and Management (OAM) | RFC 4687 | | | Requirements for Point-to-Multipoint | | | | MPLS Networks [MPLS-P2MP] | | Mizrahi, et al. Expires July 9, 2014 [Page 42] Internet-Draft Overview of OAM Tools January 2014 | +--------------------------------------+----------+ | | ICMP Extensions for Multiprotocol | RFC 4950 | | | Label Switching [ICMP-Ext] | | +-----------+--------------------------------------+----------+ |MPLS-TP | Requirements for OAM in MPLS-TP | RFC 5860 | |OAM | [MPLS-TP-OAM] | | | +--------------------------------------+----------+ | | MPLS Generic Associated Channel | RFC 5586 | | | [G-ACh] | | | +--------------------------------------+----------+ | | MPLS-TP OAM Framework | RFC 6371 | | | [TP-OAM-FW] | | | +--------------------------------------+----------+ | | Proactive Connectivity Verification, | RFC 6428 | | | Continuity Check, and Remote Defect | | | | Indication for the MPLS Transport | | | | Profile [TP-CC-CV] | | | +--------------------------------------+----------+ | | MPLS On-Demand Connectivity | RFC 6426 | | | Verification and Route Tracing | | | | [OnDemand-CV] | | | +--------------------------------------+----------+ | | MPLS Fault Management Operations, | RFC 6427 | | | Administration, and Maintenance (OAM)| | | | [TP-Fault] | | | +--------------------------------------+----------+ | | MPLS Transport Profile Lock Instruct | RFC 6435 | | | and Loopback Functions [Lock-Loop] | | | +--------------------------------------+----------+ | | Packet Loss and Delay Measurement for| RFC 6374 | | | MPLS Networks [MPLS-LM-DM] | | | +--------------------------------------+----------+ | | A Packet Loss and Delay Measurement | RFC 6375 | | | Profile for MPLS-Based Transport | | | | Networks [TP-LM-DM] | | +-----------+--------------------------------------+----------+ |Pseudowire | Pseudowire Virtual Circuit | RFC 5085 | |OAM | Connectivity Verification (VCCV): | | | | A Control Channel for Pseudowires | | | | [VCCV] | | | +--------------------------------------+----------+ Mizrahi, et al. Expires July 9, 2014 [Page 43] Internet-Draft Overview of OAM Tools January 2014 | | Bidirectional Forwarding Detection | RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | Connectivity Verification (VCCV) | | | | [BFD-VCCV] | | | +--------------------------------------+----------+ | | Using the Generic Associated Channel | RFC 6423 | | | Label for Pseudowire in the MPLS | | | | Transport Profile (MPLS-TP) | | | | [PW-G-ACh] | | | +--------------------------------------+----------+ | | Pseudowire (PW) Operations, | RFC 6310 | | | Administration, and Maintenance (OAM)| | | | Message Mapping [PW-MAP] | | +-----------+--------------------------------------+----------+ |OWAMP and | A One-way Active Measurement Protocol| RFC 4656 | |TWAMP | [OWAMP] | | | +--------------------------------------+----------+ | | A Two-Way Active Measurement Protocol| RFC 5357 | | | [TWAMP] | | | +--------------------------------------+----------+ | | Framework for IP Performance Metrics | RFC 2330 | | | [IPPM-FW] | | | +--------------------------------------+----------+ | | IPPM Metrics for Measuring | RFC 2678 | | | Connectivity [IPPM-Con] | | | +--------------------------------------+----------+ | | A One-way Delay Metric for IPPM | RFC 2679 | | | [IPPM-1DM] | | | +--------------------------------------+----------+ | | A One-way Packet Loss Metric for IPPM| RFC 2680 | | | [IPPM-1LM] | | | +--------------------------------------+----------+ | | A Round-trip Delay Metric for IPPM | RFC 2681 | | | [IPPM-2DM] | | | +--------------------------------------+----------+ | | Packet Reordering Metrics | RFC 4737 | | | [Reorder] | | | +--------------------------------------+----------+ | | A One-Way Packet Duplication Metric | RFC 5560 | | | [Dup] | | +-----------+--------------------------------------+----------+ Mizrahi, et al. Expires July 9, 2014 [Page 44] Internet-Draft Overview of OAM Tools January 2014 |TRILL OAM | Requirements for Operations, | RFC 6905 | | | Administration, and Maintenance (OAM)| | | | in Transparent Interconnection of | | | | Lots of Links (TRILL) | | +-----------+--------------------------------------+----------+ Table 5 Summary of IETF OAM Related RFCs A.2. List of Selected Non-IETF OAM Documents In addition to the OAM tools defined by the IETF, the IEEE and ITU-T have also defined various OAM tools that focus on Ethernet, and various other transport network environments. These various tools, defined by the three standard organizations, are often tightly coupled, and have had a mutual effect on each other. The ITU-T and IETF have both defined OAM tools for MPLS LSPs, [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to some extent linked to IETF OAM tools listed above and are mentioned here only as reference material: o OAM tools for Layer 2 have been defined by the ITU-T in [ITU-T-Y1731], and by the IEEE in 802.1ag [IEEE802.1Q] . The IEEE 802.3 standard defines OAM for one-hop Ethernet links [IEEE802.3ah]. o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. It should be noted that these non-IETF documents deal in many cases with OAM functions below the IP layer (Layer 2, Layer 2.5) and in some cases operators use a multi-layered OAM approach, which is a function of the way their networks are designed. Table 6 summarizes some of the main OAM standards published by non- IETF standard organizations. This document focuses on IETF OAM standards, but these non-IETF standards are referenced in this document where relevant. +-----------+--------------------------------------+---------------+ | | Title |Standard/Draft | +-----------+--------------------------------------+---------------+ |ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 | |MPLS OAM | for MPLS networks [ITU-T-Y1711] | | | +--------------------------------------+---------------+ | | Assignment of the 'OAM Alert Label' | RFC 3429 | | | for Multiprotocol Label Switching | | Mizrahi, et al. Expires July 9, 2014 [Page 45] Internet-Draft Overview of OAM Tools January 2014 | | Architecture (MPLS) Operation and | | | | Maintenance (OAM) Functions | | | | [OAM-Label] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T Y.1711. | | +-----------+--------------------------------------+---------------+ |ITU-T | Operations, administration and |ITU-T G.8113.2 | |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | | | | networks using the tools defined for | | | | MPLS [ITU-G8113.2] | | | | | | | | Note: this document describes the | | | | OAM toolset defined by the IETF for | | | | MPLS-TP, whereas ITU-T G.8113.1 | | | | describes the OAM toolset defined | | | | by the ITU-T. | | | +--------------------------------------+---------------+ | | Operations, Administration and |ITU-T G.8113.1 | | | Maintenance mechanism for MPLS-TP in | | | | Packet Transport Network (PTN) | | | +--------------------------------------+---------------+ | | Allocation of a Generic Associated | RFC 6671 | | | Channel Type for ITU-T MPLS Transport| | | | Profile Operation, Maintenance, and | | | | Administration (MPLS-TP OAM) | | | | [ITU-T-CT] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T G.8113.1. | | +-----------+--------------------------------------+---------------+ |ITU-T | OAM Functions and Mechanisms for | ITU-T Y.1731 | |Ethernet | Ethernet-based Networks | | |OAM | [ITU-T-Y1731] | | +-----------+--------------------------------------+---------------+ Mizrahi, et al. Expires July 9, 2014 [Page 46] Internet-Draft Overview of OAM Tools January 2014 |IEEE | Connectivity Fault Management | IEEE 802.1ag | |CFM | [IEEE802.1Q] | | | | | | | | Note: CFM was originally published | | | | as IEEE 802.1ag, but is now | | | | incorporated in the 802.1Q standard.| | +-----------+--------------------------------------+---------------+ |IEEE | Management of Data Driven and Data | IEEE 802.1ag | |DDCFM | Dependent Connectivity Faults | | | | [IEEE802.1Q] | | | | | | | | Note: DDCFM was originally published| | | | as IEEE 802.1Qaw, but is now | | | | incorporated in the 802.1Q standard.| | +-----------+--------------------------------------+---------------+ |IEEE | Media Access Control Parameters, | IEEE 802.3ah | |802.3 | Physical Layers, and Management | | |link level | Parameters for Subscriber Access | | |OAM | Networks [IEEE802.3ah] | | | | | | | | Note: link level OAM was originally | | | | defined in IEEE 802.3ah, and is now | | | | incorporated in the 802.3 standard. | | +-----------+--------------------------------------+---------------+ Table 6 Non-IETF OAM Standards Mentioned in this Document Authors' Addresses Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com Nurit Sprecher NSN 3 Hanagar St. Neve Ne'eman B Mizrahi, et al. Expires July 9, 2014 [Page 47] Internet-Draft Overview of OAM Tools January 2014 Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com Elisa Bellagamba Ericsson 6 Farogatan St. Stockholm, 164 40 Sweden Phone: +46 761440785 Email: elisa.bellagamba@ericsson.com Yaacov Weingarten 34 Hagefen St. Karnei Shomron, 4485500 Israel Email: wyaacov@gmail.com Mizrahi, et al. Expires July 9, 2014 [Page 48] On Jul 8, 2013:5:43 PM, at 5:43 PM, Tal Mizrahi = wrote: > Hi, > =20 > We have updated draft-ietf-opsawg-oam-overview following the comments = we received in IETF last call. > http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-09 > =20 > This document went into IETF last call in January, and we received = comments from (in chronological order): Benoit Claise, Al Morton, Sam = Aldrin, Tom Nadeau, Carlos Pignataro, Elwyn Davies, Sasha Vainshtein, = Dan Romascanu, Thomas Narten, Joel Jaeggli. > We carefully considered each and every comment, and significantly = edited the document to address these comments. > After we revised the document some of our reviewers kindly agreed to = reiterate on the document in 1x1 sessions, allowing us to verify that we = addressed the major comments. > A brief summary of the changes in the document: > - We practically rewrote the introduction; we added a subsection about = the target audience, and add general background about OAM including some = historical background. > - The structure of the document went through a significant revision as = well; for example, we moved the list of OAM documents to an appendix, = and moved the terminology section closer to the beginning. > - We revised the terminology section: we added quite a few terms that = were used without definition, and we fixed some inaccurate existing = definitions. We also did some major editing throughout the document to = verify that the terminology is used consistently. > - We added content that was missing in previous version of the draft, = e.g., TRILL OAM. > =20 > We encourage the reviewers to go over the updated document and let us = know if there are any further comments. > Any further comments from the WG are welcome. > =20 > Thanks, > Tal. --Apple-Mail=_ECDDC72D-A55D-40B8-BA92-8852834B4501 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Apologies but I = just realized I hadn't reviewed this document post the Vancouver IETF = meeting when I was asked. My comments are included. I do not feel this document is ready to go forward as there are some = major omissions as noted below.

--Tom




I have reviewed this document. Comments inline start with = TOM:.  
General comments = are:

1) Psedowire OAM = message mapping and ethernet OAM are missing.

2) There is no = discussion about OAM for L2VPN or L3VPN explicitly here. It is important = to explain this applicability.

3) BFD for MPLS is not explained. It = is a very viable replacement for CV instead of LSP Ping.

--Tom




Operations and = Management Area Working Group             =      T. Mizrahi
Internet Draft =                     =                     =           Marvell
Intended status: = Informational                 =               N. Sprecher
Expires: July 2014             =                     =                   = NSN
          =                     =                     =          E. Bellagamba
                =                     =                     =         Ericsson
      =                     =                     =              Y. Weingarten

      =                     =                     =            January 9, 2014

      =                     =     An Overview of
      =     Operations, Administration, and Maintenance (OAM) = Tools
          =         =  draft-ietf-opsawg-oam-overview-12.txt


Abstract

   Operations, = Administration, and Maintenance (OAM) is a general term
   that refers to a toolset for fault detection = and isolation, and for
   performance measurement. = Over the years various OAM tools have been
  =  defined for various layers in the protocol stack.

   This = document summarizes some of the OAM tools defined in the IETF = in
   the context of IP unicast, MPLS, MPLS for the = transport profile
   (MPLS-TP), pseudowires, = and TRILL. This document focuses on tools for
   detecting and isolating failures in networks = and for performance
   monitoring. Control and = management aspects of OAM are outside the
   scope = of this document. Network repair functions such as Fast = Reroute
   (FRR) and protection = switching, which are often triggered by OAM
   protocols, are also out of the scope of this = document.

   The target audience of this document includes = network equipment
   vendors, network = operators and standard development organizations,
   and can be used as an index to some of the main = OAM tools defined in
   the IETF. This document = provides a brief description of each of the
   OAM tools in the IETF. At the end of the = document a list of the OAM
  =  toolsets and a list of the OAM functions are presented as a = summary.

Status of this Memo

   This Internet-Draft is = submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

  =  Internet-Drafts are working documents of the Internet = Engineering
   Task Force (IETF), its = areas, and its working groups.  Note that
   other groups may also distribute working = documents as Internet-
   Drafts.




Mizrahi, et al. =         Expires July 9, 2014       =            [Page 1]
Internet-Draft          Overview of = OAM Tools             January = 2014


   Internet-Drafts are draft = documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by = other documents at any
   time.  It is = inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in = progress."

   The list of current Internet-Drafts can be = accessed at
   http://www.ietf.org/ie= tf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories = can be accessed at
   http://www.ietf.org/shadow.html.

   This = Internet-Draft will expire on July 9, 2014.

Copyright = Notice

   Copyright (c) 2014 IETF Trust and the persons = identified as the
   document authors. All = rights reserved.

   This document is subject to BCP 78 and the IETF = Trust's Legal
   Provisions Relating to = IETF Documents
   (http://trustee.ietf.org/lice= nse-info) in effect = on the date of
   publication of this = document. Please review these documents
  =  carefully, as they describe your rights and restrictions with = respect
   to this document. Code = Components extracted from this document must
   include Simplified BSD License text as = described in Section 4.e of
   the = Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD = License.

Table of Contents

   1. Introduction = ................................................. 4
      1.1. Background = .............................................. 4
      1.2. Target = Audience.......................................... 5
      1.3. OAM-related Work in the IETF = ............................ 5
      = 1.4. Focusing on the Data Plane .............................. = 6
   2. Terminology = .................................................. 7
      2.1. Abbreviations = ........................................... 7
      2.2. Terminology used in OAM Standards = ....................... 9
      =    2.2.1. General Terms ...................................... = 9
         2.2.2. Operations, = Administration and Maintenance ......... 9
    =      2.2.3. Functions, Tools and Protocols = .................... 10
      =    2.2.4. Data Plane, Control Plane and Management Plane .... = 10
         2.2.5. The Players = ....................................... 11
    =      2.2.6. Proactive and On-demand Activation = ................ 12
        =  2.2.7. Connectivity Verification and Continuity Checks ... = 12
         2.2.8. Connection = Oriented vs. Connectionless Communication13
         2.2.9. Point-to-point vs. = Point-to-multipoint Services ... 14


Mizrahi, et al.         Expires July 9, = 2014                  [Page = 2]
Internet-Draft          Overview = of OAM Tools             January = 2014


        =  2.2.10. Failures ......................................... = 15
   3. OAM Functions = ............................................... 15
   4. OAM Tools in the IETF - a Detailed = Description .............. 16
      = 4.1. IP Ping ................................................ = 16
      4.2. IP Traceroute = .......................................... 17
      4.3. Bidirectional Forwarding Detection = (BFD) ............... 18
      =    4.3.1. Overview .......................................... = 18
         4.3.2. Terminology = ....................................... 18
    =      4.3.3. BFD Control = ....................................... 18
    =      4.3.4. BFD Echo = .......................................... 19
      4.4. MPLS OAM = ............................................... 19
      4.5. MPLS-TP OAM = ............................................ 20
         4.5.1. Overview = .......................................... 20
         4.5.2. Terminology = ....................................... 21
    =      4.5.3. Generic Associated Channel = ........................ 22
      =    4.5.4. MPLS-TP OAM Toolset ............................... = 23
            4.5.4.1. = Continuity Check and Connectivity Verification 23
            4.5.4.2. Route = Tracing ................................ 24
            4.5.4.3. Lock = Instruct ................................ 24
            4.5.4.4. Lock = Reporting ............................... 24
            4.5.4.5. Alarm = Reporting .............................. 24
            4.5.4.6. Remote = Defect Indication ..................... 24
    =         4.5.4.7. Client Failure Indication = .................... 25
      =       4.5.4.8. Performance Monitoring = ....................... 25
      =          4.5.4.8.1. Packet Loss Measurement = (LM) ............ 25
          =      4.5.4.8.2. Packet Delay Measurement (DM) ........... = 25
      4.6. Pseudowire OAM = ......................................... 26
         4.6.1. Pseudowire OAM = using Virtual Circuit Connectivity
      =    Verification (VCCV) ...................................... = 26
         4.6.2. Pseudowire OAM = using G-ACh ........................ 27
      =    4.6.3. Attachment Circuit - Pseudowire Mapping ........... = 27
      4.7. OWAMP and = TWAMP......................................... 27
         4.7.1. Overview = .......................................... 27
         4.7.2. Control and Test = Protocols ........................ 28
      =    4.7.3. OWAMP ............................................. = 29
         4.7.4. TWAMP = ............................................. 29
      4.8. TRILL = .................................................. 30
   5. Summary = ..................................................... 30
      5.1. Summary of OAM Tools = ................................... 31
      = 5.2. Summary of OAM Functions ............................... = 33
      5.3. Guidance to Network Equipment = Vendors .................. 34
   6. = Security Considerations ..................................... = 34
   7. IANA Considerations = ......................................... 34
   8. Acknowledgments = ............................................. 35
   9. References = .................................................. 35
      9.1. Informative References = ................................. 35
  =  Appendix A. List of OAM Documents .............................. = 40


Mizrahi, et al.       =   Expires July 9, 2014             =      [Page 3]
Internet-Draft =          Overview of OAM Tools     =         January 2014


      A.1. List of IETF OAM Documents = ............................. 40
      = A.2. List of Selected Non-IETF OAM Documents ................ = 45

1. = Introduction

   OAM is a general term that refers to a toolset = for detecting,
   isolating and reporting = failures and for monitoring the network
  =  performance.

   There are several different interpretations to = the "OAM" acronym.
   This document refers to = Operations, Administration and Maintenance,
   as recommended in Section 3 of = [OAM-Def].

   This document summarizes some of the OAM tools = defined in the IETF in
   the context of IP = unicast, MPLS, MPLS for the transport profile
   (MPLS-TP), pseudowires, and TRILL.

   This = document focuses on tools for detecting and isolating failures
   and for performance monitoring. Hence, this = document focuses on the
   tools = used for monitoring and measuring the data plane; control and
   management aspects of OAM are outside the scope = of this document.
   Network repair functions = such as Fast Reroute (FRR) and protection
  =  switching, which are often triggered by OAM protocols, are also = out
   of the scope of this = document.

1.1. Background

   OAM was originally used = in traditional communication technologies
   such as = E1 and T1, evolving into PDH and then later in SONET/SDH. ATM
   was probably the first technology to include = inherent OAM support
   from day one, while in = other technologies OAM was typically defined
   in an ad hoc manner after the technology was = already defined and
   deployed. Packet-based = networks were traditionally considered
  =  unreliable and best-effort, but as packet-based networks = evolved,
   they have become the = common transport for both data and telephony,
   replacing traditional transport protocols. = Consequently, packet-based
  =  networks were expected to provide a similar "carrier = grade"
   experience, and = specifically to support OAM.

   As typical networks have = a multi-layer architecture, the set of OAM
  =  protocols similarly take a multi-layer structure; each layer has = its
   own OAM protocols. = Moreover, OAM can be used at different levels of
   hierarchy in the network to form a multi-layer = OAM solution, as shown
   in the example in Figure = 1.

   Figure = 1 illustrates a network in which IP traffic between two
   customer edges is transported over an MPLS = provider network. MPLS OAM


Mizrahi, et al.         Expires July 9, = 2014                  [Page = 4]
Internet-Draft          Overview = of OAM Tools             January = 2014


   is used at the = provider-level for monitoring the connection between
   the two provider edges, while IP OAM is used at = the customer-level
   for monitoring the = end-to-end connection between the two customer
   edges.

          =  |<-------------- Customer-level OAM = -------------->|
          =        IP OAM (Ping, Traceroute, OWAMP, = TWAMP)

                =         |<- Provider-level OAM ->|
                =             MPLS OAM (LSP Ping)

    =  +-----+       +----+         =                +----+   =     +-----+
     |     | =       |    |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|    |       | =     |
     |     = |-------|    |          MPLS   =        |    |-------|     = |
     |     |  IP   | =    |                 =        |    |  IP   |   =   |
     +-----+   =     +----+               =          +----+       = +-----+
     Customer   =   Provider                 =      Provider      Customer
       Edge         = Edge                   =        Edge         =  Edge

                =      Figure 1 Example: Multi-layer OAM

1.2. Target = Audience

   The target audience of this document = includes:

   o Standard development organizations - both = IETF working groups and
      = non-IETF organizations can benefit from this document when
      designing new OAM protocols, or when = looking to reuse existing OAM
      = tools for new technologies.

   o Network equipment = vendors and network operators - can use this
      document as an index to some of the = common IETF OAM tools.

   It should be noted that this document is not = necessarily suitable for
  =  beginners without any background in OAM.

1.3. OAM-related = Work in the IETF

   This memo provides an overview of the different = sets of OAM tools
   defined by the IETF. The = set of OAM tools described in this memo are
   applicable to IP unicast, MPLS, pseudowires, = MPLS for the transport
   profile (MPLS-TP), and = TRILL. While OAM tools that are applicable to
   other technologies exist, they are beyond the = scope of this memo.




Mizrahi, et al.         Expires July 9, = 2014                  [Page = 5]
Internet-Draft          Overview = of OAM Tools             January = 2014


   This document focuses on = IETF documents that have been published as
   RFCs, = while other ongoing OAM-related work is outside the scope.

   The = IETF has defined OAM protocols and tools in several different
   contexts. We roughly categorize these efforts = into a few sets of OAM-
   related = RFCs, listed in Table 1. Each set defines a logically-coupled
   set of RFCs, although the sets are in some = cases intertwined by
   common tools and = protocols.

   The discussion in this document is ordered = according to these sets.

                =      +--------------+------------+
                =      | Toolset      | Transport =  |
          =            |         =      | Technology |
      =               =  +--------------+------------+
      =                |IP Ping   =     | IPv4/IPv6  |
      =               =  +--------------+------------+
      =                |IP Traceroute | = IPv4/IPv6  |
          =           =  +--------------+------------+
      =                |BFD   =         | generic    |
                =      +--------------+------------+
                =      |MPLS OAM      | MPLS     =   |
          =           =  +--------------+------------+
      =                |MPLS-TP OAM =   | MPLS-TP    |
      =               =  +--------------+------------+
      =                |Pseudowire OAM| = Pseudowires|
          =           =  +--------------+------------+
      =                |OWAMP and   =   | IPv4/IPv6  |
      =                |TWAMP   =       |           =  |
          =           =  +--------------+------------+
      =                |TRILL OAM   =   | TRILL      |
      =               =  +--------------+------------+
      =        Table 1 OAM Toolset Packages in the IETF = Documents

   This document focuses on OAM tools that have = been developed in the
   IETF. A short summary of = some of the significant OAM standards that
   have = been developed in other standard organizations is presented in
   Appendix A.2.

1.4. Focusing on the Data = Plane

   OAM tools may, and quite often do, work in = conjunction with a control
   plane = and/or management plane.  OAM provides instrumentation = tools
   for measuring and = monitoring the data plane. OAM tools often use


Mizrahi, et al.       =   Expires July 9, 2014             =      [Page 6]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   control plane functions, e.g., to initialize = OAM sessions and to
   exchange various = parameters. The OAM tools communicate with the
   management plane to raise alarms, and often OAM = tools may be
   activated by the = management (as well as by the control plane), e.g.
   to locate and localize problems.

   The = considerations of the control plane maintenance tools and the
   functionality of the management plane are out = of scope for this
   document, which = concentrates on presenting the data plane tools that
   are used for OAM. Network repair functions such = as Fast Reroute (FRR)
   and protection switching, = which are often triggered by OAM protocols,
   are also out of the scope of this = document.

   Since OAM protocols are used for monitoring the = data plane, it is
   imperative for OAM tools = to be capable of testing the actual data
   plane = in as much accuracy as possible. Thus, it is important to
   enforce fate-sharing between OAM traffic that = monitors the data plane
   and the = data plane traffic it monitors.

2. Terminology

2.1. = Abbreviations

   ACH    Associated Channel = Header

   AIS    Alarm Indication = Signal

   ATM    Asynchronous Transfer = Mode

   BFD =    Bidirectional Forwarding Detection

   CC =     Continuity Check

   CV     = Connectivity Verification

   DM     Delay = Measurement

   ECMP   Equal Cost Multiple Paths

   FEC =    Forwarding Equivalence Class

   FRR    Fast = Reroute

   G-ACh   Generic Associated = Channel

   GAL    Generic Associated = Label



Mizrahi, et al.       =   Expires July 9, 2014             =      [Page 7]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   ICMP   Internet Control Message = Protocol

   L2TP   Layer Two Tunneling = Protocol

   LCCE   L2TP Control Connection = Endpoint

   LDP    Label Distribution = Protocol

   LER    Label Edge Router

   LM =     Loss Measurement

   LSP    Label = Switched Path

   LSR    Label Switched = Router

   ME     Maintenance Entity

   MEG =    Maintenance Entity Group

   MEP    MEG End = Point

   MIP    MEG Intermediate = Point

   MP     Maintenance Point

   MPLS =   Multiprotocol Label Switching

   MPLS-TP MPLS Transport = Profile

   MTU    Maximum Transmission = Unit

   OAM =    Operations, Administration, and Maintenance

   OWAMP =   One-way Active Measurement Protocol

   PDH   =  Plesiochronous Digital Hierarchy

   PE     Provider = Edge

   PW =     Pseudowire

   PWE3   Pseudowire Emulation = Edge-to-Edge

   RBridge Routing Bridge

   RDI =    Remote Defect Indication


Mizrahi, et al.         Expires July 9, = 2014                  [Page = 8]
Internet-Draft          Overview = of OAM Tools             January = 2014


   SDH   =  Synchronous Digital Hierarchy

   SONET   Synchronous = Optical Networking

   TRILL   Transparent Interconnection of = Lots of Links

   TTL    Time To Live

   TWAMP =   Two-way Active Measurement Protocol

   VCCV   Virtual = Circuit Connectivity Verification

2.2. Terminology used in OAM = Standards

2.2.1. General Terms

   A wide variety of terms = is used in various OAM standards. This
   section = presents a comparison of the terms used in various OAM
   standards, without fully quoting the definition = of each term.

   An interesting overview of the term OAM and its = derivatives is
   presented in [OAM-Def]. A = thesaurus of terminology for MPLS-TP terms
   is = presented in [TP-Term], and provides a good summary of some of = the
   OAM related = terminology.

2.2.2. Operations, Administration and Maintenance

   The = following definition of OAM is quoted from [OAM-Def]:

   The = components of the "OAM" acronym (and provisioning) are defined = as
   follows:

   o Operations - Operation = activities are undertaken to keep the
      = network (and the services that the network provides) up and
      running.  It includes monitoring = the network and finding problems.
      = Ideally these problems should be found before users are = affected.

   o Administration - Administration activities = involve keeping track
      of resources in = the network and how they are used.  It includes
      all the bookkeeping that is necessary = to track networking
      resources and the = network under control.








Mizrahi, et al. =         Expires July 9, 2014       =            [Page 9]
Internet-Draft          Overview of = OAM Tools             January = 2014


   o Maintenance - = Maintenance activities are focused on facilitating
      repairs and upgrades -- for example, = when equipment must be
      replaced, when a = router needs a patch for an operating system
      image, or when a new switch is added to = a network.  Maintenance
      = also involves corrective and preventive measures to make the
      managed network run more effectively, = e.g., adjusting device
      configuration and = parameters.

2.2.3. Functions, Tools and Protocols

OAM = Function



   An OAM function is an = instrumentation measurement type or diagnostic.

   OAM = functions are the atomic building blocks of OAM, where each
   function defines an OAM capability.

   Typical = examples of OAM functions are presented in Section 3.

OAM = Protocol

   A protocol used for implementing one or more = OAM functions.

   The OWAMP-Test [OWAMP] is an example of an OAM = protocol.

OAM Tool

   An OAM tool is a specific means of applying one = or more OAM
   functions.

   In some = cases an OAM protocol *is* an OAM tool, e.g., OWAMP-Test. In
   other cases an OAM tool uses a set of protocols = that are not strictly
   OAM-related; for example, = Traceroute (Section 4.2.) can be
  =  implemented using UDP and ICMP messages, without using an = OAM
   protocol per = se.

2.2.4. Data Plane, = Control Plane and Management Plane

Data Plane

   The = data plane is the set of functions used to transfer data in = the
   stratum or layer under = consideration [ITU-Terms].

   The Data Plane is also = known as the Forwarding Plane or the User
  =  Plane.


Mizrahi, et al. =         Expires July 9, 2014       =           [Page 10]
Internet-Draft          Overview of = OAM Tools             January = 2014


Control Plane

   The = control plane is the set of protocols and mechanisms that = enable
   routers to efficiently = learn how to forward packets towards their
   final = destination (based on [Comp]).

Management Plane

   The = term Management Plane, as described in [Mng], is used to = describe
   the exchange of = management messages through management protocols
   (often transported by IP and by IP transport = protocols) between
   management applications = and the managed entities such as network
  =  nodes.

Data Plane vs. Control Plane vs. Management Plane

   The = distinction between the planes is at times a bit vague. For
   example, the definition of "Control Plane" = above may imply that OAM
   tools = such as ping, BFD and others are in fact in the control plane.

   This = document focuses on tools used for monitoring the data plane.
   While these tools could arguably be considered = to be in the control
   plane, these tools = monitor the data plane, and hence it is imperative
   to have fate-sharing between OAM traffic that = monitors the data plane
   and the = data plane traffic it monitors.

   Another potentially vague = distinction is between the management plane
   and control plane. The management plane should = be seen as separate
   from, but possibly = overlapping with, the control plane (based on
   [Mng]).

2.2.5. The Players

   An OAM = tool is used between two (or more) "players". Various terms
   are used in IETF documents to refer to the = players that take part in
   OAM. = Table 2 summarizes the terms used in each of the toolsets
   discussed in this document.

      =     = +--------------------------+--------------------------+
          | Toolset     =              | Terms     =                |
          = +--------------------------+--------------------------+
          | Ping / Traceroute =        |-Host           =           |
      =     | ([ICMPv4], [ICMPv6],     |-Node     =                 |
          |  [TCPIP-Tools]) =          |-Interface       =          |
      =     |                 =          |-Gateway         =          |



Mizrahi, et al. =         Expires July 9, 2014       =           [Page 11]
Internet-Draft          Overview of = OAM Tools             January = 2014


          + = ------------------------ + ------------------------ +
          | BFD [BFD]     =            | System       =             |
          + = ------------------------ + ------------------------ +
          | MPLS OAM [MPLS-OAM-FW] =   | LSR                 =      |
          + = ------------------------ + ------------------------ +
          | MPLS-TP OAM [TP-OAM-FW] =  |-End Point - MEP          |
          |       =                   =  |-Intermediate Point - MIP |
      =     + ------------------------ + ------------------------ = +
          | Pseudowire OAM [VCCV] =    |-PE               =         |
      =     |                 =          |-LCCE         =             |
          + = ------------------------ + ------------------------ +
          | OWAMP and TWAMP   =        |-Host           =           |
      =     | ([OWAMP], [TWAMP])       |-End system =               |
          + = ------------------------ + ------------------------ +
          | TRILL OAM [TRILL-OAM] =    |-RBridge               =    |
          = +--------------------------+--------------------------+
                =    Table 2 Maintenance Point Terminology



2.2.6. Proactive and On-demand Activation

   The = different OAM tools may be used in one of two basic types of
   activation:

Proactive

  =  Proactive activation - indicates that the tool is activated on = a
   continual basis, where messages are sent = periodically, and errors are
  =  detected when a certain number of expected messages are not = received.

On-demand

   On-demand activation - indicates that the tool = is activated
   "manually" to detect a = specific anomaly.

2.2.7. 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.

Continuity Check



Mizrahi, et al.         Expires July 9, = 2014                 [Page = 12]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


  =  Continuity checks are used to verify that a destination is = reachable,
   and are typically sent = proactively, though they can be invoked on-
   demand as well.

Connectivity Verification

   A = connectivity verification function allows Alice to check = whether
   she is connected to Bob = or not. It is noted that while the CV
  =  function is performed in the data plane, the "expected path" = is
   predetermined either in the control plane or = in the management plane.
   A = connectivity verification (CV) protocol typically uses a CV
   message, followed by a CV reply that is sent = back to the originator.
   A CV = function can be applied proactively or on-demand.

  =  Connectivity Verification tools often perform path verification = as
   well, allowing Alice to verify that messages = from Bob are received
   through the correct path, = thereby verifying not only that the two MPs
   are connected, but also that they are connected = through the expected
   path, allowing detection = of unexpected topology changes.

   Connectivity verification = and continuity checks are considered
  =  complementary mechanisms, and are often used in conjunction with = each
   other.

2.2.8. Connection = Oriented vs. Connectionless Communication

Connection Oriented

   In = Connection Oriented technologies an end-to-end connection is
   established (by a control protocol or = provisioned by a management
   system) = prior to the transmission of data.

   Typically a connection = identifier is used to identify the connection.
   In connection oriented technologies it is often = the case (although
   not always) that all = packets belonging to a specific connection use
   the same route through the network.

Connectionless

   In Connectionless = technologies data is typically sent between end
   points without prior arrangement. Packets are = routed independently
   based on their = destination address, and hence different packets may
   be routed in a different way across the = network.

Discussion




Mizrahi, et al.         Expires July 9, = 2014                 [Page = 13]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


   The OAM = tools described in this document include tools that support
   connection oriented technologies, as well as = tools for connectionless
  =  technologies.

   In connection oriented technologies OAM is used = to monitor a
   *specific* connection; = OAM packets are forwarded through the same
   route = as the data traffic and receive the same treatment. In
   connectionless technologies, OAM is used = between a source and
   destination pair without = defining a specific connection. Moreover, in
   some cases the route of OAM packets may differ = from the one of the
   data traffic. For = example, the connectionless IP Ping (Section 4.1.)
   tests the reachability from a source to a given = destination, while
   the connection oriented = LSP Ping (Section 4.4.) is used for
  =  monitoring a specific LSP (connection), and provides the = capability
   to monitor all the = available paths used by an LSP.

   It should be noted that = in some cases connectionless protocols are
  =  monitored by connection oriented OAM protocols. For example, while = IP
   is a connectionless protocol, it can monitored = by BFD (Section 4.3.
   ), which is connection = oriented.

2.2.9. Point-to-point vs. Point-to-multipoint = Services

Point-to-point (P2P)

   A P2P service delivers = data from a single source to a single
  =  destination.

Point-to-multipoint (P2MP)

   A P2MP service delivers = data from a single source to a one or more
  =  destinations (based on [Signal]).

   An MP2MP service is a = service that delivers data from more than one
   source to one or more receivers (based on = [Signal]).

   Note: the two definitions for P2MP and MP2MP = are quoted from
   [Signal]. Although = [Signal] describes a specific case of P2MP and
   MP2MP which is MPLS-specific, these two = definitions also apply to
  =  non-MPLS cases.

Discussion

   The OAM tools described in this document = include tools for P2P
   services, as well as = tools for P2MP services.




Mizrahi, et al.         Expires July 9, = 2014                 [Page = 14]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


   The = distinction between P2P services and P2MP services affects the
   corresponding OAM tools. A P2P service is = typically simpler to
   monitor, as it consists = of a single pair of end points. P2MP services
   present several challenges. For example, in a = P2MP service, the OAM
   mechanism not only = verifies that each of the destinations is
  =  reachable from the source, but also verifies that the = P2MP
   distribution tree is = intact and loop-free.

2.2.10. Failures

   The terms Failure, Fault, = and Defect are used interchangeably in the
  =  standards, referring to a malfunction that can be detected by = a
   connectivity or a continuity check. In some = standards, such as
   802.1ag [IEEE802.1Q] , = there is no distinction between these terms,
   while in other standards each of these terms = refers to a different
   type of = malfunction.

   The terminology used in IETF MPLS-TP OAM is = based on the ITU-T
   terminology, which = distinguishes between these three terms in
  =  [ITU-T-G.806];

Fault

   The term Fault refers to an inability to = perform a required action,
   e.g., = an unsuccessful attempt to deliver a packet.

Defect

   The = term Defect refers to an interruption in the normal operation,
   such as a consecutive period of time where no = packets are delivered
   successfully.

Failure

   The = term Failure refers to the termination of the required = function.
   While a Defect typically = refers to a limited period of time, a
   failure = refers to a long period of time.

3. OAM Functions

   This = subsection provides a brief summary of the common OAM = functions
   used in OAM-related = standards. These functions are used as building
   blocks in the OAM standards described in this = document.

   o Connectivity Verification (CV), Path = Verification and Continuity
      = Checks (CC):
      As defined in = Section 2.2.7.


Mizrahi, et al. =         Expires July 9, 2014       =           [Page 15]
Internet-Draft          Overview of = OAM Tools             January = 2014


   o Path Discovery / Fault = Localization:
      This function can = be used to trace the route to a destination,
      i.e., to identify the nodes along the = route to the destination.
      = When more than one route is available to a specific = destination,
      this function = traces one of the available routes. When a failure
      occurs, this function also allows to = detect the location of the
      = failure.
      Note that the = term route tracing (or Traceroute) that is used in
      the context of IP and MPLS, is = sometimes referred to as path
      = tracing in the context of other protocols, such as TRILL.

   o = Performance Monitoring:
      = Typically refers to:

        o Loss Measurement (LM) - = monitors the packet loss rate.

        o Delay = Measurement (DM) - monitors the delay and delay
          variation.

4. OAM Tools in the = IETF - a Detailed Description

   This section presents a = detailed description of the sets of OAM-
   related = tools in each of the toolsets in Table 1.

4.1. IP Ping

   Ping is = a common network diagnosis application for IP networks that
   uses ICMP. According to [NetTerms], 'Ping' is = an abbreviation for
   Packet internet groper, = although the term has been so commonly used
   that it stands on its own.  As defined in = [NetTerms], it is a program
   used to = test reachability of destinations by sending them an ICMP
   echo request and waiting for a reply.

   The = ICMP Echo request/reply exchange in Ping is used as a = continuity
   check function for the = Internet Protocol. The originator transmits an
   ICMP Echo request packet, and the receiver = replies with an Echo
   reply. ICMP ping is = defined in two variants, [ICMPv4] is used for
   IPv4, and [ICMPv6] is used for IPv6.

   Ping = implementations typically use ICMP messages. UDP Ping is a
   variant that uses UDP messages instead of ICMP = echo messages.

   Ping is a single-ended continuity check, i.e., = it allows the
   *initiator* of the Echo = request to test the reachability. If it is
  =  desirable for both ends to test the reachability, both ends have = to
   invoke Ping independently.



Mizrahi, et al.         Expires July 9, = 2014                 [Page = 16]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


   Note = that since ICMP filtering is deployed in some routers and
   firewalls, the usefulness of Ping is sometimes = limited in the wider
   internet. This limitation = is equally relevant to Traceroute.

4.2. IP Traceroute

  =  Traceroute ([TCPIP-Tools], [NetTools]) is an application that = allows
   users to discover a path = between an IP source and an IP destination.

   The = most common way to implement Traceroute [TCPIP-Tools] is
   described as follows. Traceroute sends a = sequence of UDP packets to
   UDP = port 33434 at the destination. By default, Traceroute begins = by
   sending three packets (the number of packets = is configurable in most
  =  Traceroute implementations), each with an IP Time-To-Live (or = Hop
   Limit in IPv6) value of = one to the destination. These packets expire
   as soon as they reach the first router in the = path. Consequently,
   that router sends three = ICMP Time Exceeded Messages back to the
  =  Traceroute application. Traceroute now sends another three = UDP
   packets, each with the = TTL value of 2. These messages cause the
   second = router to return ICMP messages. This process continues, with
   ever increasing values for the TTL field, until = the packets actually
   reach the destination. = Because no application listens to port 33434
   at the destination, the destination returns = ICMP Destination
   Unreachable Messages = indicating an unreachable port. This event
  =  indicates to the Traceroute application that it is finished. =  The
   Traceroute program = displays the round-trip delay associated with each
   of the attempts.

   While Traceroute is a = tool that finds *a* path from A to B, it should
   be noted that traffic from A to B is often = forwarded through Equal
   Cost = Multiple Paths (ECMP). Paris Traceroute [PARIS] is an = extension
   to Traceroute that = attempts to discovers all the available paths from
   A to B by scanning different values of header = fields (such as UDP
   ports) in the probe = packets.

   It is noted that Traceroute is an application, = and not a protocol. As
   such, it has various = different implementations. One of the most
   common = ones uses UDP probe packets, as described above. Other
   implementations exist that use other types of = probe messages, such as
   ICMP or = TCP.

   Note = that IP routing may be asymmetric. While Traceroute discovers = a
   path between a source and destination, it does = not reveal the reverse
   path.

   A few = ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in
   the context of Traceroute. These documents = define several extensions,


Mizrahi, et al.         Expires July 9, = 2014                 [Page = 17]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


  =  including extensions to the ICMP Destination Unreachable = message,
   that can be used by = Traceroute applications.

4.3. Bidirectional Forwarding Detection (BFD)

4.3.1. = Overview

   While multiple OAM tools have been defined for = various protocols in
   the protocol stack, = Bidirectional Forwarding Detection [BFD], defined
   by the IETF BFD working group, is a generic OAM = tool that can be
   deployed over various = encapsulating protocols, and in various medium
   types. The IETF has defined variants of the = protocol for IP ([BFD-
   IP], [BFD-Multi]), for = MPLS LSPs [BFD-LSP], and for pseudowires [BFD-
   VCCV]. The usage of BFD in MPLS-TP is defined = in [TP-CC-CV].

   BFD includes two main OAM functions, using two = types of BFD packets:
   BFD Control packets, and = BFD Echo packets.

4.3.2. Terminology

   BFD operates between = *systems*. The BFD protocol is run between two
   or more systems after establishing a = *session*.

4.3.3. BFD Control

   BFD supports a = bidirectional continuity check, using BFD control
   packets, that are exchanged within a BFD = session. BFD sessions
   operate in one of two = modes:

   o Asynchronous mode (i.e. proactive): in this = mode BFD control
      packets are sent = periodically. When the receiver detects that no
      BFD control packets have been received = during a predetermined
      period of time, a = failure is detected.

   o Demand mode: in this mode, BFD control = packets are sent on-demand.
      = Upon need, a system initiates a series of BFD control packets = to
      check the continuity of the session. = BFD control packets are sent
      = independently in each direction.

   Each of the end-points = (referred to as systems) of the monitored path
   maintains its own session identification, = called a Discriminator,
   both of = which are included in the BFD Control Packets that are
   exchanged between the end-points.  At the = time of session
   establishment, the = Discriminators are exchanged between the two-end
   points.  In addition, the transmission = (and reception) rate is
  =  negotiated between the two end-points, based on information = included



Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 18]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   in the control packets.  These = transmission rates may be renegotiated
   during = the session.

   During normal operation of the session, i.e. no = failures are
   detected, the BFD session = is in the Up state.  If no BFD Control
   packets are received during a period of time = called the Detection
   Time, the session is = declared to be Down. The detection time is a
   function of the pre-configured or negotiated = transmission time, and a
  =  parameter called Detect Mult. Detect Mult determines the number = of
   missing BFD Control packets that cause the = session to be declared as
   Down. = This parameter is included in the BFD Control packet.

4.3.4. BFD = Echo

   A BFD = echo packet is sent to a peer system, and is looped back to = the
   originator. The echo = function can be used proactively, or on-demand.

   The BFD = echo function has been defined in BFD for IPv4 and IPv6
   ([BFD-IP]), but is not used in BFD for MPLS = LSPs, PWs, or in BFD for
  =  MPLS-TP.

4.4. MPLS OAM

   The IETF MPLS working = group has defined OAM for MPLS LSPs. The
  =  requirements and framework of this effort are defined in
   [MPLS-OAM-FW] and [MPLS-OAM], respectively. The = corresponding OAM
   tool defined, in this = context, is LSP Ping [LSP-Ping]. OAM for P2MP
   services is defined in [MPLS-P2MP].

   LSP = Ping is modeled after the Ping/Traceroute paradigm and thus it
   may be used in one of two modes:

   o = "Ping" mode: In this mode LSP Ping is used for end-to-end
      connectivity verification between two = LERs.

   o "Traceroute" mode: This mode is used for = hop-by-hop fault
      = isolation.

   LSP Ping extends the basic ICMP Ping operation = (of data-plane
   connectivity = verification) with functionality to verify data-plane
   vs. control-plane consistency for a Forwarding = Equivalence Class
   (FEC) and also Maximum = Transmission Unit (MTU) problems.

TOM: This is misleading. LSP Ping does = not extend any part of ICMP operation; its a completely new operation = that is native to MPLS.  It is important not to conflate these two things, as there are proprietary = versions of ICMP ping extended for MPLS that DO NOT work in all cases. = This is why LSP Ping was invented (and trace).

   The Traceroute = functionality may be used to isolate and localize the
   MPLS faults, using the Time-to-live (TTL) = indicator to incrementally
  =  identify the sub-path of the LSP that is successfully = traversed
   before the faulty link or = node.


TOM: There is more = to the LSP Traceroute than just using TTL. Please review the RFC for = details.

Mizrahi, et al.         Expires July 9, = 2014                 [Page = 19]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


   The = challenge in MPLS networks is that the traffic of a given LSP = may
   be load balanced across = Equal Cost Multiple paths (ECMP). LSP Ping
  =  monitors all the available paths of an LSP by monitoring = its
   different Forwarding = Equivalence Classes (FEC). Conversely, MPLS-TP
   does not use ECMP, and thus does not require = OAM over multiple paths.

TOM: Why "conversely"?  You imply that MPLS-TP is = "better" somehow with that statement; its different.  

   Another = challenge is that an MPLS LSP does not necessarily have a
   return path, and thus responding to an LSP Ping = message is not

TOM: Strictily speaking, an LSP does not have a return path. = There is a return route at the other end that is used to return the = response message. This can be a = different MPLS LSP, IP or whatever.

   necessarily as trivial as = in IP Ping, where the responder just swaps
   the = source and destination IP addresses. Note that this challenge = is
   not applicable to MPLS-TP, where a return path = is always available.

   It should be noted that LSP Ping supports = unique identification of
   the LSP = within an addressing domain. The identification is checked
   using the full FEC identification. LSP Ping is = easily extensible to
   include additional = information needed to support new functionality,
   by use of Type-Length-Value (TLV) constructs. = The usage of TLVs is
   typically not easy to = perform in hardware, and is thus typically
  =  handled by the control plane.

   LSP Ping supports both = asynchronous, as well as, on-demand
  =  activation.

4.5. MPLS-TP OAM

4.5.1. Overview

   The = MPLS working group has defined the OAM toolset that fulfills = the
   requirements for MPLS-TP = OAM. The full set of requirements for MPLS-
   TP OAM are defined in [MPLS-TP-OAM], and = include both general
   requirements for the = behavior of the OAM tools and a set of
  =  operations that should be supported by the OAM toolset.  The = set of
   mechanisms required are = further elaborated in [TP-OAM-FW], which
  =  describes the general architecture of the OAM system as well = as
   giving overviews of the functionality of the = OAM toolset.

   Some of the basic requirements for the OAM = toolset for MPLS-TP are:

   o MPLS-TP OAM must be able to support both an = IP based and non-IP
      based = environment. If the network is IP based, i.e. IP routing and
      forwarding are available, then the = MPLS-TP OAM toolset should rely
      = on the IP routing and forwarding capabilities. On the other = hand,
      in environments = where IP functionality is not available, the OAM
      tools must still be able to operate = without dependence on IP
      = forwarding and routing.




Mizrahi, et al.         Expires July 9, = 2014                 [Page = 20]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


   o OAM = packets and the user traffic are required to be congruent
      (i.e. OAM packets are transmitted = in-band) and there is a need to
      = differentiate OAM packets from data plane ones. Inherent in = this
      requirement is = the principle that MPLS-TP OAM be independent of
      any existing control-plane, although it = should not preclude use of
      = the control-plane functionality.
      = OAM packets are identified by the Generic Associated Label = (GAL),
      which is a = reserved MPLS label value (13).

4.5.2. Terminology

Maintenance Entity = (ME)

   The = MPLS-TP OAM tools are designed to monitor and manage a
   Maintenance Entity (ME).  An ME, as = defined in [TP-OAM-FW], defines a
  =  relationship between two points of a transport path to = which
   maintenance and = monitoring operations apply.

   The term Maintenance = Entity (ME) is used in ITU-T Recommendations
   (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP = terminology
   ([TP-OAM-FW]).

Maintenance Entity = Group (MEG)

   The collection of one or more MEs that belongs = to the same transport
   path and that are = maintained and monitored as a group are known as a
   Maintenance Entity Group (based on = [TP-OAM-FW]).

Maintenance Point (MP)

   A Maintenance Point (MP) = is a functional entity that is defined at a
   node in the network, and can initiate and/or = react to OAM messages.
   This document focuses on = the data-plane functionality of MPs, while
   MPs = interact with the control plane and with the management plane = as
   well.

   The term MP is used in = IEEE 802.1ag, and was similarly adopted in
  =  MPLS-TP ([TP-OAM-FW]).

Maintenance End Point (MEP)

   A = Maintenance End Point (MEP) is one of the end points of an ME, = and
   can initiate OAM messages = and respond to them (based on [TP-OAM-FW]).

Maintenance = Intermediate Point (MIP)




Mizrahi, et al.         Expires July 9, = 2014                 [Page = 21]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


   In = between MEPs, there are zero or more intermediate points, = called
   Maintenance Entity Group = Intermediate Points  (based on [TP-OAM-FW]).

   A = Maintenance Intermediate Point (MIP) is an intermediate point = that
   does not generally = initiate OAM frames (one exception to this is the
   use of AIS notifications), but is able to = respond to OAM frames that
   are = destined to it. A MIP in MPLS-TP identifies OAM packets = destined
   to it by the value of the = TTL field in the OAM packet. The term
  =  Maintenance Point is a general term for MEPs and MIPs.

Up and Down = MEPs

   The = IEEE 802.1ag [IEEE802.1Q] defines a distinction between Up = MEPs
   and Down MEPs. A MEP is a = bridge interface that is monitored by an
   OAM = protocol either in the direction facing the network, or in the
   direction facing the bridge. A Down MEP is a = MEP that receives OAM
   packets from, and = transmits them to the direction of the network. An
   Up MEP receives OAM packets from, and transmits = them to the direction
   of the bridging entity. = MPLS-TP ([TP-OAM-FW]) uses a similar
  =  distinction on the placement of the MEP - either at the = ingress,
   egress, or forwarding = function of the node (Down / Up MEPs).  This
   placement is important for localization of a = failure.

   The distinction between Up and Down MEPs was = defined in [TP-OAM-FW],
   but has = not been used in other MPLS-TP RFCs, as of the writing of
   this document.

4.5.3. Generic Associated = Channel

   In order to address the requirement for in-band = transmission of MPLS-
   TP OAM traffic, MPLS-TP = uses a Generic Associated Channel (G-ACh),
  =  defined in [G-ACh] for LSP-based OAM traffic. This mechanism is = based
   on the same concepts as = the PWE3 ACH and VCCV mechanisms.  However,
   to address the needs of LSPs as differentiated = from PW, the following
   concepts were defined for = [G-ACh]:

   o An Associated Channel Header (ACH), that uses = a format similar to
      the PW Control = Word, is a 4-byte header that is prepended to OAM
      packets.

   o A Generic Associated = Label (GAL). The GAL is a reserved MPLS label
      value (13) that indicates that the = packet is an ACH packet and the
      = payload follows immediately after the label stack.

   It = should be noted that while the G-ACh was defined as part of = the
   MPLS-TP definition = effort, the G-ACh is a generic tool that can be
   used in MPLS in general, and not only in = MPLS-TP.


Mizrahi, et al. =         Expires July 9, 2014       =           [Page 22]
Internet-Draft          Overview of = OAM Tools             January = 2014


4.5.4. MPLS-TP OAM Toolset

   To = address the functionality that is required of the OAM toolset, = the
   MPLS WG conducted an = analysis of the existing IETF and ITU-T OAM
   tools and their ability to fulfill the required = functionality.  The
  =  conclusions of this analysis are documented in [OAM-Analys]. The = MPLS
   working group currently = plans to use a mixture of OAM tools that are
   based on various existing standards, and adapt = them to the
   requirements of = [MPLS-TP-OAM]. Some of the main building blocks of
   this solution are based on:

   o = Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for
      proactive continuity check and = connectivity verification.

   o LSP Ping as defined in = [LSP-Ping] for on-demand connectivity
      = verification.

   o New protocol packets, using G-ACH, to address = different
      = functionality.

   o Performance measurement protocols that are = based on the
      functionality = that is described in [ITU-T-Y1731].

   The following = sub-sections describe the OAM tools defined for MPLS-TP
   as described in [TP-OAM-FW].

4.5.4.1. Continuity = Check and Connectivity Verification

   Continuity Check and = Connectivity Verification are presented in
  =  Section 2.2.7. of this document.  As presented there, these = tools may
   be used either = proactively or on-demand.  When using these tools
   proactively, they are generally used in = tandem.

   For MPLS-TP there are two distinct tools, the = proactive tool is
   defined in [TP-CC-CV] = while the on-demand tool is defined in
  =  [OnDemand-CV]. In on-demand mode, this function should = support
   monitoring between the = MEPs and, in addition, between a MEP and MIP.
   [TP-OAM-FW] highlights,  when performing = Connectivity Verification,
   the = need for the CC-V messages to include unique identification of
   the MEG that is being monitored and the MEP = that originated the
   message.

   The = proactive tool [TP-CC-CV] is based on extensions to BFD (see
   Section 4.3.) with the additional limitation = that the transmission
   and receiving rates are = based on configuration by the operator.  The
   on-demand tool [OnDemand-CV] is an adaptation = of LSP Ping (see
   Section 4.4.) for the = required behavior of MPLS-TP.


Mizrahi, et al.         Expires July 9, = 2014                 [Page = 23]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


4.5.4.2. Route = Tracing

   [MPLS-TP-OAM] defines that there is a need for = functionality that
   would allow a path = end-point to identify the intermediate and end-
   points of the path. This function would be used = in on-demand mode.
   Normally, this path will = be used for bidirectional PW, LSP, and
  =  sections, however, unidirectional paths may be supported only if = a
   return path exists.  The tool for this is = based on the LSP Ping (see
   Section = 4.4.) functionality and is described in [OnDemand-CV].

4.5.4.3. Lock = Instruct

   The Lock Instruct function [Lock-Loop] is used = to notify a transport
   path end-point of an = administrative need to disable the transport
   path.  This functionality will generally = be used in conjunction with
   some = intrusive OAM function, e.g. Performance measurement, = Diagnostic
   testing, to minimize the = side-effect on user data traffic.

4.5.4.4. Lock Reporting

   Lock = Reporting is a function used by an end-point of a path to = report
   to its far-end end-point = that a lock condition has been affected on
   the = path.

4.5.4.5. Alarm Reporting

   Alarm Reporting = [TP-Fault] provides the means to suppress alarms
   following detection of defect conditions at the = server sub-layer.
   Alarm reporting is used = by an intermediate point of a path, that
   becomes = aware of a fault on the path, to report to the end-points of
   the path. [TP-OAM-FW] states that this may = occur as a result of a
   defect condition = discovered at a server sub-layer. This generates an
   Alarm Indication Signal (AIS) that continues = until the fault is
   cleared. The consequent = action of this function is detailed in
  =  [TP-OAM-FW].

4.5.4.6. Remote Defect Indication

   Remote = Defect Indication (RDI) is used proactively by a path end-
   point to report to its peer end-point that a = defect is detected on a
  =  bidirectional connection between them. [MPLS-TP-OAM] points out = that
   this function may be = applied to a unidirectional LSP only if there a
   return path exists.  [TP-OAM-FW] points = out that this function is
  =  associated with the proactive CC-V function.





Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 24]
Internet-Draft =          Overview of OAM Tools     =         January 2014


4.5.4.7. Client Failure Indication

   Client = Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow
   the propagation information from one edge of = the network to the
   other. The information = concerns a defect to a client, in the case
   that = the client does not support alarm notification.

4.5.4.8. Performance = Monitoring

   The definition of MPLS performance monitoring = was motivated by the
   MPLS-TP requirements = [MPLS-TP-OAM], but was defined generically for
   MPLS in [MPLS-LM-DM]. An additional document = [TP-LM-DM] defines a
   performance monitoring = profile for MPLS-TP.

4.5.4.8.1. Packet Loss Measurement (LM)

   Packet = Loss Measurement is a function used to verify the quality of
   the service. Packet loss, as defined in = [IPPM-1LM] and [MPLS-TP-OAM],
  =  indicates the ratio of the number of user packets lost to the = total
   number of user packets = sent during a defined time interval.

   There are two possible = ways of determining this measurement:

   o Using OAM packets, it = is possible to compute the statistics based
      on a series of OAM packets. This, = however, has the disadvantage of
      = being artificial, and may not be representative since part of = the
      packet loss may = be dependent upon packet sizes and upon the
      implementation of the MEPs that take = part in the protocol.

   o Sending delimiting messages for the start and = end of a measurement
      period during = which the source and sink of the path count the
      packets transmitted and received. After = the end delimiter, the
      ratio would be = calculated by the path OAM entity.

4.5.4.8.2. Packet Delay Measurement = (DM)

   Packet = Delay Measurement is a function that is used to measure one-
   way or two-way delay of a packet transmission = between a pair of the
   end-points of a path (PW, = LSP, or Section). Where:

   o One-way packet delay, as defined in = [IPPM-1DM], is the time
      = elapsed from the start of transmission of the first bit of the
      packet by a source node until the = reception of the last bit of
      = that packet by the destination node. Note that one-way delay
      measurement requires the clocks of the = two end-points to be
      = synchronized.



Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 25]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   o Two-way packet delay, as defined in = [IPPM-2DM], is the time
      = elapsed from the start of transmission of the first bit of the
      packet by a source node until the = reception of the last bit of the
      = loop-backed packet by the same source node, when the loopback = is
      performed at the packet's destination = node. Note that due to
      possible path = asymmetry, the one-way packet delay from one end-
      point to another is not necessarily = equal to half of the two-way
      = packet delay.
      As opposed to = one-way delay measurement, two-way delay measurement
      does not require the two end-points to = be synchronized.

   For each of these two metrics, the DM function = allows the MEP to
   measure the delay, as = well as the delay variation. Delay measurement
   is performed by exchanging timestamped OAM = packets between the
   participating = MEPs.

4.6. Pseudowire OAM

4.6.1. Pseudowire OAM using Virtual = Circuit Connectivity Verification
  =  (VCCV)

   VCCV, as defined in [VCCV], provides a means = for end-to-end fault
   detection and diagnostics = tools to be extended for PWs (regardless of

TOM: Why "to be = extended"?  They've already been extended.

   the = underlying tunneling technology). The VCCV switching function
   provides a control channel associated with each = PW. [VCCV] defines
   three Control Channel = (CC) types, i.e., three possible methods for
   transmitting and identifying OAM = messages:

   o CC Type 1: In-band VCCV, as described in = [VCCV], is also referred
      = to as "PWE3 Control Word with 0001b as first nibble".  It uses = the
      PW Associated = Channel Header [PW-ACH].

   o CC Type 2: Out-of-band VCCV [VCCV], is also = referred to as "MPLS
      Router Alert = Label". In this case the control channel is created
      by using the MPLS router alert label = [MPLS-ENCAPS] immediately
      = above the PW label.

   o CC Type 3: TTL expiry VCCV [VCCV], is also = referred to as "MPLS PW
      = Label with TTL =3D=3D 1", i.e., the control channel is identified = when
      the value of the = TTL field in the PW label is set to 1.

   VCCV currently supports = the following OAM tools: ICMP Ping, LSP Ping,
   and BFD. ICMP and LSP Ping are IP encapsulated = before being sent over
   the PW ACH. BFD for VCCV = [BFD-VCCV] supports two modes of
  =  encapsulation - either IP/UDP encapsulated (with IP/UDP header) = or
   PW-ACH encapsulated (with no IP/UDP header) = and provides support to
   signal = the AC status. The use of the VCCV control channel provides


Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 26]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   the context, based on the MPLS-PW label, = required to bind and
   bootstrap the BFD session = to a particular pseudo wire (FEC),
  =  eliminating the need to exchange Discriminator values.

   VCCV = consists of two components: (1) signaled component to
   communicate VCCV capabilities as part of VC = label, and (2) switching
  =  component to cause the PW payload to be treated as a control = packet.

   VCCV is not directly dependent upon the = presence of a control plane.
   The = VCCV capability negotiation may be performed as part of the PW

TOM: There is not = really a capability "negotiation" per se; its a capability advertisement = with strict and explicit rules for what each end should do when = it receives capability = advertisements. 

   signaling when LDP is used. In case of manual = configuration of the
   PW, it is the = responsibility of the operator to set consistent
   options at both ends. The manual option was = created specifically to
   handle = MPLS-TP use cases where no control plane was a requirement.
   However, new use cases such as pure mobile = backhaul find this
   functionality useful = too.

   The = PWE3 working group has conducted an implementation survey of = VCCV
   [VCCV-SURVEY], which = analyzes which VCCV mechanisms are used in
  =  practice.

4.6.2. Pseudowire OAM using G-ACh

   As = mentioned above, VCCV enables OAM for PWs by using a control
   channel for OAM packets. When PWs are used in = MPLS-TP networks,
   rather than the control = channels defined in VCCV, the G-ACh can be
   used = as an alternative control channel. The usage of the G-ACh for
   PWs is defined in [PW-G-ACh].

4.6.3. Attachment = Circuit - Pseudowire Mapping

   The PWE3 working group = has defined a mapping and notification of
   defect = states between a pseudowire (PW) and the Attachment Circuits
   (ACs) of the end-to-end emulated service. This = mapping is of key
   importance to the = end-to-end functionality. Specifically, the mapping
   is provided by [PW-MAP], by [L2TP-EC] for = L2TPv3 pseudowires, and
   Section = 5.3 of [ATM-L2] for ATM.

4.7. OWAMP and TWAMP

4.7.1. Overview

   The = IPPM working group in the IETF defines common criteria and
   metrics for measuring performance of IP traffic = ([IPPM-FW]). Some of
   the key RFCs published by = this working group have defined metrics for
   measuring connectivity [IPPM-Con], delay = ([IPPM-1DM], [IPPM-2DM]),
   and = packet loss [IPPM-1LM]. It should be noted that the work of = the


Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 27]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   IETF in the context of performance metrics is = not limited to IP
   networks; [PM-CONS] = presents general guidelines for considering new
   performance metrics.

   The = IPPM working group has defined not only metrics for = performance
   measurement, but also = protocols that define how the measurement is
   carried out. The One-way Active Measurement = Protocol [OWAMP] and the
   Two-Way = Active Measurement Protocol [TWAMP] define a method and
   protocol for measuring performance metrics in = IP networks.

   OWAMP [OWAMP] enables measurement of one-way = characteristics of IP
   networks, such as one-way = packet loss and one-way delay.  For its
   proper operation OWAMP requires accurate time = of day setting at its
   end points.

   TWAMP = [TWAMP] is a similar protocol that enables measurement of both
   one-way and two-way (round trip) = characteristics.

   OWAMP and TWAMP are both comprised of two = separate protocols:

   o OWAMP-Control/TWAMP-Control: used to = initiate, start, and stop
      = test sessions and to fetch their results. Continuity Check and
      Connectivity Verification are tested = and confirmed by establishing
      = the OWAMP/TWAMP Control Protocol TCP connection.

   o = OWAMP-Test/TWAMP-Test: used to exchange test packets between = two
      measurement = nodes. Enables the loss and delay measurement
      functions, as well as detection of = other anomalies, such as packet
      = duplication and packet reordering.

   It should be noted that = while [OWAMP] and [TWAMP] define tools for
  =  performance measurement, they do not define the accuracy of = these
   tools. The accuracy = depends on scale, implementation and network
   configurations.

   Alternative protocols for = performance monitoring are defined, for
  =  example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in = Ethernet
   OAM = [ITU-T-Y1731].

4.7.2. Control and Test Protocols

   OWAMP = and TWAMP control protocols run over TCP, while the test
   protocols run over UDP.  The purpose of = the control protocols is to
  =  initiate, start, and stop test sessions, and for OWAMP to = fetch
   results.  The test = protocols introduce test packets (which contain
   sequence numbers and timestamps) along the IP = path under test
   according to a schedule, = and record statistics of packet arrival.


Mizrahi, et al.         Expires July 9, = 2014                 [Page = 28]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


  =  Multiple sessions may be simultaneously defined, each with a = session
   identifier, and defining = the number of packets to be sent, the amount
   of padding to be added (and thus the packet = size), the start time,
   and the send schedule = (which can be either a constant time between
   test packets or exponentially distributed = pseudo-random). Statistics
  =  recorded conform to the relevant IPPM RFCs.

   OWAMP = and TWAMP test traffic is designed with security in mind. Test
   packets are hard to detect because they are = simply UDP streams
   between negotiated port = numbers, with potentially nothing static in
   the packets.  OWAMP and TWAMP also include = optional authentication
   and = encryption for both control and test packets.

4.7.3. = OWAMP

   OWAMP defines the following logical roles: = Session-Sender, Session-
  =  Receiver, Server, Control-Client, and Fetch-Client.  The = Session-
   Sender originates test = traffic that is received by the Session-
  =  Receiver.  The Server configures and manages the session, as = well as
   returning the results. =  The Control-Client initiates requests for
   test sessions, triggers their start, and may = trigger their
   termination.  The = Fetch-Client requests the results of a completed
   session.  Multiple roles may be combined = in a single host - for
   example, one host may = play the roles of Control-Client, Fetch-Client,
   and Session-Sender, and a second playing the = roles of Server and
  =  Session-Receiver.

   In a typical OWAMP session the Control-Client = establishes a TCP
   connection to port 861 of = the Server, which responds with a server
  =  greeting message indicating supported security/integrity modes. = The
   Control-Client responds = with the chosen communications mode and the
   Server accepts the modes.  The = Control-Client then requests and fully
  =  describes a test session to which the Server responds with = its
   acceptance and supporting = information.  More than one test session
   may be requested with additional messages. =  The Control-Client then
   starts = a test session and the Server acknowledges.  The Session-
   Sender then sends test packets with = pseudorandom padding to the
  =  Session-Receiver until the session is complete or until the = Control-
   client stops the session. =  Once finished, the Fetch-Client sends a
   fetch request to the server, which responds = with an acknowledgement
   and = immediately thereafter the result data.

4.7.4. TWAMP

   TWAMP = defines the following logical roles: session-sender, session-
   reflector, server, and control-client. =  These are similar to the



Mizrahi, et al. =         Expires July 9, 2014       =           [Page 29]
Internet-Draft          Overview of = OAM Tools             January = 2014


   OWAMP roles, except that = the Session-Reflector does not collect any
   packet = information, and there is no need for a Fetch-Client.

   In a = typical TWAMP session the Control-Client establishes a TCP
   connection to port 862 of the Server, and mode = is negotiated as in
   OWAMP.  The = Control-Client then requests sessions and starts them.
   The Session-Sender sends test packets with = pseudorandom padding to
   the = Session-Reflector which returns them with insertion of
   timestamps.

4.8. TRILL

   The = requirements of OAM in TRILL are defined in [TRILL-OAM]. The
   challenge in TRILL OAM, much like in MPLS = networks, is that traffic
   between = RBridges RB1 and RB2 may be forwarded through more than one
   path. Thus, an OAM protocol between RBridges = RB1 and RB2 must be able
   to = monitor all the available paths between the two RBridge.

   During = the writing of this document the detailed definition of the
   TRILL OAM tools are still work in progress. = This subsection presents
   the = main requirements of TRILL OAM.

   The main requirements = defined in [TRILL-OAM] are:

   o Continuity Checking = (CC) - the TRILL OAM protocol must support a
      function for CC between any two = RBridges RB1 and RB2.

   o Connectivity Verification (CV) - connectivity = between two RBridges
      RB1 and RB2 can = be verified on a per-flow basis.

   o Path Tracing - allows = an RBridge to trace all the available paths
      to a peer RBridge.

   o = Performance monitoring - allows an RBridge to monitor the = packet
      loss and packet = delay to a peer RBridge.

5. Summary

   This section summarizes the OAM tools and = functions presented in this
  =  document. This summary is an index to some of the main OAM = tools
   defined in the IETF. This = compact index that can be useful to all
   readers = from network operators to standard development organizations.
   The summary includes a short subsection that = presents some guidance
   to network equipment = vendors.





Mizrahi, et al. =         Expires July 9, 2014       =           [Page 30]
Internet-Draft          Overview of = OAM Tools             January = 2014


5.1. Summary of OAM Tools

   This = subsection provides a short summary of each of the OAM = toolsets
   described in this = document.

   A detailed list of the RFCs related to each = toolset is given in
   Appendix A.1.

  =  +-----------+------------------------------------------+------------= +
   | Toolset   | Description     =                     =      | Transport  |
   | =           |           =                     =            | Technology |
  =  +-----------+------------------------------------------+------------= +
   |IP Ping    | Ping ([IntHost], = [NetTerms]) is a simple | IPv4/IPv6  |
   |           | = application for testing reachability that|         =    |
   |       =     | uses ICMP Echo messages ([ICMPv4],       = |            |
   |           | = [ICMPv6]).                 =               |       =      |
  =  +-----------+------------------------------------------+------------= +
   |IP         | Traceroute = ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6  |
   |Traceroute | an application that allows users = to trace|            |
   |           | the path = between an IP source and an IP  |         =    |
   |       =     | destination, i.e., to identify the nodes |     =        |
   | =           | along the path. If more than one = path    |            |
   |           | exists = between the source and destination|           =  |
   |       =     | Traceroute traces *a* path. The most     | =            |
   | =           | common implementation of Traceroute =      |           =  |
   |       =     | uses UDP probe messages, although there  |   =          |
   | =           | are other implementations that use =       |           =  |
   |       =     | different probes, such as ICMP or TCP.   |   =          |
  =  +-----------+------------------------------------------+------------= +
   |BFD        | Bidirectional = Forwarding Detection (BFD) | generic    |
   |           | is = defined in [BFD] as a framework for a |         =    |
   |       =     | lightweight generic OAM tool.  The     =   |            |
   |           | = intention is to define a base tool       |     =        |
   | =           | that can be used with various =            |         =    |
   |       =     | encapsulation types, network         =     |            |
   |           | = environments, and in various medium      |     =        |
   | =           | types.         =                     =       |           =  |
  =  +-----------+------------------------------------------+------------= +
   |MPLS OAM   | MPLS LSP Ping, as defined in = [MPLS-OAM], | MPLS       |
   | =           | [MPLS-OAM-FW] and [LSP-Ping], is an = OAM  |            |
   |           | tool for = point-to-point and              | =            |
   | =           | point-to-multipoint MLPS LSPs. =           |           =  |


Mizrahi, et al. =         Expires July 9, 2014       =           [Page 31]
Internet-Draft          Overview of = OAM Tools             January = 2014


   |       =     | It includes two main functions: Ping and |     =        |
   | =           | Traceroute.       =                     =    |            |
   |           | It is = noted that while this category     |       =      |
   |       =     | focuses on LSP Ping, other OAM tools     | =            |
   | =           | can be used in MPLS networks, e.g., = BFD. |            |
  =  +-----------+------------------------------------------+------------= +
   |MPLS-TP OAM| MPLS-TP OAM is defined in a set = of RFCs. | MPLS-TP    |
   | =           | The OAM requirements for MPLS = Transport  |            |
   |           | Profile = (MPLS-TP) are defined in         |     =        |
   | =           | [MPLS-TP-OAM]. Each of the tools in = the  |            |
   |           | OAM = toolset is defined in its own RFC, as|         =    |
   |       =     | specified in Section A.1.         =        |           =  |
  =  +-----------+------------------------------------------+------------= +
   |Pseudowire | The PWE3 OAM architecture defines = control| Pseudowire |
   |OAM       =  | channels that support the use of existing|       =      |
   |       =     | IETF OAM tools to be used for a pseudo-  |   =          |
   | =           | wire (PW).  The control = channels that are|            |
   |           | defined = in [VCCV] and [PW-G-ACh] may be  |         =    |
   |       =     | used in conjunction with ICMP Ping, LSP  |   =          |
   | =           | Ping, and BFD to perform CC and CV =       |           =  |
   |       =     | functionality.  In addition the channels |   =          |
   | =           | support use of any of the MPLS-TP = based  |            |
   |           | OAM = tools for completing their respective|         =    |
   |       =     | OAM functionality for a PW.         =      |           =  |
  =  +-----------+------------------------------------------+------------= +
   |OWAMP and  | The One Way Active = Measurement Protocol  | IPv4/IPv6  |
   |TWAMP      | (OWAMP) and the = Two Way Active Measure-  |           =  |
   |       =     | ment Protocols (TWAMP) are two protocols |     =        |
   | =           | defined in the IP Performance = Metrics    |           =  |
   |       =     | (IPPM) working group in the IETF. These  |   =          |
   | =           | protocols allow various performance =      |           =  |
   |       =     | metrics to be measured, such as packet   |   =          |
   | =           | loss, delay and delay variation, =         |           =  |
   |       =     | duplication and reordering.         =      |           =  |
  =  +-----------+------------------------------------------+------------= +
   |TRILL OAM  | The requirements of OAM in = TRILL are     | TRILL      |
   |           | defined = in [TRILL-OAM]. These            |   =          |
   | =           | requirements include continuity = checking,|            |
   |           | = connectivity verification, path tracing  |       =      |
   |       =     | and performance monitoring. During the   |   =          |
   | =           | writing of this document the = detailed    |           =  |


Mizrahi, et al. =         Expires July 9, 2014       =           [Page 32]
Internet-Draft          Overview of = OAM Tools             January = 2014


   |       =     | definition of the TRILL OAM tools       =  |            |
   |           | is work = in progress.                 =     |            |
  =  +-----------+------------------------------------------+------------= +
                =  Table 3 Summary of OAM-related IETF Tools

5.2. Summary of OAM = Functions

   Table 4 summarizes the OAM functions that are = supported in each of
   the toolsets that were = analyzed in this section. The columns of this
   tables are the typical OAM functions described = in Section 1.3.

      =  +-----------+-------+--------+--------+-------+----------+       |         =   |Continu|Connecti|Path    |Perform|Other     = |
       |         =   |ity    |vity    |Discover|ance   = |Function  |
       |   =         |Check  |Verifica|y     =   |Monitor|s         |
       | Toolset   |     =   |tion    |        |ing   =  |          |
      =  +-----------+-------+--------+--------+-------+----------+       |IP Ping    |Echo =   |        |        | =       |          |
       + --------- + ----- + ------ + = ------ + ----- + -------- +
      =  |IP         |       |   =      |Tracerou|       |     =      |
       |Traceroute = |       |        |te     =  |       |         =  |
       + --------- = + ----- + ------ + ------ + ----- + -------- +
       |BFD       =  |BFD    |BFD     |       =  |       |RDI usi-  |
       |         =   |Control|Control |        |     =   |ng BFD    |
      =  |           |/ Echo |     =    |        |       = |Control   |
       + --------- = + ----- + ------ + ------ + ----- + -------- +
       |MPLS OAM   |     =   |"Ping"  |"Tracero|       |     =      |
       |(LSP Ping) = |       |mode    |ute"    |   =     |          |
       |         =   |       |        |mode   =  |       |         =  |
       + --------- = + ----- + ------ + ------ + ----- + -------- +
       |MPLS-TP    |CC   =   |CV/pro- |Route   |-LM    |-Diagnos- |
       |OAM        | =       |active  |Tracing |-DM    | tic Test = |
       |         =   |       |or on-  |       =  |       |-Lock     |
       |         =   |       |demand  |       =  |       |-Alarm    |
       |         =   |       |        |   =      |       |Reporting |
       |         =   |       |        |   =      |       |-Client   |
       |         =   |       |        |   =      |       |Failure   |
       |         =   |       |        |   =      |       |Indication|
       |         =   |       |        |   =      |       |-RDI     =  |
       + --------- = + ----- + ------ + ------ + ----- + -------- +
       |Pseudowire |BFD   =  |-BFD    |LSP-Ping|       |     =      |
       |OAM   =      |       |-ICMP   |     =    |       |         =  |


Mizrahi, et al. =         Expires July 9, 2014       =           [Page 33]
Internet-Draft          Overview of = OAM Tools             January = 2014


       |   =         |       | Ping   | =        |       |       =    |
       |   =         |       |-LSP-   | =        |       |       =    |
       |   =         |       | Ping   | =        |       |       =    |
       + --------- = + ----- + ------ + ------ + ----- + -------- +
       |OWAMP and  | - control =      |        |-Delay |     =      |
       |TWAMP =      |   protocol     |     =    | measur|          |
       |         =   |                |   =      | ement |         =  |
       |   =         |             =    |        |-Packet|       =    |
       |   =         |             =    |        | loss  |     =      |
       |   =         |             =    |        | measur|       =    |
       |   =         |             =    |        | ement |       =    |
       + --------- = + ----- + ------ + ------ + ----- + -------- +
       |TRILL OAM  |CC   =   |CV      |Path    |-Delay |   =        |
      =  |           |       | =        |tracing | measur|       =    |
       |   =         |       |     =    |        | ement |       =    |
       |   =         |       |     =    |        |-Packet|       =    |
       |   =         |       |     =    |        | loss  |     =      |
       |   =         |       |     =    |        | measur|       =    |
       |   =         |       |     =    |        | ement |       =    |
      =  +-----------+-------+--------+--------+-------+----------+         Table 4 Summary of the OAM = Functionality in IETF OAM Tools

5.3. Guidance to Network Equipment = Vendors

   As mentioned in Section 1.4. , it is imperative = for OAM tools to be
   capable of testing the = actual data plane in as much accuracy as
  =  possible. While this guideline may appear obvious, it is = worthwhile
   to emphasize the key = importance of enforcing fate-sharing between OAM
   traffic that monitors the data plane and the = data plane traffic it
   monitors.

6. Security = Considerations

   This memo presents an overview of existing OAM = tools, and proposes
   no new OAM tools. = Therefore, this document introduces no security
   considerations. However, the OAM tools reviewed = in this document can
   and do present security = issues. The reader is encouraged to review
   the = Security Considerations section of each document referenced by
   this memo.

7. IANA Considerations

   There = are no new IANA considerations implied by this document.



Mizrahi, et al.         Expires July 9, = 2014                 [Page = 34]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


8. = Acknowledgments

   The authors gratefully acknowledge Sasha = Vainshtein, Carlos
   Pignataro, David = Harrington, Dan Romascanu, Ron Bonica and other
   members of the OPSAWG mailing list for their = helpful comments.

   This document was prepared using = 2-Word-v2.0.template.dot.

9. References

9.1. Informative = References

   [ATM-L2]      Singh, S., = Townsley, M., and C. Pignataro,
      =            "Asynchronous Transfer Mode = (ATM) over Layer 2
          =        Tunneling Protocol Version 3 (L2TPv3)", RFC = 4454, May
          =        2006.

   [BFD]     =     Katz, D., Ward, D., "Bidirectional Forwarding = Detection
          =        (BFD)", RFC 5880, June 2010.

  =  [BFD-Gen]     Katz, D., Ward, D., "Generic Application = of
                =  Bidirectional Forwarding Detection (BFD)", RFC 5882,
                =  June 2010.

   [BFD-IP]      Katz, D., Ward, = D., "Bidirectional Forwarding Detection
      =            (BFD) for IPv4 and IPv6 (Single = Hop)", RFC 5881, June
          =        2010.

   [BFD-LSP]     = Aggarwal, R., Kompella, K., Nadeau, T., and Swallow,
                =  G., "Bidirectional Forwarding Detection (BFD) for MPLS
                =  Label Switched Paths (LSPs)", RFC 5884, June 2010.

  =  [BFD-Multi]   Katz, D., Ward, D., "Bidirectional Forwarding = Detection
          =        (BFD) for Multihop Paths", RFC 5883, June = 2010.

   [BFD-VCCV]    Nadeau, T., Pignataro, = C., "Bidirectional Forwarding
      =            Detection (BFD) for the = Pseudowire Virtual Circuit
      =            Connectivity Verification = (VCCV)", RFC 5885, June
      =            2010.

   [Comp] =        Bonaventure, O., "Computer Networking: = Principles,
          =        Protocols and Practice", 2008.

   [Dup] =         Uijterwaal, H., "A One-Way Packet = Duplication Metric",
          =        RFC 5560, May 2009.




Mizrahi, et al. =         Expires July 9, 2014       =           [Page 35]
Internet-Draft          Overview of = OAM Tools             January = 2014


   [G-ACh]     =   Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic
                =  Associated Channel", RFC 5586, June 2009.

  =  [ICMP-Ext]    Bonica, R., Gan, D., Tappan, D., = Pignataro, C., "ICMP
          =        Extensions for Multiprotocol Label = Switching", RFC
          =        4950, August 2007.

  =  [ICMP-Int]    Atlas, A., Bonica, R., Pignataro, C., = Shen, N., Rivers,
          =        JR., "Extending ICMP for Interface and = Next-Hop
          =        Identification", RFC 5837, April = 2010.

   [ICMP-MP]     Bonica, R., Gan, D., = Tappan, D., Pignataro, C.,
      =            "Extended ICMP to Support = Multi-Part Messages", RFC
      =            4884, April 2007.

  =  [ICMPv4]      Postel, J., "Internet Control Message = Protocol", STD 5,
          =        RFC 792, September 1981.

  =  [ICMPv6]      Conta, A., Deering, S., and M. Gupta, = "Internet Control
          =        Message Protocol (ICMPv6) for the Internet = Protocol
          =        Version 6 (IPv6) Specification", RFC 4443, = March 2006.

   [IEEE802.1Q]  IEEE 802.1Q, "IEEE Standard = for Local and metropolitan
      =            area networks - Media Access = Control (MAC) Bridges and
      =            Virtual Bridged Local Area = Networks", October 2012.

   [IEEE802.3ah] IEEE 802.3, "IEEE Standard for = Information technology -
      =            Local and metropolitan area = networks - Carrier sense
      =            multiple access with collision = detection (CSMA/CD)
          =        access method and physical layer = specifications",
          =        clause 57, December 2008.

  =  [IntHost]     Braden, R., "Requirements for Internet = Hosts --
          =        Communication Layers", RFC 1122, October = 1989.

   [IPPM-1DM]    Almes, G., Kalidindi, = S., Zekauskas, M., "A One-way
      =            Delay Metric for IPPM", RFC = 2679, September 1999.

   [IPPM-1LM]    Almes, G., Kalidindi, = S., Zekauskas, M., "A One-way
      =            Packet Loss Metric for IPPM", = RFC 2680, September
          =        1999.

   [IPPM-2DM]   =  Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip
                =  Delay Metric for IPPM", RFC 2681, September 1999.

  =  [IPPM-Con]    Mahdavi, J., Paxson, V., "IPPM Metrics for = Measuring
          =        Connectivity", RFC 2678, September = 1999.


Mizrahi, et al. =         Expires July 9, 2014       =           [Page 36]
Internet-Draft          Overview of = OAM Tools             January = 2014


   [IPPM-FW]     = Paxson, V., Almes, G., Mahdavi, J., and Mathis, M.,
                =  "Framework for IP Performance Metrics", RFC 2330, May
                =  1998.

   [ITU-G8113.1] ITU-T Recommendation = G.8113.1/Y.1372.1, "Operations,
      =            Administration and Maintenance = mechanism for MPLS-TP
          =        in Packet Transport Network (PTN)", November = 2012.

   [ITU-G8113.2] ITU-T Recommendation = G.8113.2/Y.1372.2, "Operations,
      =            administration and maintenance = mechanisms for MPLS-TP
          =        networks using the tools defined for MPLS", = November
          =        2012.

   [ITU-T-CT]   =  Betts, M., "Allocation of a Generic Associated Channel
                =  Type for ITU-T MPLS Transport Profile Operation,
                =  Maintenance, and Administration (MPLS-TP OAM)", RFC
                =  6671, November 2012.

   [ITU-T-G.806] ITU-T = Recommendation G.806, "Characteristics of
      =            transport equipment - = Description methodology and
      =            generic functionality", January = 2009.

   [ITU-T-Y1711] ITU-T Recommendation Y.1711, = "Operation & Maintenance
      =            mechanism for MPLS networks", = February 2004.

   [ITU-T-Y1731] ITU-T Recommendation = G.8013/Y.1731, "OAM Functions and
      =            Mechanisms for Ethernet-based = Networks", July 2011.

   [ITU-Terms]   ITU-R/ITU-T Terms and = Definitions, online, 2013.

   [L2TP-EC]     = McGill, N. and C. Pignataro, "Layer 2 Tunneling
                =  Protocol Version 3 (L2TPv3) Extended Circuit Status
                =  Values", RFC 5641, August 2009.

   [Lock-Loop]   = Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux,
                =  M., Dai, X., "MPLS Transport Profile Lock Instruct and
                =  Loopback Functions", RFC 6435, November 2011.

  =  [LSP-Ping]    Kompella, K., Swallow, G., "Detecting = Multi-Protocol
          =        Label Switched (MPLS) Data Plane Failures", = RFC 4379,
          =        February 2006.

   [Mng]     =     Farrel, A., "Inclusion of Manageability Sections = in
                =  Path Computation Element (PCE) Working Group Drafts",
                =  RFC 6123, February 2011.




Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 37]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, = G., Rekhter, Y.,
          =        Farinacci, D., Li, T. and A. Conta, "MPLS = Label Stack
          =        Encoding", RFC 3032, January 2001.

  =  [MPLS-LM-DM]  Frost, D., Bryant, S., "Packet Loss and = Delay
          =        Measurement for MPLS Networks", RFC 6374, = September
          =        2011.

   [MPLS-OAM]   =  Nadeau, T., Morrow, M., Swallow, G., Allan, D.,
                =  Matsushima, S., "Operations and Management (OAM)
                =  Requirements for Multi-Protocol Label Switched (MPLS)
                =  Networks", RFC 4377, February 2006.

   [MPLS-OAM-FW] Allan, D., = Nadeau, T., "A Framework for Multi-Protocol
                =  Label Switching (MPLS) Operations and Management
                =  (OAM)", RFC 4378, February 2006.

   [MPLS-P2MP]   = Yasukawa, S., Farrel, A., King, D., Nadeau, T.,
                =  "Operations and Management (OAM) Requirements for
                =  Point-to-Multipoint MPLS Networks", RFC 4687,
                =  September 2006.

   [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, = M., "Requirements for
          =        OAM in MPLS Transport Networks", RFC 5860, = May 2010.

   [NetTerms]    Jacobsen, O., Lynch, = D., "A Glossary of Networking
      =            Terms", RFC 1208, March = 1991.

   [NetTools]    Enger, R., Reynolds, = J., "FYI on a Network Management
      =            Tool Catalog: Tools for = Monitoring and Debugging
      =            TCP/IP Internets and = Interconnected Devices", RFC
      =            1470, June 1993.

  =  [OAM-Analys]  Sprecher, N., Fang, L., "An Overview of the OAM = Tool
          =        Set for  MPLS based Transport Networks", = RFC 6669,
          =        July 2012.

   [OAM-Def]     = Andersson, L., Van Helvoort, H., Bonica, R., Romascanu,
                =  D., Mansfield, S., "Guidelines for the use of the OAM
                =  acronym in the IETF ", RFC 6291, June 2011.

  =  [OAM-Label]   Ohta, H., "Assignment of the 'OAM Alert Label' = for
          =        Multiprotocol Label Switching Architecture = (MPLS)
          =        Operation and Maintenance (OAM) Functions", = RFC 3429,
          =        November 2002.




Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 38]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   [OnDemand-CV] Gray, E., Bahadur, N., Boutros, = S., Aggarwal, R. "MPLS
          =        On-Demand Connectivity Verification and = Route
          =        Tracing", RFC 6426, November 2011.

   [OWAMP] =       Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., = and
          =        Zekauskas, M., "A One-way Active Measurement = Protocol
          =        (OWAMP)", RFC 4656, September 2006.

   [PARIS] =       Brice Augustin, Timur Friedman and Renata = Teixeira,
          =        "Measuring Load-balanced Paths in the = Internet", IMC,
          =        2007.

   [PM-CONS]     = Clark, A. and B. Claise, "Guidelines for Considering
                =  New Performance Metric Development", BCP 170, RFC
                =  6390, October 2011.

   [PW-ACH]     =  Bryant, S., Swallow, G., Martini, L., McPherson, D.,
                =  "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
                =  for Use over an MPLS PSN", RFC 4385, February 2006.

  =  [PW-G-ACh]    Li, H., Martini, L., He, J., Huang, F., = "Using the
          =        Generic Associated Channel Label for = Pseudowire in the
          =        MPLS Transport Profile (MPLS-TP)", RFC 6423, = November
          =        2011.

   [PW-MAP]     =  Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
                =  Nadeau, T., and Y(J). Stein, "Pseudowire (PW)
                =  Operations, Administration, and Maintenance (OAM)
                =  Message Mapping", RFC 6310, July 2011.

  =  [Reorder]     Morton, A., Ciavattone, L., Ramachandran, = G., Shalunov,
          =        S., and J. Perser, "Packet Reordering = Metrics", RFC
          =        4737, November 2006.

  =  [Signal]      Yasukawa, S., "Signaling Requirements = for Point-to-
          =        Multipoint Traffic-Engineered MPLS Label = Switched
          =        Paths (LSPs)", RFC 4461, April = 2006.

   [TCPIP-Tools] Kessler, G., Shepard, S., "A = Primer On Internet and
          =        TCP/IP Tools and Utilities", RFC 2151, June = 1997.

   [TP-CC-CV]    Allan, D., Swallow, G., = Drake, J., "Proactive
          =        Connectivity Verification, Continuity Check = and Remote
          =        Defect indication for MPLS Transport = Profile", RFC
          =        6428, November 2011.




Mizrahi, et al. =         Expires July 9, 2014       =           [Page 39]
Internet-Draft          Overview of = OAM Tools             January = 2014


   [TP-Fault]   =  Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
                =  "MPLS Fault Management Operations, Administration, and
                =  Maintenance (OAM)", RFC 6427, November 2011.

  =  [TP-LM-DM]    Frost, D., Bryant, S., "A Packet Loss and = Delay
          =        Measurement Profile for MPLS-Based = Transport
          =        Networks", RFC 6375, September = 2011.

   [TP-OAM-FW]   Busi, I., Allan, D., = "Operations, Administration and
      =            Maintenance Framework for = MPLS-based Transport
          =        Networks ", RFC 6371, September = 2011.

   [TP-Term]     Van Helvoort, H., = Andersson, L., Sprecher, N., "A
      =            Thesaurus for the Terminology = used in MPLS Transport
          =        Profile (MPLS-TP) Internet-Drafts and RFCs in = the
          =        Context of the ITU-T's Transport = Network
          =        Recommendations", RFC 7087, December = 2013.

   [TRILL-OAM]   Senevirathne, T., Bond, D., = Aldrin, S., Li, Y., Watve,
      =            R., "Requirements for = Operations, Administration, and
      =            Maintenance (OAM) in = Transparent Interconnection of
      =            Lots of Links (TRILL)", RFC = 6905, March 2013.

   [TWAMP]       Hedayat, K., = Krzanowski, R., Morton, A., Yum, K., and
      =            Babiarz, J., "A Two-Way Active = Measurement Protocol
          =        (TWAMP)", RFC 5357, October 2008.

   [VCCV] =        Nadeau, T., Pignataro, C., "Pseudowire = Virtual Circuit
          =        Connectivity Verification (VCCV): A Control = Channel
          =        for Pseudowires", RFC 5085, December = 2007.

   [VCCV-SURVEY] Del Regno, N., Malis, A., "The = Pseudowire (PW) and
          =        Virtual Circuit Connectivity Verification = (VCCV)
          =        Implementation Survey Results", RFC 7079, = November
          =        2013.



Appendix A.   =               List of OAM = Documents

A.1. List of IETF OAM Documents

   Table 5 = summarizes the OAM related RFCs published by the IETF.

   It is = important to note that the table lists various RFCs that are
   different by nature. For example, some of these = documents define OAM
   tools or OAM protocols = (or both), while others define protocols that


Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 40]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   are not strictly OAM-related, but are used by = OAM tools. The table
   also includes RFCs that = define the requirements or the framework of
   OAM in a specific context (e.g., = MPLS-TP).

   The RFCs in the table are categorized in a few = sets as defined in
   Section 1.3.

  =  +-----------+--------------------------------------+----------+
   | Toolset   | Title       =                     =      | RFC      |
  =  +-----------+--------------------------------------+----------+
   |IP Ping    | Requirements for = Internet Hosts --   | RFC 1122 |
   | =           | Communication Layers [IntHost] =       |          |
   |           = +--------------------------------------+----------+
   |           | A = Glossary of Networking Terms       | RFC 1208 |
   |           | = [NetTerms]                 =           |         =  |
   |       =     = +--------------------------------------+----------+
   |           | Internet = Control Message Protocol    | RFC 792  |
   |           | [ICMPv4] =                     =         |         =  |
   |       =     = +--------------------------------------+----------+
   |           | Internet = Control Message Protocol    | RFC 4443 |
   |           | (ICMPv6) = for the Internet Protocol   |         =  |
   |       =     | Version 6 (IPv6) Specification       | =          |
   | =           | [ICMPv6]       =                     =   |          |
  =  +-----------+--------------------------------------+----------+
   |IP         | A Primer On = Internet and TCP/IP      | RFC 2151 |
   |Traceroute | Tools and Utilities [TCPIP-Tools] =    |          |
   |           = +--------------------------------------+----------+
   |           | FYI on a = Network Management Tool     | RFC 1470 |
   |           | Catalog: = Tools for Monitoring and    |         =  |
   |       =     | Debugging TCP/IP Internets and       | =          |
   | =           | Interconnected Devices [NetTools] =    |          |
   |           = +--------------------------------------+----------+
   |           | Internet = Control Message Protocol    | RFC 792  |
   |           | [ICMPv4] =                     =         |         =  |
   |       =     = +--------------------------------------+----------+
   |           | Internet = Control Message Protocol    | RFC 4443 |
   |           | (ICMPv6) = for the Internet Protocol   |         =  |
   |       =     | Version 6 (IPv6) Specification       | =          |
   | =           | [ICMPv6]       =                     =   |          |
   |           = +--------------------------------------+----------+
   |           | Extended = ICMP to Support Multi-Part  | RFC 4884 |
   |           | Messages = [ICMP-MP]                   = |          |


Mizrahi, et al.         Expires July 9, = 2014                 [Page = 41]
Internet-Draft       =    Overview of OAM Tools           =   January 2014


   | =           = +--------------------------------------+----------+
   |           | = Extending ICMP for Interface and     | RFC 5837 |
   |           | Next-Hop = Identification [ICMP-Int]   |         =  |
  =  +-----------+--------------------------------------+----------+
   |BFD        | Bidirectional = Forwarding Detection   | RFC 5880 |
   | =           | [BFD]         =                     =    |          |
   |           = +--------------------------------------+----------+
   |           | = Bidirectional Forwarding Detection   | RFC 5881 |
   |           | (BFD) = for IPv4 and IPv6 (Single Hop) |         =  |
   |       =     | [BFD-IP]             =                 |     =      |
   |       =     = +--------------------------------------+----------+
   |           | Generic = Application of Bidirectional | RFC 5882 |
   | =           | Forwarding Detection [BFD-Gen] =       |          |
   |           = +--------------------------------------+----------+
   |           | = Bidirectional Forwarding Detection   | RFC 5883 |
   |           | (BFD) = for Multihop Paths [BFD-Multi] |         =  |
   |       =     = +--------------------------------------+----------+
   |           | = Bidirectional Forwarding Detection   | RFC 5884 |
   |           | for MPLS = Label Switched Paths (LSPs) |         =  |
   |       =     | [BFD-LSP]             =                |     =      |
   |       =     = +--------------------------------------+----------+
   |           | = Bidirectional Forwarding Detection   | RFC 5885 |
   |           | for the = Pseudowire Virtual Circuit   |         =  |
   |       =     | Connectivity Verification (VCCV)     |   =        |
   | =           | [BFD-VCCV]       =                     | =          |
  =  +-----------+--------------------------------------+----------+
   |MPLS OAM   | Operations and Management = (OAM)      | RFC 4377 |
   | =           | Requirements for Multi-Protocol = Label|          |
   | =           | Switched (MPLS) Networks [MPLS-OAM] =  |          |
   |           = +--------------------------------------+----------+
   |           | A = Framework for Multi-Protocol       | RFC 4378 |
   |           | Label = Switching (MPLS) Operations    |         =  |
   |       =     | and Management (OAM) [MPLS-OAM-FW]   |   =        |
   | =           = +--------------------------------------+----------+
   |           | = Detecting Multi-Protocol Label       | RFC 4379 = |
   |           | Switched = (MPLS) Data Plane Failures  |         =  |
   |       =     | [LSP-Ping]             =               |       =    |
   |       =     = +--------------------------------------+----------+
   |           | = Operations and Management (OAM)      | RFC 4687 = |
   |           | = Requirements for Point-to-Multipoint |         =  |
   |       =     | MPLS Networks [MPLS-P2MP]         =    |          |


Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 42]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   |           = +--------------------------------------+----------+
   |           | ICMP = Extensions for Multiprotocol    | RFC 4950 |
   |           | Label = Switching [ICMP-Ext]           |     =      |
  =  +-----------+--------------------------------------+----------+
   |MPLS-TP    | Requirements for OAM in = MPLS-TP      | RFC 5860 |
   |OAM =        | [MPLS-TP-OAM]         =                |     =      |
   |       =     = +--------------------------------------+----------+
   |           | MPLS = Generic Associated Channel      | RFC 5586 |
   |           | [G-ACh] =                     =          |         =  |
   |       =     = +--------------------------------------+----------+
   |           | MPLS-TP = OAM Framework                | = RFC 6371 |
   |       =     | [TP-OAM-FW]             =              |       =    |
   |       =     = +--------------------------------------+----------+
   |           | = Proactive Connectivity Verification, | RFC 6428 |
   |           | = Continuity Check, and Remote Defect  |         =  |
   |       =     | Indication for the MPLS Transport    |   =        |
   | =           | Profile [TP-CC-CV]     =               |       =    |
   |       =     = +--------------------------------------+----------+
   |           | MPLS = On-Demand Connectivity          | RFC 6426 = |
   |           | = Verification and Route Tracing       |     =      |
   |       =     | [OnDemand-CV]             =            |         =  |
   |       =     = +--------------------------------------+----------+
   |           | MPLS = Fault Management Operations,    | RFC 6427 |
   |           | = Administration, and Maintenance (OAM)|         =  |
   |       =     | [TP-Fault]             =               |       =    |
   |       =     = +--------------------------------------+----------+
   |           | MPLS = Transport Profile Lock Instruct | RFC 6435 |
   |           | and = Loopback Functions [Lock-Loop]   |         =  |
   |       =     = +--------------------------------------+----------+
   |           | Packet = Loss and Delay Measurement for| RFC 6374 |
   | =           | MPLS Networks [MPLS-LM-DM]   =         |         =  |
   |       =     = +--------------------------------------+----------+
   |           | A Packet = Loss and Delay Measurement  | RFC 6375 |
   |           | Profile = for MPLS-Based Transport     |         =  |
   |       =     | Networks [TP-LM-DM]           =        |         =  |
  =  +-----------+--------------------------------------+----------+
   |Pseudowire | Pseudowire Virtual Circuit   =         | RFC 5085 |
   |OAM =        | Connectivity Verification (VCCV):   =  |          |
   |           | A = Control Channel for Pseudowires    |       =    |
   |       =     | [VCCV]               =                 |     =      |
   |       =     = +--------------------------------------+----------+


Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 43]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   |           | = Bidirectional Forwarding Detection   | RFC 5885 |
   |           | for the = Pseudowire Virtual Circuit   |         =  |
   |       =     | Connectivity Verification (VCCV)     |   =        |
   | =           | [BFD-VCCV]       =                     | =          |
   | =           = +--------------------------------------+----------+
   |           | Using = the Generic Associated Channel | RFC 6423 |
   |           | Label = for Pseudowire in the MPLS     |         =  |
   |       =     | Transport Profile (MPLS-TP)         =  |          |
   |           | = [PW-G-ACh]                 =           |         =  |
   |       =     = +--------------------------------------+----------+
   |           | = Pseudowire (PW) Operations,          | RFC 6310 = |
   |           | = Administration, and Maintenance (OAM)|         =  |
   |       =     | Message Mapping [PW-MAP]         =     |          |
  =  +-----------+--------------------------------------+----------+
   |OWAMP and  | A One-way Active Measurement = Protocol| RFC 4656 |
   |TWAMP     =  | [OWAMP]                 =              |       =    |
   |       =     = +--------------------------------------+----------+
   |           | A = Two-Way Active Measurement Protocol| RFC 5357 |
   |           | [TWAMP] =                     =          |         =  |
   |       =     = +--------------------------------------+----------+
   |           | = Framework for IP Performance Metrics | RFC 2330 |
   |           | = [IPPM-FW]                   =          |         =  |
   |       =     = +--------------------------------------+----------+
   |           | IPPM = Metrics for Measuring           | RFC 2678 = |
   |           | = Connectivity [IPPM-Con]             =  |          |
   |           = +--------------------------------------+----------+
   |           | A = One-way Delay Metric for IPPM      | RFC 2679 |
   |           | = [IPPM-1DM]                 =           |         =  |
   |       =     = +--------------------------------------+----------+
   |           | A = One-way Packet Loss Metric for IPPM| RFC 2680 |
   |           | = [IPPM-1LM]                 =           |         =  |
   |       =     = +--------------------------------------+----------+
   |           | A = Round-trip Delay Metric for IPPM   | RFC 2681 |
   |           | = [IPPM-2DM]                 =           |         =  |
   |       =     = +--------------------------------------+----------+
   |           | Packet = Reordering Metrics            | RFC 4737 = |
   |           | = [Reorder]                   =          |         =  |
   |       =     = +--------------------------------------+----------+
   |           | A = One-Way Packet Duplication Metric  | RFC 5560 |
   |           | [Dup] =                     =            |         =  |
  =  +-----------+--------------------------------------+----------+


Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 44]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   |TRILL OAM  | Requirements for Operations, =         | RFC 6905 |
   | =           | Administration, and Maintenance = (OAM)|          |
   | =           | in Transparent Interconnection of =    |          |
   |           | Lots of = Links (TRILL)                | =          |
  =  +-----------+--------------------------------------+----------+
                =  Table 5 Summary of IETF OAM Related RFCs

A.2. List of = Selected Non-IETF OAM Documents

   In addition to the OAM = tools defined by the IETF, the IEEE and ITU-T
   have also defined various OAM tools that focus = on Ethernet, and
   various other transport = network environments. These various tools,
  =  defined by the three standard organizations, are often = tightly
   coupled, and have had a = mutual effect on each other. The ITU-T and
   IETF = have both defined OAM tools for MPLS LSPs, [ITU-T-Y1711] and
   [LSP-Ping]. The following OAM standards by the = IEEE and ITU-T are to
   some extent linked to = IETF OAM tools listed above and are mentioned
   here only as reference material:

   o OAM = tools for Layer 2 have been defined by the ITU-T in
      [ITU-T-Y1731], and by the IEEE in = 802.1ag [IEEE802.1Q] . The IEEE
      = 802.3 standard defines OAM for one-hop Ethernet links
      [IEEE802.3ah].

   o The = ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and
      MPLS-TP OAM in [ITU-G8113.1] and = [ITU-G8113.2].

   It should be noted that these non-IETF = documents deal in many cases
   with = OAM functions below the IP layer (Layer 2, Layer 2.5) and in
   some cases operators use a multi-layered OAM = approach, which is a
   function of the way their = networks are designed.

   Table 6 summarizes some of the main OAM = standards published by non-
   IETF = standard organizations. This document focuses on IETF OAM
   standards, but these non-IETF standards are = referenced in this
   document where = relevant.

  =  +-----------+--------------------------------------+---------------+=
   |           | Title =                     =            |Standard/Draft |
  =  +-----------+--------------------------------------+---------------+=
   |ITU-T      | Operation & = Maintenance mechanism    | ITU-T Y.1711  |
   |MPLS OAM   | for MPLS networks = [ITU-T-Y1711]      |           =     |
   |       =     = +--------------------------------------+---------------+
   |           | = Assignment of the 'OAM Alert Label'  | RFC 3429     =  |
   |       =     | for Multiprotocol Label Switching    |   =             |


Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 45]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   |           | = Architecture (MPLS) Operation and    |       =         |
   | =           | Maintenance (OAM) Functions   =        |             =   |
   |       =     | [OAM-Label]             =              |       =         |
   | =           |           =                     =        |             =   |
   |       =     |  Note: although this is an IETF     =  |               |
   |           | =  document, it is listed as one of the|         =       |
   |       =     |  non-IETF OAM standards, since it    | =               |
   |           | =  was defined as a complementary part |         =       |
   |       =     |  of ITU-T Y.1711.         =            |         =       |
  =  +-----------+--------------------------------------+---------------+=
   |ITU-T      | Operations, = administration and       |ITU-T G.8113.2 |
   |MPLS-TP OAM| Maintenance mechanisms for = MPLS-TP   |               = |
   |           | networks = using the tools defined for |             =   |
   |       =     | MPLS [ITU-G8113.2]           =         |             =   |
   |       =     |                 =                     =  |               |
   |           | =  Note: this document describes the   |       =         |
   | =           |  OAM toolset defined by the = IETF for |               |
   |           | =  MPLS-TP, whereas ITU-T G.8113.1     |     =           |
   | =           |  describes the OAM toolset = defined   |               = |
   |           |  by = the ITU-T.                 =       |               = |
   |           = +--------------------------------------+---------------+
   |           | = Operations, Administration and       |ITU-T G.8113.1 = |
   |           | = Maintenance mechanism for MPLS-TP in |         =       |
   |       =     | Packet Transport Network (PTN)       | =               |
   |           = +--------------------------------------+---------------+
   |           | = Allocation of a Generic Associated   | RFC 6671     =  |
   |       =     | Channel Type for ITU-T MPLS Transport|     =           |
   | =           | Profile Operation, Maintenance, and =  |               |
   |           | = Administration (MPLS-TP OAM)         |     =           |
   | =           | [ITU-T-CT]       =                     | =               |
   |           |   =                     =                |     =           |
   | =           |  Note: although this is an = IETF      |             =   |
   |       =     |  document, it is listed as one of the|   =             |
   |           | =  non-IETF OAM standards, since it    |     =           |
   | =           |  was defined as a = complementary part |               = |
   |           |  of = ITU-T G.8113.1.                 =  |               |
  =  +-----------+--------------------------------------+---------------+=
   |ITU-T      | OAM Functions and = Mechanisms for     | ITU-T Y.1731  |
   |Ethernet   | Ethernet-based Networks =              |       =         |
   |OAM =        | [ITU-T-Y1731]         =                |     =           |
  =  +-----------+--------------------------------------+---------------+=


Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 46]
Internet-Draft =          Overview of OAM Tools     =         January 2014


   |IEEE       | Connectivity Fault = Management        | IEEE 802.1ag  |
   |CFM        | [IEEE802.1Q] =                     =     |               = |
   |           |   =                     =                |     =           |
   | =           |  Note: CFM was originally = published  |               = |
   |           |  as = IEEE 802.1ag, but is now         |     =           |
   | =           |  incorporated in the 802.1Q = standard.|               |
  =  +-----------+--------------------------------------+---------------+=
   |IEEE       | Management of Data = Driven and Data   | IEEE 802.1ag  |
   |DDCFM      | Dependent = Connectivity Faults        |       =         |
   | =           | [IEEE802.1Q]       =                   |   =             |
   |           |   =                     =                |     =           |
   | =           |  Note: DDCFM was originally = published|               |
   |           |  as = IEEE 802.1Qaw, but is now        |     =           |
   | =           |  incorporated in the 802.1Q = standard.|               |
  =  +-----------+--------------------------------------+---------------+=
   |IEEE       | Media Access = Control Parameters,     | IEEE 802.3ah  |
   |802.3      | Physical Layers, = and Management      |           =     |
   |link level | Parameters = for Subscriber Access     |           =     |
   |OAM       =  | Networks [IEEE802.3ah]             =   |               |
   |           |   =                     =                |     =           |
   | =           |  Note: link level OAM was = originally |               = |
   |           | =  defined in IEEE 802.3ah, and is now |         =       |
   |       =     |  incorporated in the 802.3 standard. |   =             |
  =  +-----------+--------------------------------------+---------------+=
         Table 6 Non-IETF OAM = Standards Mentioned in this Document



Authors' = Addresses

   Tal Mizrahi
  =  Marvell
   6 Hamada St.
   Yokneam, 20692
  =  Israel

   Email: talmi@marvell.com


   Nurit Sprecher
   NSN
   3 = Hanagar St. Neve Ne'eman B



Mizrahi, et al. =         Expires July 9, 2014       =           [Page 47]
Internet-Draft          Overview of = OAM Tools             January = 2014


   Hod Hasharon,   = 45241
   Israel

  =  Email: nurit.sprecher@nsn.com

   Elisa = Bellagamba
   Ericsson
   6 Farogatan St.
  =  Stockholm,   164 40
  =  Sweden

   Phone: +46 761440785
   Email: elisa.bellagamba@ericsson.co= m


   Yaacov = Weingarten
   34 Hagefen St.
   Karnei Shomron,   4485500
   Israel

   Email: wyaacov@gmail.com


























Mizrahi, et al.       =   Expires July 9, 2014             =     [Page 48]


On Jul 8, 2013:5:43 PM, at = 5:43 PM, Tal Mizrahi <talmi@marvell.com> = wrote:

Hi,
 
We have = updated draft-ietf-opsawg-oam-overview following the comments we = received in IETF last call.

= --Apple-Mail=_ECDDC72D-A55D-40B8-BA92-8852834B4501-- --Apple-Mail=_91D8F787-6B8B-45C4-94EA-54D49191EA94 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS3UDxAAoJEPcO+I7eiUJZTlgQAL1qr335XU/R3JuHeKTRRIk0 Xc42CGDDAnij4XYnS5MCIpKHv+r8odsrPx8ddGnIFasmSs1AZPfS2UDWlBjXSef2 ywH7H5PimZiuBbuH+OKlV3vCfJamnUqSQKzVJU8R7wjXLif/+UsX/9ytNHf6f5sg 69PT84ysew1OxyvOC6Hvf+I7IALn4VXzDNbbNwze4rkOTUeD0e4K5XZfcmCKK9yA UmCWvpdS3369O0nQiDGQu5RRcmb8fiW3X1jHmx18Vbx8RGa3FtSu7orVJsCT5I03 UOwFfwil6d0kdZXaT9fpXWmv1sQ72WCYgLXpSHTW0fKccgIJHA30kP/EgEm7U633 dGkcvNoQeLRpf+vip7DUz/hBG3YR6mCwCYEOdyNlkYTI8u3sKJoDy9SoPzF2FMqb PoQ1LGJY/2wGVy5e5CUq8Zpzc18/9VTcRSw50bV6vNCDrbjPaXoGeEFBYORLoxJ2 mdNmFhiUkyZZe65NMIg+Qy+xCqHETmFYvg41SKj2qo9sVruN4yFCiqUKiQ1yFxOM uOtWTcGNsSQst5nykrFNTvtmXN4BPx5KEzC0L6ckTpKsy7JG56p4QwRBCKS26Rok 4b4rcUF1JH4n7Gp+EJej/Xez1z3XBYJO/5/sdPkuXzrykt/qq7DxUViFPaCTEdfF lCIkqlmezCT/OVvepCm4 =pVgE -----END PGP SIGNATURE----- --Apple-Mail=_91D8F787-6B8B-45C4-94EA-54D49191EA94-- From internet-drafts@ietf.org Wed Jan 22 18:42:21 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F7F1A0370; Wed, 22 Jan 2014 18:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezf8PHFfk8w5; Wed, 22 Jan 2014 18:42:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F431A01D6; Wed, 22 Jan 2014 18:42:19 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123024219.29671.87597.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 18:42:19 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-lsn-deployment-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 02:42:21 -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 Working Gr= oup Working Group of the IETF. Title : CGN Deployment with BGP/MPLS IP VPNs Authors : Victor Kuarsingh John Cianfarani Filename : draft-ietf-opsawg-lsn-deployment-05.txt Pages : 21 Date : 2014-01-22 Abstract: 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). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. 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 the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs which allow for virtual routing separation helping ease the CGNs impact on the network. This document does not intend to defend the merits of CGN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-lsn-deployment-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jan 28 02:00:57 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0DE1A02D9; Tue, 28 Jan 2014 02:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Io-4shzz3zOG; Tue, 28 Jan 2014 02:00:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA10B1A011B; Tue, 28 Jan 2014 02:00:51 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140128100051.27724.32822.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2014 02:00:51 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-oam-overview-13.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 10:00:57 -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 Working Gr= oup Working Group of the IETF. Title : An Overview of Operations, Administration, and Ma= intenance (OAM) Tools Authors : Tal Mizrahi Nurit Sprecher Elisa Bellagamba Yaacov Weingarten Filename : draft-ietf-opsawg-oam-overview-13.txt Pages : 49 Date : 2014-01-28 Abstract: Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS for the transport profile (MPLS-TP), pseudowires, and TRILL. This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators and standard development organizations, and can be used as an index to some of the main OAM tools defined in the IETF. This document provides a brief description of each of the OAM tools in the IETF. At the end of the document a list of the OAM toolsets and a list of the OAM functions are presented as a summary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-oam-overview-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From talmi@marvell.com Tue Jan 28 02:06:54 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993111A0379 for ; Tue, 28 Jan 2014 02:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.756 X-Spam-Level: * X-Spam-Status: No, score=1.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LITTLE=1.555, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001, T_FRT_LITTLE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXzXAXeU9Zlj for ; Tue, 28 Jan 2014 02:06:23 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9656A1A0348 for ; Tue, 28 Jan 2014 02:06:22 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s0SA4Qw6020285; Tue, 28 Jan 2014 02:06:16 -0800 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1hknvxaksa-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jan 2014 02:06:14 -0800 Received: from YK-HUB01.marvell.com (10.4.102.51) by SC-OWA.marvell.com (10.93.76.28) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 28 Jan 2014 02:06:12 -0800 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB01.marvell.com ([10.4.102.51]) with mapi; Tue, 28 Jan 2014 12:06:07 +0200 From: Tal Mizrahi To: Thomas Nadeau Date: Tue, 28 Jan 2014 12:06:00 +0200 Thread-Topic: Updated draft-ietf-opsawg-oam-overview Thread-Index: Ac8V9H2mzmGx6kMlSxOh9QD65KYu7AF++Ztw Message-ID: <74470498B659FA4687F0B0018C19A89C01D43919C121@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9F93307@IL-MB01.marvell.com> <73851B1F-3FC5-4DBF-BD09-2C4DD74DF383@lucidvision.com> In-Reply-To: <73851B1F-3FC5-4DBF-BD09-2C4DD74DF383@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01D43919C121ILMB01marve_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-28_04:2014-01-27,2014-01-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401280019 Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Updated draft-ietf-opsawg-oam-overview X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 10:06:54 -0000 --_000_74470498B659FA4687F0B0018C19A89C01D43919C121ILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks for reviewing the draft and sending us your comments. Based on your comments we have updated the draft: http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13 We made an effort to address all the comments you sent. Please see our inline replies to your comments, marked by [TM]. Please let us know if you have further comments. Thanks, Tal. From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Monday, January 20, 2014 5:30 PM To: Tal Mizrahi Cc: opsawg@ietf.org; opsawg-chairs@tools.ietf.org; Carlos Pignataro (cpigna= ta); Alexander Vainshtein; Elwyn Davies; MORTON JR., ALFRED C (AL); Thomas = Narten; Sam Aldrin; Romascanu, Dan (Dan); joel jaeggli; Benoit Claise Subject: Re: Updated draft-ietf-opsawg-oam-overview Apologies but I just realized I hadn't reviewed this document post the= Vancouver IETF meeting when I was asked. My comments are included. I do no= t feel this document is ready to go forward as there are some major omissio= ns as noted below. --Tom I have reviewed this document. Comments inline start with TOM:. General comments are: 1) Psedowire OAM message mapping and ethernet OAM are missing. [TM] Point well taken. Notice the document includes the section "4.6.3. Att= achment Circuit - Pseudowire Mapping". Following your comment we added text= about Ethernet mapping and RFC 7023. 2) There is no discussion about OAM for L2VPN or L3VPN explicitly here. It = is important to explain this applicability. [TM] Point well taken. We have added brief descriptions about L2VPN and L3V= PN, since the focus of this document is OAM *tools*, and no new tools are d= efined in the context of L2VPN and L3VPN. We have added a new subsection, 4= .4.3., that discusses L2VPN and L3VPN in the context of MPLS. We have also = added text to section 4.6.3 about L2VPNs in the context of pseudowires. 3) BFD for MPLS is not explained. It is a very viable replacement for CV in= stead of LSP Ping. [TM] Point well taken. We have added a new subsection "4.4.2. BFD for MPLS"= . --Tom Operations and Management Area Working Group T. Mizrahi Internet Draft Marvell Intended status: Informational N. Sprecher Expires: July 2014 NSN E. Bellagamba Ericsson Y. Weingarten January 9, 2014 An Overview of Operations, Administration, and Maintenance (OAM) Tools draft-ietf-opsawg-oam-overview-12.txt Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS for the transport profile (MPLS-TP), pseudowires, and TRILL. This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators and standard development organizations, and can be used as an index to some of the main OAM tools defined in the IETF. This document provides a brief description of each of the OAM tools in the IETF. At the end of the document a list of the OAM toolsets and a list of the OAM functions are presented as a summary. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Mizrahi, et al. Expires July 9, 2014 [Page 1] Internet-Draft Overview of OAM Tools January 2014 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 4 1.1. Background .............................................. 4 1.2. Target Audience.......................................... 5 1.3. OAM-related Work in the IETF ............................ 5 1.4. Focusing on the Data Plane .............................. 6 2. Terminology .................................................. 7 2.1. Abbreviations ........................................... 7 2.2. Terminology used in OAM Standards ....................... 9 2.2.1. General Terms ...................................... 9 2.2.2. Operations, Administration and Maintenance ......... 9 2.2.3. Functions, Tools and Protocols .................... 10 2.2.4. Data Plane, Control Plane and Management Plane .... 10 2.2.5. The Players ....................................... 11 2.2.6. Proactive and On-demand Activation ................ 12 2.2.7. Connectivity Verification and Continuity Checks ... 12 2.2.8. Connection Oriented vs. Connectionless Communication13 2.2.9. Point-to-point vs. Point-to-multipoint Services ... 14 Mizrahi, et al. Expires July 9, 2014 [Page 2] Internet-Draft Overview of OAM Tools January 2014 2.2.10. Failures ......................................... 15 3. OAM Functions ............................................... 15 4. OAM Tools in the IETF - a Detailed Description .............. 16 4.1. IP Ping ................................................ 16 4.2. IP Traceroute .......................................... 17 4.3. Bidirectional Forwarding Detection (BFD) ............... 18 4.3.1. Overview .......................................... 18 4.3.2. Terminology ....................................... 18 4.3.3. BFD Control ....................................... 18 4.3.4. BFD Echo .......................................... 19 4.4. MPLS OAM ............................................... 19 4.5. MPLS-TP OAM ............................................ 20 4.5.1. Overview .......................................... 20 4.5.2. Terminology ....................................... 21 4.5.3. Generic Associated Channel ........................ 22 4.5.4. MPLS-TP OAM Toolset ............................... 23 4.5.4.1. Continuity Check and Connectivity Verification 23 4.5.4.2. Route Tracing ................................ 24 4.5.4.3. Lock Instruct ................................ 24 4.5.4.4. Lock Reporting ............................... 24 4.5.4.5. Alarm Reporting .............................. 24 4.5.4.6. Remote Defect Indication ..................... 24 4.5.4.7. Client Failure Indication .................... 25 4.5.4.8. Performance Monitoring ....................... 25 4.5.4.8.1. Packet Loss Measurement (LM) ............ 25 4.5.4.8.2. Packet Delay Measurement (DM) ........... 25 4.6. Pseudowire OAM ......................................... 26 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification (VCCV) ...................................... 26 4.6.2. Pseudowire OAM using G-ACh ........................ 27 4.6.3. Attachment Circuit - Pseudowire Mapping ........... 27 4.7. OWAMP and TWAMP......................................... 27 4.7.1. Overview .......................................... 27 4.7.2. Control and Test Protocols ........................ 28 4.7.3. OWAMP ............................................. 29 4.7.4. TWAMP ............................................. 29 4.8. TRILL .................................................. 30 5. Summary ..................................................... 30 5.1. Summary of OAM Tools ................................... 31 5.2. Summary of OAM Functions ............................... 33 5.3. Guidance to Network Equipment Vendors .................. 34 6. Security Considerations ..................................... 34 7. IANA Considerations ......................................... 34 8. Acknowledgments ............................................. 35 9. References .................................................. 35 9.1. Informative References ................................. 35 Appendix A. List of OAM Documents .............................. 40 Mizrahi, et al. Expires July 9, 2014 [Page 3] Internet-Draft Overview of OAM Tools January 2014 A.1. List of IETF OAM Documents ............................. 40 A.2. List of Selected Non-IETF OAM Documents ................ 45 1. Introduction OAM is a general term that refers to a toolset for detecting, isolating and reporting failures and for monitoring the network performance. There are several different interpretations to the "OAM" acronym. This document refers to Operations, Administration and Maintenance, as recommended in Section 3 of [OAM-Def]. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS for the transport profile (MPLS-TP), pseudowires, and TRILL. This document focuses on tools for detecting and isolating failures and for performance monitoring. Hence, this document focuses on the tools used for monitoring and measuring the data plane; control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. 1.1. Background OAM was originally used in traditional communication technologies such as E1 and T1, evolving into PDH and then later in SONET/SDH. ATM was probably the first technology to include inherent OAM support from day one, while in other technologies OAM was typically defined in an ad hoc manner after the technology was already defined and deployed. Packet-based networks were traditionally considered unreliable and best-effort, but as packet-based networks evolved, they have become the common transport for both data and telephony, replacing traditional transport protocols. Consequently, packet-based networks were expected to provide a similar "carrier grade" experience, and specifically to support OAM. As typical networks have a multi-layer architecture, the set of OAM protocols similarly take a multi-layer structure; each layer has its own OAM protocols. Moreover, OAM can be used at different levels of hierarchy in the network to form a multi-layer OAM solution, as shown in the example in Figure 1. Figure 1 illustrates a network in which IP traffic between two customer edges is transported over an MPLS provider network. MPLS OAM Mizrahi, et al. Expires July 9, 2014 [Page 4] Internet-Draft Overview of OAM Tools January 2014 is used at the provider-level for monitoring the connection between the two provider edges, while IP OAM is used at the customer-level for monitoring the end-to-end connection between the two customer edges. |<-------------- Customer-level OAM -------------->| IP OAM (Ping, Traceroute, OWAMP, TWAMP) |<- Provider-level OAM ->| MPLS OAM (LSP Ping) +-----+ +----+ +----+ +-----+ | | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D| | | | | |-------| | MPLS | |-------| | | | IP | | | | IP | | +-----+ +----+ +----+ +-----+ Customer Provider Provider Customer Edge Edge Edge Edge Figure 1 Example: Multi-layer OAM 1.2. Target Audience The target audience of this document includes: o Standard development organizations - both IETF working groups and non-IETF organizations can benefit from this document when designing new OAM protocols, or when looking to reuse existing OAM tools for new technologies. o Network equipment vendors and network operators - can use this document as an index to some of the common IETF OAM tools. It should be noted that this document is not necessarily suitable for beginners without any background in OAM. 1.3. OAM-related Work in the IETF This memo provides an overview of the different sets of OAM tools defined by the IETF. The set of OAM tools described in this memo are applicable to IP unicast, MPLS, pseudowires, MPLS for the transport profile (MPLS-TP), and TRILL. While OAM tools that are applicable to other technologies exist, they are beyond the scope of this memo. Mizrahi, et al. Expires July 9, 2014 [Page 5] Internet-Draft Overview of OAM Tools January 2014 This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM-related work is outside the scope. The IETF has defined OAM protocols and tools in several different contexts. We roughly categorize these efforts into a few sets of OAM- related RFCs, listed in Table 1. Each set defines a logically-coupled set of RFCs, although the sets are in some cases intertwined by common tools and protocols. The discussion in this document is ordered according to these sets. +--------------+------------+ | Toolset | Transport | | | Technology | +--------------+------------+ |IP Ping | IPv4/IPv6 | +--------------+------------+ |IP Traceroute | IPv4/IPv6 | +--------------+------------+ |BFD | generic | +--------------+------------+ |MPLS OAM | MPLS | +--------------+------------+ |MPLS-TP OAM | MPLS-TP | +--------------+------------+ |Pseudowire OAM| Pseudowires| +--------------+------------+ |OWAMP and | IPv4/IPv6 | |TWAMP | | +--------------+------------+ |TRILL OAM | TRILL | +--------------+------------+ Table 1 OAM Toolset Packages in the IETF Documents This document focuses on OAM tools that have been developed in the IETF. A short summary of some of the significant OAM standards that have been developed in other standard organizations is presented in Appendix A.2. 1.4. Focusing on the Data Plane OAM tools may, and quite often do, work in conjunction with a control plane and/or management plane. OAM provides instrumentation tools for measuring and monitoring the data plane. OAM tools often use Mizrahi, et al. Expires July 9, 2014 [Page 6] Internet-Draft Overview of OAM Tools January 2014 control plane functions, e.g., to initialize OAM sessions and to exchange various parameters. The OAM tools communicate with the management plane to raise alarms, and often OAM tools may be activated by the management (as well as by the control plane), e.g. to locate and localize problems. The considerations of the control plane maintenance tools and the functionality of the management plane are out of scope for this document, which concentrates on presenting the data plane tools that are used for OAM. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. Since OAM protocols are used for monitoring the data plane, it is imperative for OAM tools to be capable of testing the actual data plane in as much accuracy as possible. Thus, it is important to enforce fate-sharing between OAM traffic that monitors the data plane and the data plane traffic it monitors. 2. Terminology 2.1. Abbreviations ACH Associated Channel Header AIS Alarm Indication Signal ATM Asynchronous Transfer Mode BFD Bidirectional Forwarding Detection CC Continuity Check CV Connectivity Verification DM Delay Measurement ECMP Equal Cost Multiple Paths FEC Forwarding Equivalence Class FRR Fast Reroute G-ACh Generic Associated Channel GAL Generic Associated Label Mizrahi, et al. Expires July 9, 2014 [Page 7] Internet-Draft Overview of OAM Tools January 2014 ICMP Internet Control Message Protocol L2TP Layer Two Tunneling Protocol LCCE L2TP Control Connection Endpoint LDP Label Distribution Protocol LER Label Edge Router LM Loss Measurement LSP Label Switched Path LSR Label Switched Router ME Maintenance Entity MEG Maintenance Entity Group MEP MEG End Point MIP MEG Intermediate Point MP Maintenance Point MPLS Multiprotocol Label Switching MPLS-TP MPLS Transport Profile MTU Maximum Transmission Unit OAM Operations, Administration, and Maintenance OWAMP One-way Active Measurement Protocol PDH Plesiochronous Digital Hierarchy PE Provider Edge PW Pseudowire PWE3 Pseudowire Emulation Edge-to-Edge RBridge Routing Bridge RDI Remote Defect Indication Mizrahi, et al. Expires July 9, 2014 [Page 8] Internet-Draft Overview of OAM Tools January 2014 SDH Synchronous Digital Hierarchy SONET Synchronous Optical Networking TRILL Transparent Interconnection of Lots of Links TTL Time To Live TWAMP Two-way Active Measurement Protocol VCCV Virtual Circuit Connectivity Verification 2.2. Terminology used in OAM Standards 2.2.1. General Terms A wide variety of terms is used in various OAM standards. This section presents a comparison of the terms used in various OAM standards, without fully quoting the definition of each term. An interesting overview of the term OAM and its derivatives is presented in [OAM-Def]. A thesaurus of terminology for MPLS-TP terms is presented in [TP-Term], and provides a good summary of some of the OAM related terminology. 2.2.2. Operations, Administration and Maintenance The following definition of OAM is quoted from [OAM-Def]: The components of the "OAM" acronym (and provisioning) are defined as follows: o Operations - Operation activities are undertaken to keep the network (and the services that the network provides) up and running. It includes monitoring the network and finding problems. Ideally these problems should be found before users are affected. o Administration - Administration activities involve keeping track of resources in the network and how they are used. It includes all the bookkeeping that is necessary to track networking resources and the network under control. Mizrahi, et al. Expires July 9, 2014 [Page 9] Internet-Draft Overview of OAM Tools January 2014 o Maintenance - Maintenance activities are focused on facilitating repairs and upgrades -- for example, when equipment must be replaced, when a router needs a patch for an operating system image, or when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run more effectively, e.g., adjusting device configuration and parameters. 2.2.3. Functions, Tools and Protocols OAM Function An OAM function is an instrumentation measurement type or diagnostic. OAM functions are the atomic building blocks of OAM, where each function defines an OAM capability. Typical examples of OAM functions are presented in Section 3. OAM Protocol A protocol used for implementing one or more OAM functions. The OWAMP-Test [OWAMP] is an example of an OAM protocol. OAM Tool An OAM tool is a specific means of applying one or more OAM functions. In some cases an OAM protocol *is* an OAM tool, e.g., OWAMP-Test. In other cases an OAM tool uses a set of protocols that are not strictly OAM-related; for example, Traceroute (Section 4.2.) can be implemented using UDP and ICMP messages, without using an OAM protocol per se. 2.2.4. Data Plane, Control Plane and Management Plane Data Plane The data plane is the set of functions used to transfer data in the stratum or layer under consideration [ITU-Terms]. The Data Plane is also known as the Forwarding Plane or the User Plane. Mizrahi, et al. Expires July 9, 2014 [Page 10] Internet-Draft Overview of OAM Tools January 2014 Control Plane The control plane is the set of protocols and mechanisms that enable routers to efficiently learn how to forward packets towards their final destination (based on [Comp]). Management Plane The term Management Plane, as described in [Mng], is used to describe the exchange of management messages through management protocols (often transported by IP and by IP transport protocols) between management applications and the managed entities such as network nodes. Data Plane vs. Control Plane vs. Management Plane The distinction between the planes is at times a bit vague. For example, the definition of "Control Plane" above may imply that OAM tools such as ping, BFD and others are in fact in the control plane. This document focuses on tools used for monitoring the data plane. While these tools could arguably be considered to be in the control plane, these tools monitor the data plane, and hence it is imperative to have fate-sharing between OAM traffic that monitors the data plane and the data plane traffic it monitors. Another potentially vague distinction is between the management plane and control plane. The management plane should be seen as separate from, but possibly overlapping with, the control plane (based on [Mng]). 2.2.5. The Players An OAM tool is used between two (or more) "players". Various terms are used in IETF documents to refer to the players that take part in OAM. Table 2 summarizes the terms used in each of the toolsets discussed in this document. +--------------------------+--------------------------+ | Toolset | Terms | +--------------------------+--------------------------+ | Ping / Traceroute |-Host | | ([ICMPv4], [ICMPv6], |-Node | | [TCPIP-Tools]) |-Interface | | |-Gateway | Mizrahi, et al. Expires July 9, 2014 [Page 11] Internet-Draft Overview of OAM Tools January 2014 + ------------------------ + ------------------------ + | BFD [BFD] | System | + ------------------------ + ------------------------ + | MPLS OAM [MPLS-OAM-FW] | LSR | + ------------------------ + ------------------------ + | MPLS-TP OAM [TP-OAM-FW] |-End Point - MEP | | |-Intermediate Point - MIP | + ------------------------ + ------------------------ + | Pseudowire OAM [VCCV] |-PE | | |-LCCE | + ------------------------ + ------------------------ + | OWAMP and TWAMP |-Host | | ([OWAMP], [TWAMP]) |-End system | + ------------------------ + ------------------------ + | TRILL OAM [TRILL-OAM] |-RBridge | +--------------------------+--------------------------+ Table 2 Maintenance Point Terminology 2.2.6. Proactive and On-demand Activation The different OAM tools may be used in one of two basic types of activation: Proactive Proactive activation - indicates that the tool is activated on a continual basis, where messages are sent periodically, and errors are detected when a certain number of expected messages are not received. On-demand On-demand activation - indicates that the tool is activated "manually" to detect a specific anomaly. 2.2.7. 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. Continuity Check Mizrahi, et al. Expires July 9, 2014 [Page 12] Internet-Draft Overview of OAM Tools January 2014 Continuity checks are used to verify that a destination is reachable, and are typically sent proactively, though they can be invoked on- demand as well. Connectivity Verification A connectivity verification function allows Alice to check whether she is connected to Bob or not. It is noted that while the CV function is performed in the data plane, the "expected path" is predetermined either in the control plane or in the management plane. A connectivity verification (CV) protocol typically uses a CV message, followed by a CV reply that is sent back to the originator. A CV function can be applied proactively or on-demand. Connectivity Verification tools often perform path verification as well, allowing Alice to verify that messages from Bob are received through the correct path, thereby verifying not only that the two MPs are connected, but also that they are connected through the expected path, allowing detection of unexpected topology changes. Connectivity verification and continuity checks are considered complementary mechanisms, and are often used in conjunction with each other. 2.2.8. Connection Oriented vs. Connectionless Communication Connection Oriented In Connection Oriented technologies an end-to-end connection is established (by a control protocol or provisioned by a management system) prior to the transmission of data. Typically a connection identifier is used to identify the connection. In connection oriented technologies it is often the case (although not always) that all packets belonging to a specific connection use the same route through the network. Connectionless In Connectionless technologies data is typically sent between end points without prior arrangement. Packets are routed independently based on their destination address, and hence different packets may be routed in a different way across the network. Discussion Mizrahi, et al. Expires July 9, 2014 [Page 13] Internet-Draft Overview of OAM Tools January 2014 The OAM tools described in this document include tools that support connection oriented technologies, as well as tools for connectionless technologies. In connection oriented technologies OAM is used to monitor a *specific* connection; OAM packets are forwarded through the same route as the data traffic and receive the same treatment. In connectionless technologies, OAM is used between a source and destination pair without defining a specific connection. Moreover, in some cases the route of OAM packets may differ from the one of the data traffic. For example, the connectionless IP Ping (Section 4.1.) tests the reachability from a source to a given destination, while the connection oriented LSP Ping (Section 4.4.) is used for monitoring a specific LSP (connection), and provides the capability to monitor all the available paths used by an LSP. It should be noted that in some cases connectionless protocols are monitored by connection oriented OAM protocols. For example, while IP is a connectionless protocol, it can monitored by BFD (Section 4.3. ), which is connection oriented. 2.2.9. Point-to-point vs. Point-to-multipoint Services Point-to-point (P2P) A P2P service delivers data from a single source to a single destination. Point-to-multipoint (P2MP) A P2MP service delivers data from a single source to a one or more destinations (based on [Signal]). An MP2MP service is a service that delivers data from more than one source to one or more receivers (based on [Signal]). Note: the two definitions for P2MP and MP2MP are quoted from [Signal]. Although [Signal] describes a specific case of P2MP and MP2MP which is MPLS-specific, these two definitions also apply to non-MPLS cases. Discussion The OAM tools described in this document include tools for P2P services, as well as tools for P2MP services. Mizrahi, et al. Expires July 9, 2014 [Page 14] Internet-Draft Overview of OAM Tools January 2014 The distinction between P2P services and P2MP services affects the corresponding OAM tools. A P2P service is typically simpler to monitor, as it consists of a single pair of end points. P2MP services present several challenges. For example, in a P2MP service, the OAM mechanism not only verifies that each of the destinations is reachable from the source, but also verifies that the P2MP distribution tree is intact and loop-free. 2.2.10. Failures The terms Failure, Fault, and Defect are used interchangeably in the standards, referring to a malfunction that can be detected by a connectivity or a continuity check. In some standards, such as 802.1ag [IEEE802.1Q] , there is no distinction between these terms, while in other standards each of these terms refers to a different type of malfunction. The terminology used in IETF MPLS-TP OAM is based on the ITU-T terminology, which distinguishes between these three terms in [ITU-T-G.806]; Fault The term Fault refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. Defect The term Defect refers to an interruption in the normal operation, such as a consecutive period of time where no packets are delivered successfully. Failure The term Failure refers to the termination of the required function. While a Defect typically refers to a limited period of time, a failure refers to a long period of time. 3. OAM Functions This subsection provides a brief summary of the common OAM functions used in OAM-related standards. These functions are used as building blocks in the OAM standards described in this document. o Connectivity Verification (CV), Path Verification and Continuity Checks (CC): As defined in Section 2.2.7. Mizrahi, et al. Expires July 9, 2014 [Page 15] Internet-Draft Overview of OAM Tools January 2014 o Path Discovery / Fault Localization: This function can be used to trace the route to a destination, i.e., to identify the nodes along the route to the destination. When more than one route is available to a specific destination, this function traces one of the available routes. When a failure occurs, this function also allows to detect the location of the failure. Note that the term route tracing (or Traceroute) that is used in the context of IP and MPLS, is sometimes referred to as path tracing in the context of other protocols, such as TRILL. o Performance Monitoring: Typically refers to: o Loss Measurement (LM) - monitors the packet loss rate. o Delay Measurement (DM) - monitors the delay and delay variation. 4. OAM Tools in the IETF - a Detailed Description This section presents a detailed description of the sets of OAM- related tools in each of the toolsets in Table 1. 4.1. IP Ping Ping is a common network diagnosis application for IP networks that uses ICMP. According to [NetTerms], 'Ping' is an abbreviation for Packet internet groper, although the term has been so commonly used that it stands on its own. As defined in [NetTerms], it is a program used to test reachability of destinations by sending them an ICMP echo request and waiting for a reply. The ICMP Echo request/reply exchange in Ping is used as a continuity check function for the Internet Protocol. The originator transmits an ICMP Echo request packet, and the receiver replies with an Echo reply. ICMP ping is defined in two variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6. Ping implementations typically use ICMP messages. UDP Ping is a variant that uses UDP messages instead of ICMP echo messages. Ping is a single-ended continuity check, i.e., it allows the *initiator* of the Echo request to test the reachability. If it is desirable for both ends to test the reachability, both ends have to invoke Ping independently. Mizrahi, et al. Expires July 9, 2014 [Page 16] Internet-Draft Overview of OAM Tools January 2014 Note that since ICMP filtering is deployed in some routers and firewalls, the usefulness of Ping is sometimes limited in the wider internet. This limitation is equally relevant to Traceroute. 4.2. IP Traceroute Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to discover a path between an IP source and an IP destination. The most common way to implement Traceroute [TCPIP-Tools] is described as follows. Traceroute sends a sequence of UDP packets to UDP port 33434 at the destination. By default, Traceroute begins by sending three packets (the number of packets is configurable in most Traceroute implementations), each with an IP Time-To-Live (or Hop Limit in IPv6) value of one to the destination. These packets expire as soon as they reach the first router in the path. Consequently, that router sends three ICMP Time Exceeded Messages back to the Traceroute application. Traceroute now sends another three UDP packets, each with the TTL value of 2. These messages cause the second router to return ICMP messages. This process continues, with ever increasing values for the TTL field, until the packets actually reach the destination. Because no application listens to port 33434 at the destination, the destination returns ICMP Destination Unreachable Messages indicating an unreachable port. This event indicates to the Traceroute application that it is finished. The Traceroute program displays the round-trip delay associated with each of the attempts. While Traceroute is a tool that finds *a* path from A to B, it should be noted that traffic from A to B is often forwarded through Equal Cost Multiple Paths (ECMP). Paris Traceroute [PARIS] is an extension to Traceroute that attempts to discovers all the available paths from A to B by scanning different values of header fields (such as UDP ports) in the probe packets. It is noted that Traceroute is an application, and not a protocol. As such, it has various different implementations. One of the most common ones uses UDP probe packets, as described above. Other implementations exist that use other types of probe messages, such as ICMP or TCP. Note that IP routing may be asymmetric. While Traceroute discovers a path between a source and destination, it does not reveal the reverse path. A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in the context of Traceroute. These documents define several extensions, Mizrahi, et al. Expires July 9, 2014 [Page 17] Internet-Draft Overview of OAM Tools January 2014 including extensions to the ICMP Destination Unreachable message, that can be used by Traceroute applications. 4.3. Bidirectional Forwarding Detection (BFD) 4.3.1. Overview While multiple OAM tools have been defined for various protocols in the protocol stack, Bidirectional Forwarding Detection [BFD], defined by the IETF BFD working group, is a generic OAM tool that can be deployed over various encapsulating protocols, and in various medium types. The IETF has defined variants of the protocol for IP ([BFD- IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires [BFD- VCCV]. The usage of BFD in MPLS-TP is defined in [TP-CC-CV]. BFD includes two main OAM functions, using two types of BFD packets: BFD Control packets, and BFD Echo packets. 4.3.2. Terminology BFD operates between *systems*. The BFD protocol is run between two or more systems after establishing a *session*. 4.3.3. BFD Control BFD supports a bidirectional continuity check, using BFD control packets, that are exchanged within a BFD session. BFD sessions operate in one of two modes: o Asynchronous mode (i.e. proactive): in this mode BFD control packets are sent periodically. When the receiver detects that no BFD control packets have been received during a predetermined period of time, a failure is detected. o Demand mode: in this mode, BFD control packets are sent on-demand. Upon need, a system initiates a series of BFD control packets to check the continuity of the session. BFD control packets are sent independently in each direction. Each of the end-points (referred to as systems) of the monitored path maintains its own session identification, called a Discriminator, both of which are included in the BFD Control Packets that are exchanged between the end-points. At the time of session establishment, the Discriminators are exchanged between the two-end points. In addition, the transmission (and reception) rate is negotiated between the two end-points, based on information included Mizrahi, et al. Expires July 9, 2014 [Page 18] Internet-Draft Overview of OAM Tools January 2014 in the control packets. These transmission rates may be renegotiated during the session. During normal operation of the session, i.e. no failures are detected, the BFD session is in the Up state. If no BFD Control packets are received during a period of time called the Detection Time, the session is declared to be Down. The detection time is a function of the pre-configured or negotiated transmission time, and a parameter called Detect Mult. Detect Mult determines the number of missing BFD Control packets that cause the session to be declared as Down. This parameter is included in the BFD Control packet. 4.3.4. BFD Echo A BFD echo packet is sent to a peer system, and is looped back to the originator. The echo function can be used proactively, or on-demand. The BFD echo function has been defined in BFD for IPv4 and IPv6 ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for MPLS-TP. 4.4. MPLS OAM The IETF MPLS working group has defined OAM for MPLS LSPs. The requirements and framework of this effort are defined in [MPLS-OAM-FW] and [MPLS-OAM], respectively. The corresponding OAM tool defined, in this context, is LSP Ping [LSP-Ping]. OAM for P2MP services is defined in [MPLS-P2MP]. LSP Ping is modeled after the Ping/Traceroute paradigm and thus it may be used in one of two modes: o "Ping" mode: In this mode LSP Ping is used for end-to-end connectivity verification between two LERs. o "Traceroute" mode: This mode is used for hop-by-hop fault isolation. LSP Ping extends the basic ICMP Ping operation (of data-plane connectivity verification) with functionality to verify data-plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC) and also Maximum Transmission Unit (MTU) problems. TOM: This is misleading. LSP Ping does not extend any part of ICMP operatio= n; its a completely new operation that is native to MPLS. It is important = not to conflate these two things, as there are proprietary versions of ICMP= ping extended for MPLS that DO NOT work in all cases. This is why LSP Ping= was invented (and trace). [TM] Point well taken. Rephrased. The Traceroute functionality may be used to isolate and localize the MPLS faults, using the Time-to-live (TTL) indicator to incrementally identify the sub-path of the LSP that is successfully traversed before the faulty link or node. TOM: There is more to the LSP Traceroute than just using TTL. Please review= the RFC for details. [TM] Our challenge in this overview document is to try to capture some of t= he most significant content of each of the RFCs we mention. Indeed, an over= view document cannot (and should not) include all the details about all the= topics it covers. This is just an example where, as you mention, there is = more to the protocol than is currently described, and we believe that it is= quite reasonable that we do not cover the entire RFC. However, if you beli= eve there is a significant point that is currently missing in the text, it = would be great if you could explain what you are referring to. Mizrahi, et al. Expires July 9, 2014 [Page 19] Internet-Draft Overview of OAM Tools January 2014 The challenge in MPLS networks is that the traffic of a given LSP may be load balanced across Equal Cost Multiple paths (ECMP). LSP Ping monitors all the available paths of an LSP by monitoring its different Forwarding Equivalence Classes (FEC). Conversely, MPLS-TP does not use ECMP, and thus does not require OAM over multiple paths. TOM: Why "conversely"? You imply that MPLS-TP is "better" somehow with tha= t statement; its different. [TM] We by no means implied that MPLS-TP is better. In fact, we believe tha= t all MPLS variants are created equal. :) The sentence was rephrased. Another challenge is that an MPLS LSP does not necessarily have a return path, and thus responding to an LSP Ping message is not TOM: Strictily speaking, an LSP does not have a return path. There is a ret= urn route at the other end that is used to return the response message. Thi= s can be a different MPLS LSP, IP or whatever. [TM] Point well taken. Rephrased. necessarily as trivial as in IP Ping, where the responder just swaps the source and destination IP addresses. Note that this challenge is not applicable to MPLS-TP, where a return path is always available. It should be noted that LSP Ping supports unique identification of the LSP within an addressing domain. The identification is checked using the full FEC identification. LSP Ping is easily extensible to include additional information needed to support new functionality, by use of Type-Length-Value (TLV) constructs. The usage of TLVs is typically not easy to perform in hardware, and is thus typically handled by the control plane. LSP Ping supports both asynchronous, as well as, on-demand activation. 4.5. MPLS-TP OAM 4.5.1. Overview The MPLS working group has defined the OAM toolset that fulfills the requirements for MPLS-TP OAM. The full set of requirements for MPLS- TP OAM are defined in [MPLS-TP-OAM], and include both general requirements for the behavior of the OAM tools and a set of operations that should be supported by the OAM toolset. The set of mechanisms required are further elaborated in [TP-OAM-FW], which describes the general architecture of the OAM system as well as giving overviews of the functionality of the OAM toolset. Some of the basic requirements for the OAM toolset for MPLS-TP are: o MPLS-TP OAM must be able to support both an IP based and non-IP based environment. If the network is IP based, i.e. IP routing and forwarding are available, then the MPLS-TP OAM toolset should rely on the IP routing and forwarding capabilities. On the other hand, in environments where IP functionality is not available, the OAM tools must still be able to operate without dependence on IP forwarding and routing. Mizrahi, et al. Expires July 9, 2014 [Page 20] Internet-Draft Overview of OAM Tools January 2014 o OAM packets and the user traffic are required to be congruent (i.e. OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from data plane ones. Inherent in this requirement is the principle that MPLS-TP OAM be independent of any existing control-plane, although it should not preclude use of the control-plane functionality. OAM packets are identified by the Generic Associated Label (GAL), which is a reserved MPLS label value (13). 4.5.2. Terminology Maintenance Entity (ME) The MPLS-TP OAM tools are designed to monitor and manage a Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a relationship between two points of a transport path to which maintenance and monitoring operations apply. The term Maintenance Entity (ME) is used in ITU-T Recommendations (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology ([TP-OAM-FW]). Maintenance Entity Group (MEG) The collection of one or more MEs that belongs to the same transport path and that are maintained and monitored as a group are known as a Maintenance Entity Group (based on [TP-OAM-FW]). Maintenance Point (MP) A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and can initiate and/or react to OAM messages. This document focuses on the data-plane functionality of MPs, while MPs interact with the control plane and with the management plane as well. The term MP is used in IEEE 802.1ag, and was similarly adopted in MPLS-TP ([TP-OAM-FW]). Maintenance End Point (MEP) A Maintenance End Point (MEP) is one of the end points of an ME, and can initiate OAM messages and respond to them (based on [TP-OAM-FW]). Maintenance Intermediate Point (MIP) Mizrahi, et al. Expires July 9, 2014 [Page 21] Internet-Draft Overview of OAM Tools January 2014 In between MEPs, there are zero or more intermediate points, called Maintenance Entity Group Intermediate Points (based on [TP-OAM-FW]). A Maintenance Intermediate Point (MIP) is an intermediate point that does not generally initiate OAM frames (one exception to this is the use of AIS notifications), but is able to respond to OAM frames that are destined to it. A MIP in MPLS-TP identifies OAM packets destined to it by the value of the TTL field in the OAM packet. The term Maintenance Point is a general term for MEPs and MIPs. Up and Down MEPs The IEEE 802.1ag [IEEE802.1Q] defines a distinction between Up MEPs and Down MEPs. A MEP is a bridge interface that is monitored by an OAM protocol either in the direction facing the network, or in the direction facing the bridge. A Down MEP is a MEP that receives OAM packets from, and transmits them to the direction of the network. An Up MEP receives OAM packets from, and transmits them to the direction of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the MEP - either at the ingress, egress, or forwarding function of the node (Down / Up MEPs). This placement is important for localization of a failure. The distinction between Up and Down MEPs was defined in [TP-OAM-FW], but has not been used in other MPLS-TP RFCs, as of the writing of this document. 4.5.3. Generic Associated Channel In order to address the requirement for in-band transmission of MPLS- TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based on the same concepts as the PWE3 ACH and VCCV mechanisms. However, to address the needs of LSPs as differentiated from PW, the following concepts were defined for [G-ACh]: o An Associated Channel Header (ACH), that uses a format similar to the PW Control Word, is a 4-byte header that is prepended to OAM packets. o A Generic Associated Label (GAL). The GAL is a reserved MPLS label value (13) that indicates that the packet is an ACH packet and the payload follows immediately after the label stack. It should be noted that while the G-ACh was defined as part of the MPLS-TP definition effort, the G-ACh is a generic tool that can be used in MPLS in general, and not only in MPLS-TP. Mizrahi, et al. Expires July 9, 2014 [Page 22] Internet-Draft Overview of OAM Tools January 2014 4.5.4. MPLS-TP OAM Toolset To address the functionality that is required of the OAM toolset, the MPLS WG conducted an analysis of the existing IETF and ITU-T OAM tools and their ability to fulfill the required functionality. The conclusions of this analysis are documented in [OAM-Analys]. The MPLS working group currently plans to use a mixture of OAM tools that are based on various existing standards, and adapt them to the requirements of [MPLS-TP-OAM]. Some of the main building blocks of this solution are based on: o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for proactive continuity check and connectivity verification. o LSP Ping as defined in [LSP-Ping] for on-demand connectivity verification. o New protocol packets, using G-ACH, to address different functionality. o Performance measurement protocols that are based on the functionality that is described in [ITU-T-Y1731]. The following sub-sections describe the OAM tools defined for MPLS-TP as described in [TP-OAM-FW]. 4.5.4.1. Continuity Check and Connectivity Verification Continuity Check and Connectivity Verification are presented in Section 2.2.7. of this document. As presented there, these tools may be used either proactively or on-demand. When using these tools proactively, they are generally used in tandem. For MPLS-TP there are two distinct tools, the proactive tool is defined in [TP-CC-CV] while the on-demand tool is defined in [OnDemand-CV]. In on-demand mode, this function should support monitoring between the MEPs and, in addition, between a MEP and MIP. [TP-OAM-FW] highlights, when performing Connectivity Verification, the need for the CC-V messages to include unique identification of the MEG that is being monitored and the MEP that originated the message. The proactive tool [TP-CC-CV] is based on extensions to BFD (see Section 4.3.) with the additional limitation that the transmission and receiving rates are based on configuration by the operator. The on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see Section 4.4.) for the required behavior of MPLS-TP. Mizrahi, et al. Expires July 9, 2014 [Page 23] Internet-Draft Overview of OAM Tools January 2014 4.5.4.2. Route Tracing [MPLS-TP-OAM] defines that there is a need for functionality that would allow a path end-point to identify the intermediate and end- points of the path. This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP, and sections, however, unidirectional paths may be supported only if a return path exists. The tool for this is based on the LSP Ping (see Section 4.4.) functionality and is described in [OnDemand-CV]. 4.5.4.3. Lock Instruct The Lock Instruct function [Lock-Loop] is used to notify a transport path end-point of an administrative need to disable the transport path. This functionality will generally be used in conjunction with some intrusive OAM function, e.g. Performance measurement, Diagnostic testing, to minimize the side-effect on user data traffic. 4.5.4.4. Lock Reporting Lock Reporting is a function used by an end-point of a path to report to its far-end end-point that a lock condition has been affected on the path. 4.5.4.5. Alarm Reporting Alarm Reporting [TP-Fault] provides the means to suppress alarms following detection of defect conditions at the server sub-layer. Alarm reporting is used by an intermediate point of a path, that becomes aware of a fault on the path, to report to the end-points of the path. [TP-OAM-FW] states that this may occur as a result of a defect condition discovered at a server sub-layer. This generates an Alarm Indication Signal (AIS) that continues until the fault is cleared. The consequent action of this function is detailed in [TP-OAM-FW]. 4.5.4.6. Remote Defect Indication Remote Defect Indication (RDI) is used proactively by a path end- point to report to its peer end-point that a defect is detected on a bidirectional connection between them. [MPLS-TP-OAM] points out that this function may be applied to a unidirectional LSP only if there a return path exists. [TP-OAM-FW] points out that this function is associated with the proactive CC-V function. Mizrahi, et al. Expires July 9, 2014 [Page 24] Internet-Draft Overview of OAM Tools January 2014 4.5.4.7. Client Failure Indication Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow the propagation information from one edge of the network to the other. The information concerns a defect to a client, in the case that the client does not support alarm notification. 4.5.4.8. Performance Monitoring The definition of MPLS performance monitoring was motivated by the MPLS-TP requirements [MPLS-TP-OAM], but was defined generically for MPLS in [MPLS-LM-DM]. An additional document [TP-LM-DM] defines a performance monitoring profile for MPLS-TP. 4.5.4.8.1. Packet Loss Measurement (LM) Packet Loss Measurement is a function used to verify the quality of the service. Packet loss, as defined in [IPPM-1LM] and [MPLS-TP-OAM], indicates the ratio of the number of user packets lost to the total number of user packets sent during a defined time interval. There are two possible ways of determining this measurement: o Using OAM packets, it is possible to compute the statistics based on a series of OAM packets. This, however, has the disadvantage of being artificial, and may not be representative since part of the packet loss may be dependent upon packet sizes and upon the implementation of the MEPs that take part in the protocol. o Sending delimiting messages for the start and end of a measurement period during which the source and sink of the path count the packets transmitted and received. After the end delimiter, the ratio would be calculated by the path OAM entity. 4.5.4.8.2. Packet Delay Measurement (DM) Packet Delay Measurement is a function that is used to measure one- way or two-way delay of a packet transmission between a pair of the end-points of a path (PW, LSP, or Section). Where: o One-way packet delay, as defined in [IPPM-1DM], is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of that packet by the destination node. Note that one-way delay measurement requires the clocks of the two end-points to be synchronized. Mizrahi, et al. Expires July 9, 2014 [Page 25] Internet-Draft Overview of OAM Tools January 2014 o Two-way packet delay, as defined in [IPPM-2DM], is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop-backed packet by the same source node, when the loopback is performed at the packet's destination node. Note that due to possible path asymmetry, the one-way packet delay from one end- point to another is not necessarily equal to half of the two-way packet delay. As opposed to one-way delay measurement, two-way delay measurement does not require the two end-points to be synchronized. For each of these two metrics, the DM function allows the MEP to measure the delay, as well as the delay variation. Delay measurement is performed by exchanging timestamped OAM packets between the participating MEPs. 4.6. Pseudowire OAM 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification (VCCV) VCCV, as defined in [VCCV], provides a means for end-to-end fault detection and diagnostics tools to be extended for PWs (regardless of TOM: Why "to be extended"? They've already been extended. [TM] In this context "to be extended" was not intended to refer to the futu= re. Rephrased. the underlying tunneling technology). The VCCV switching function provides a control channel associated with each PW. [VCCV] defines three Control Channel (CC) types, i.e., three possible methods for transmitting and identifying OAM messages: o CC Type 1: In-band VCCV, as described in [VCCV], is also referred to as "PWE3 Control Word with 0001b as first nibble". It uses the PW Associated Channel Header [PW-ACH]. o CC Type 2: Out-of-band VCCV [VCCV], is also referred to as "MPLS Router Alert Label". In this case the control channel is created by using the MPLS router alert label [MPLS-ENCAPS] immediately above the PW label. o CC Type 3: TTL expiry VCCV [VCCV], is also referred to as "MPLS PW Label with TTL =3D=3D 1", i.e., the control channel is identified whe= n the value of the TTL field in the PW label is set to 1. VCCV currently supports the following OAM tools: ICMP Ping, LSP Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of encapsulation - either IP/UDP encapsulated (with IP/UDP header) or PW-ACH encapsulated (with no IP/UDP header) and provides support to signal the AC status. The use of the VCCV control channel provides Mizrahi, et al. Expires July 9, 2014 [Page 26] Internet-Draft Overview of OAM Tools January 2014 the context, based on the MPLS-PW label, required to bind and bootstrap the BFD session to a particular pseudo wire (FEC), eliminating the need to exchange Discriminator values. VCCV consists of two components: (1) signaled component to communicate VCCV capabilities as part of VC label, and (2) switching component to cause the PW payload to be treated as a control packet. VCCV is not directly dependent upon the presence of a control plane. The VCCV capability negotiation may be performed as part of the PW TOM: There is not really a capability "negotiation" per se; its a capabilit= y advertisement with strict and explicit rules for what each end should do = when it receives capability advertisements. [TM] Point well taken. Rephrased. signaling when LDP is used. In case of manual configuration of the PW, it is the responsibility of the operator to set consistent options at both ends. The manual option was created specifically to handle MPLS-TP use cases where no control plane was a requirement. However, new use cases such as pure mobile backhaul find this functionality useful too. The PWE3 working group has conducted an implementation survey of VCCV [VCCV-SURVEY], which analyzes which VCCV mechanisms are used in practice. 4.6.2. Pseudowire OAM using G-ACh As mentioned above, VCCV enables OAM for PWs by using a control channel for OAM packets. When PWs are used in MPLS-TP networks, rather than the control channels defined in VCCV, the G-ACh can be used as an alternative control channel. The usage of the G-ACh for PWs is defined in [PW-G-ACh]. 4.6.3. Attachment Circuit - Pseudowire Mapping The PWE3 working group has defined a mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. This mapping is of key importance to the end-to-end functionality. Specifically, the mapping is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and Section 5.3 of [ATM-L2] for ATM. 4.7. OWAMP and TWAMP 4.7.1. Overview The IPPM working group in the IETF defines common criteria and metrics for measuring performance of IP traffic ([IPPM-FW]). Some of the key RFCs published by this working group have defined metrics for measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), and packet loss [IPPM-1LM]. It should be noted that the work of the Mizrahi, et al. Expires July 9, 2014 [Page 27] Internet-Draft Overview of OAM Tools January 2014 IETF in the context of performance metrics is not limited to IP networks; [PM-CONS] presents general guidelines for considering new performance metrics. The IPPM working group has defined not only metrics for performance measurement, but also protocols that define how the measurement is carried out. The One-way Active Measurement Protocol [OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] define a method and protocol for measuring performance metrics in IP networks. OWAMP [OWAMP] enables measurement of one-way characteristics of IP networks, such as one-way packet loss and one-way delay. For its proper operation OWAMP requires accurate time of day setting at its end points. TWAMP [TWAMP] is a similar protocol that enables measurement of both one-way and two-way (round trip) characteristics. OWAMP and TWAMP are both comprised of two separate protocols: o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop test sessions and to fetch their results. Continuity Check and Connectivity Verification are tested and confirmed by establishing the OWAMP/TWAMP Control Protocol TCP connection. o OWAMP-Test/TWAMP-Test: used to exchange test packets between two measurement nodes. Enables the loss and delay measurement functions, as well as detection of other anomalies, such as packet duplication and packet reordering. It should be noted that while [OWAMP] and [TWAMP] define tools for performance measurement, they do not define the accuracy of these tools. The accuracy depends on scale, implementation and network configurations. Alternative protocols for performance monitoring are defined, for example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet OAM [ITU-T-Y1731]. 4.7.2. Control and Test Protocols OWAMP and TWAMP control protocols run over TCP, while the test protocols run over UDP. The purpose of the control protocols is to initiate, start, and stop test sessions, and for OWAMP to fetch results. The test protocols introduce test packets (which contain sequence numbers and timestamps) along the IP path under test according to a schedule, and record statistics of packet arrival. Mizrahi, et al. Expires July 9, 2014 [Page 28] Internet-Draft Overview of OAM Tools January 2014 Multiple sessions may be simultaneously defined, each with a session identifier, and defining the number of packets to be sent, the amount of padding to be added (and thus the packet size), the start time, and the send schedule (which can be either a constant time between test packets or exponentially distributed pseudo-random). Statistics recorded conform to the relevant IPPM RFCs. OWAMP and TWAMP test traffic is designed with security in mind. Test packets are hard to detect because they are simply UDP streams between negotiated port numbers, with potentially nothing static in the packets. OWAMP and TWAMP also include optional authentication and encryption for both control and test packets. 4.7.3. OWAMP OWAMP defines the following logical roles: Session-Sender, Session- Receiver, Server, Control-Client, and Fetch-Client. The Session- Sender originates test traffic that is received by the Session- Receiver. The Server configures and manages the session, as well as returning the results. The Control-Client initiates requests for test sessions, triggers their start, and may trigger their termination. The Fetch-Client requests the results of a completed session. Multiple roles may be combined in a single host - for example, one host may play the roles of Control-Client, Fetch-Client, and Session-Sender, and a second playing the roles of Server and Session-Receiver. In a typical OWAMP session the Control-Client establishes a TCP connection to port 861 of the Server, which responds with a server greeting message indicating supported security/integrity modes. The Control-Client responds with the chosen communications mode and the Server accepts the modes. The Control-Client then requests and fully describes a test session to which the Server responds with its acceptance and supporting information. More than one test session may be requested with additional messages. The Control-Client then starts a test session and the Server acknowledges. The Session- Sender then sends test packets with pseudorandom padding to the Session-Receiver until the session is complete or until the Control- client stops the session. Once finished, the Fetch-Client sends a fetch request to the server, which responds with an acknowledgement and immediately thereafter the result data. 4.7.4. TWAMP TWAMP defines the following logical roles: session-sender, session- reflector, server, and control-client. These are similar to the Mizrahi, et al. Expires July 9, 2014 [Page 29] Internet-Draft Overview of OAM Tools January 2014 OWAMP roles, except that the Session-Reflector does not collect any packet information, and there is no need for a Fetch-Client. In a typical TWAMP session the Control-Client establishes a TCP connection to port 862 of the Server, and mode is negotiated as in OWAMP. The Control-Client then requests sessions and starts them. The Session-Sender sends test packets with pseudorandom padding to the Session-Reflector which returns them with insertion of timestamps. 4.8. TRILL The requirements of OAM in TRILL are defined in [TRILL-OAM]. The challenge in TRILL OAM, much like in MPLS networks, is that traffic between RBridges RB1 and RB2 may be forwarded through more than one path. Thus, an OAM protocol between RBridges RB1 and RB2 must be able to monitor all the available paths between the two RBridge. During the writing of this document the detailed definition of the TRILL OAM tools are still work in progress. This subsection presents the main requirements of TRILL OAM. The main requirements defined in [TRILL-OAM] are: o Continuity Checking (CC) - the TRILL OAM protocol must support a function for CC between any two RBridges RB1 and RB2. o Connectivity Verification (CV) - connectivity between two RBridges RB1 and RB2 can be verified on a per-flow basis. o Path Tracing - allows an RBridge to trace all the available paths to a peer RBridge. o Performance monitoring - allows an RBridge to monitor the packet loss and packet delay to a peer RBridge. 5. Summary This section summarizes the OAM tools and functions presented in this document. This summary is an index to some of the main OAM tools defined in the IETF. This compact index that can be useful to all readers from network operators to standard development organizations. The summary includes a short subsection that presents some guidance to network equipment vendors. Mizrahi, et al. Expires July 9, 2014 [Page 30] Internet-Draft Overview of OAM Tools January 2014 5.1. Summary of OAM Tools This subsection provides a short summary of each of the OAM toolsets described in this document. A detailed list of the RFCs related to each toolset is given in Appendix A.1. +-----------+------------------------------------------+------------+ | Toolset | Description | Transport | | | | Technology | +-----------+------------------------------------------+------------+ |IP Ping | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6 | | | application for testing reachability that| | | | uses ICMP Echo messages ([ICMPv4], | | | | [ICMPv6]). | | +-----------+------------------------------------------+------------+ |IP | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 | |Traceroute | an application that allows users to trace| | | | the path between an IP source and an IP | | | | destination, i.e., to identify the nodes | | | | along the path. If more than one path | | | | exists between the source and destination| | | | Traceroute traces *a* path. The most | | | | common implementation of Traceroute | | | | uses UDP probe messages, although there | | | | are other implementations that use | | | | different probes, such as ICMP or TCP. | | +-----------+------------------------------------------+------------+ |BFD | Bidirectional Forwarding Detection (BFD) | generic | | | is defined in [BFD] as a framework for a | | | | lightweight generic OAM tool. The | | | | intention is to define a base tool | | | | that can be used with various | | | | encapsulation types, network | | | | environments, and in various medium | | | | types. | | +-----------+------------------------------------------+------------+ |MPLS OAM | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS | | | [MPLS-OAM-FW] and [LSP-Ping], is an OAM | | | | tool for point-to-point and | | | | point-to-multipoint MLPS LSPs. | | Mizrahi, et al. Expires July 9, 2014 [Page 31] Internet-Draft Overview of OAM Tools January 2014 | | It includes two main functions: Ping and | | | | Traceroute. | | | | It is noted that while this category | | | | focuses on LSP Ping, other OAM tools | | | | can be used in MPLS networks, e.g., BFD. | | +-----------+------------------------------------------+------------+ |MPLS-TP OAM| MPLS-TP OAM is defined in a set of RFCs. | MPLS-TP | | | The OAM requirements for MPLS Transport | | | | Profile (MPLS-TP) are defined in | | | | [MPLS-TP-OAM]. Each of the tools in the | | | | OAM toolset is defined in its own RFC, as| | | | specified in Section A.1. | | +-----------+------------------------------------------+------------+ |Pseudowire | The PWE3 OAM architecture defines control| Pseudowire | |OAM | channels that support the use of existing| | | | IETF OAM tools to be used for a pseudo- | | | | wire (PW). The control channels that are| | | | defined in [VCCV] and [PW-G-ACh] may be | | | | used in conjunction with ICMP Ping, LSP | | | | Ping, and BFD to perform CC and CV | | | | functionality. In addition the channels | | | | support use of any of the MPLS-TP based | | | | OAM tools for completing their respective| | | | OAM functionality for a PW. | | +-----------+------------------------------------------+------------+ |OWAMP and | The One Way Active Measurement Protocol | IPv4/IPv6 | |TWAMP | (OWAMP) and the Two Way Active Measure- | | | | ment Protocols (TWAMP) are two protocols | | | | defined in the IP Performance Metrics | | | | (IPPM) working group in the IETF. These | | | | protocols allow various performance | | | | metrics to be measured, such as packet | | | | loss, delay and delay variation, | | | | duplication and reordering. | | +-----------+------------------------------------------+------------+ |TRILL OAM | The requirements of OAM in TRILL are | TRILL | | | defined in [TRILL-OAM]. These | | | | requirements include continuity checking,| | | | connectivity verification, path tracing | | | | and performance monitoring. During the | | | | writing of this document the detailed | | Mizrahi, et al. Expires July 9, 2014 [Page 32] Internet-Draft Overview of OAM Tools January 2014 | | definition of the TRILL OAM tools | | | | is work in progress. | | +-----------+------------------------------------------+------------+ Table 3 Summary of OAM-related IETF Tools 5.2. Summary of OAM Functions Table 4 summarizes the OAM functions that are supported in each of the toolsets that were analyzed in this section. The columns of this tables are the typical OAM functions described in Section 1.3. +-----------+-------+--------+--------+-------+----------+ | |Continu|Connecti|Path |Perform|Other | | |ity |vity |Discover|ance |Function | | |Check |Verifica|y |Monitor|s | | Toolset | |tion | |ing | | +-----------+-------+--------+--------+-------+----------+ |IP Ping |Echo | | | | | + --------- + ----- + ------ + ------ + ----- + -------- + |IP | | |Tracerou| | | |Traceroute | | |te | | | + --------- + ----- + ------ + ------ + ----- + -------- + |BFD |BFD |BFD | | |RDI usi- | | |Control|Control | | |ng BFD | | |/ Echo | | | |Control | + --------- + ----- + ------ + ------ + ----- + -------- + |MPLS OAM | |"Ping" |"Tracero| | | |(LSP Ping) | |mode |ute" | | | | | | |mode | | | + --------- + ----- + ------ + ------ + ----- + -------- + |MPLS-TP |CC |CV/pro- |Route |-LM |-Diagnos- | |OAM | |active |Tracing |-DM | tic Test | | | |or on- | | |-Lock | | | |demand | | |-Alarm | | | | | | |Reporting | | | | | | |-Client | | | | | | |Failure | | | | | | |Indication| | | | | | |-RDI | + --------- + ----- + ------ + ------ + ----- + -------- + |Pseudowire |BFD |-BFD |LSP-Ping| | | |OAM | |-ICMP | | | | Mizrahi, et al. Expires July 9, 2014 [Page 33] Internet-Draft Overview of OAM Tools January 2014 | | | Ping | | | | | | |-LSP- | | | | | | | Ping | | | | + --------- + ----- + ------ + ------ + ----- + -------- + |OWAMP and | - control | |-Delay | | |TWAMP | protocol | | measur| | | | | | ement | | | | | |-Packet| | | | | | loss | | | | | | measur| | | | | | ement | | + --------- + ----- + ------ + ------ + ----- + -------- + |TRILL OAM |CC |CV |Path |-Delay | | | | | |tracing | measur| | | | | | | ement | | | | | | |-Packet| | | | | | | loss | | | | | | | measur| | | | | | | ement | | +-----------+-------+--------+--------+-------+----------+ Table 4 Summary of the OAM Functionality in IETF OAM Tools 5.3. Guidance to Network Equipment Vendors As mentioned in Section 1.4. , it is imperative for OAM tools to be capable of testing the actual data plane in as much accuracy as possible. While this guideline may appear obvious, it is worthwhile to emphasize the key importance of enforcing fate-sharing between OAM traffic that monitors the data plane and the data plane traffic it monitors. 6. Security Considerations This memo presents an overview of existing OAM tools, and proposes no new OAM tools. Therefore, this document introduces no security considerations. However, the OAM tools reviewed in this document can and do present security issues. The reader is encouraged to review the Security Considerations section of each document referenced by this memo. 7. IANA Considerations There are no new IANA considerations implied by this document. Mizrahi, et al. Expires July 9, 2014 [Page 34] Internet-Draft Overview of OAM Tools January 2014 8. Acknowledgments The authors gratefully acknowledge Sasha Vainshtein, Carlos Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other members of the OPSAWG mailing list for their helpful comments. This document was prepared using 2-Word-v2.0.template.dot. 9. References 9.1. Informative References [ATM-L2] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May 2006. [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [BFD-Gen] Katz, D., Ward, D., "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010. [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [Comp] Bonaventure, O., "Computer Networking: Principles, Protocols and Practice", 2008. [Dup] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009. Mizrahi, et al. Expires July 9, 2014 [Page 35] Internet-Draft Overview of OAM Tools January 2014 [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic Associated Channel", RFC 5586, June 2009. [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers, JR., "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010. [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007. [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [IEEE802.1Q] IEEE 802.1Q, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", October 2012. [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology - Local and metropolitan area networks - Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", clause 57, December 2008. [IntHost] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989. [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [IPPM-2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. Mizrahi, et al. Expires July 9, 2014 [Page 36] Internet-Draft Overview of OAM Tools January 2014 [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework for IP Performance Metrics", RFC 2330, May 1998. [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)", November 2012. [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS", November 2012. [ITU-T-CT] Betts, M., "Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)", RFC 6671, November 2012. [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January 2009. [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance mechanism for MPLS networks", February 2004. [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and Mechanisms for Ethernet-based Networks", July 2011. [ITU-Terms] ITU-R/ITU-T Terms and Definitions, online, 2013. [L2TP-EC] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values", RFC 5641, August 2009. [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., Dai, X., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011. [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [Mng] Farrel, A., "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, February 2011. Mizrahi, et al. Expires July 9, 2014 [Page 37] Internet-Draft Overview of OAM Tools January 2014 [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., Matsushima, S., "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006. [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T., "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006. [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for OAM in MPLS Transport Networks", RFC 5860, May 2010. [NetTerms] Jacobsen, O., Lynch, D., "A Glossary of Networking Terms", RFC 1208, March 1991. [NetTools] Enger, R., Reynolds, J., "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", RFC 1470, June 1993. [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool Set for MPLS based Transport Networks", RFC 6669, July 2012. [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, D., Mansfield, S., "Guidelines for the use of the OAM acronym in the IETF ", RFC 6291, June 2011. [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002. Mizrahi, et al. Expires July 9, 2014 [Page 38] Internet-Draft Overview of OAM Tools January 2014 [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011. [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and Zekauskas, M., "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, "Measuring Load-balanced Paths in the Internet", IMC, 2007. [PM-CONS] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011. [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [PW-G-ACh] Li, H., Martini, L., He, J., Huang, F., "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, November 2011. [PW-MAP] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011. [Reorder] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006. [Signal] Yasukawa, S., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006. [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and TCP/IP Tools and Utilities", RFC 2151, June 1997. [TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile", RFC 6428, November 2011. Mizrahi, et al. Expires July 9, 2014 [Page 39] Internet-Draft Overview of OAM Tools January 2014 [TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011. [TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011. [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration and Maintenance Framework for MPLS-based Transport Networks ", RFC 6371, September 2011. [TP-Term] Van Helvoort, H., Andersson, L., Sprecher, N., "A Thesaurus for the Terminology used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations", RFC 7087, December 2013. [TRILL-OAM] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve, R., "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, March 2013. [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and Babiarz, J., "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008. [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [VCCV-SURVEY] Del Regno, N., Malis, A., "The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", RFC 7079, November 2013. Appendix A. List of OAM Documents A.1. List of IETF OAM Documents Table 5 summarizes the OAM related RFCs published by the IETF. It is important to note that the table lists various RFCs that are different by nature. For example, some of these documents define OAM tools or OAM protocols (or both), while others define protocols that Mizrahi, et al. Expires July 9, 2014 [Page 40] Internet-Draft Overview of OAM Tools January 2014 are not strictly OAM-related, but are used by OAM tools. The table also includes RFCs that define the requirements or the framework of OAM in a specific context (e.g., MPLS-TP). The RFCs in the table are categorized in a few sets as defined in Section 1.3. +-----------+--------------------------------------+----------+ | Toolset | Title | RFC | +-----------+--------------------------------------+----------+ |IP Ping | Requirements for Internet Hosts -- | RFC 1122 | | | Communication Layers [IntHost] | | | +--------------------------------------+----------+ | | A Glossary of Networking Terms | RFC 1208 | | | [NetTerms] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 792 | | | [ICMPv4] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | Version 6 (IPv6) Specification | | | | [ICMPv6] | | +-----------+--------------------------------------+----------+ |IP | A Primer On Internet and TCP/IP | RFC 2151 | |Traceroute | Tools and Utilities [TCPIP-Tools] | | | +--------------------------------------+----------+ | | FYI on a Network Management Tool | RFC 1470 | | | Catalog: Tools for Monitoring and | | | | Debugging TCP/IP Internets and | | | | Interconnected Devices [NetTools] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 792 | | | [ICMPv4] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | Version 6 (IPv6) Specification | | | | [ICMPv6] | | | +--------------------------------------+----------+ | | Extended ICMP to Support Multi-Part | RFC 4884 | | | Messages [ICMP-MP] | | Mizrahi, et al. Expires July 9, 2014 [Page 41] Internet-Draft Overview of OAM Tools January 2014 | +--------------------------------------+----------+ | | Extending ICMP for Interface and | RFC 5837 | | | Next-Hop Identification [ICMP-Int] | | +-----------+--------------------------------------+----------+ |BFD | Bidirectional Forwarding Detection | RFC 5880 | | | [BFD] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5881 | | | (BFD) for IPv4 and IPv6 (Single Hop) | | | | [BFD-IP] | | | +--------------------------------------+----------+ | | Generic Application of Bidirectional | RFC 5882 | | | Forwarding Detection [BFD-Gen] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5883 | | | (BFD) for Multihop Paths [BFD-Multi] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5884 | | | for MPLS Label Switched Paths (LSPs) | | | | [BFD-LSP] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | Connectivity Verification (VCCV) | | | | [BFD-VCCV] | | +-----------+--------------------------------------+----------+ |MPLS OAM | Operations and Management (OAM) | RFC 4377 | | | Requirements for Multi-Protocol Label| | | | Switched (MPLS) Networks [MPLS-OAM] | | | +--------------------------------------+----------+ | | A Framework for Multi-Protocol | RFC 4378 | | | Label Switching (MPLS) Operations | | | | and Management (OAM) [MPLS-OAM-FW] | | | +--------------------------------------+----------+ | | Detecting Multi-Protocol Label | RFC 4379 | | | Switched (MPLS) Data Plane Failures | | | | [LSP-Ping] | | | +--------------------------------------+----------+ | | Operations and Management (OAM) | RFC 4687 | | | Requirements for Point-to-Multipoint | | | | MPLS Networks [MPLS-P2MP] | | Mizrahi, et al. Expires July 9, 2014 [Page 42] Internet-Draft Overview of OAM Tools January 2014 | +--------------------------------------+----------+ | | ICMP Extensions for Multiprotocol | RFC 4950 | | | Label Switching [ICMP-Ext] | | +-----------+--------------------------------------+----------+ |MPLS-TP | Requirements for OAM in MPLS-TP | RFC 5860 | |OAM | [MPLS-TP-OAM] | | | +--------------------------------------+----------+ | | MPLS Generic Associated Channel | RFC 5586 | | | [G-ACh] | | | +--------------------------------------+----------+ | | MPLS-TP OAM Framework | RFC 6371 | | | [TP-OAM-FW] | | | +--------------------------------------+----------+ | | Proactive Connectivity Verification, | RFC 6428 | | | Continuity Check, and Remote Defect | | | | Indication for the MPLS Transport | | | | Profile [TP-CC-CV] | | | +--------------------------------------+----------+ | | MPLS On-Demand Connectivity | RFC 6426 | | | Verification and Route Tracing | | | | [OnDemand-CV] | | | +--------------------------------------+----------+ | | MPLS Fault Management Operations, | RFC 6427 | | | Administration, and Maintenance (OAM)| | | | [TP-Fault] | | | +--------------------------------------+----------+ | | MPLS Transport Profile Lock Instruct | RFC 6435 | | | and Loopback Functions [Lock-Loop] | | | +--------------------------------------+----------+ | | Packet Loss and Delay Measurement for| RFC 6374 | | | MPLS Networks [MPLS-LM-DM] | | | +--------------------------------------+----------+ | | A Packet Loss and Delay Measurement | RFC 6375 | | | Profile for MPLS-Based Transport | | | | Networks [TP-LM-DM] | | +-----------+--------------------------------------+----------+ |Pseudowire | Pseudowire Virtual Circuit | RFC 5085 | |OAM | Connectivity Verification (VCCV): | | | | A Control Channel for Pseudowires | | | | [VCCV] | | | +--------------------------------------+----------+ Mizrahi, et al. Expires July 9, 2014 [Page 43] Internet-Draft Overview of OAM Tools January 2014 | | Bidirectional Forwarding Detection | RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | Connectivity Verification (VCCV) | | | | [BFD-VCCV] | | | +--------------------------------------+----------+ | | Using the Generic Associated Channel | RFC 6423 | | | Label for Pseudowire in the MPLS | | | | Transport Profile (MPLS-TP) | | | | [PW-G-ACh] | | | +--------------------------------------+----------+ | | Pseudowire (PW) Operations, | RFC 6310 | | | Administration, and Maintenance (OAM)| | | | Message Mapping [PW-MAP] | | +-----------+--------------------------------------+----------+ |OWAMP and | A One-way Active Measurement Protocol| RFC 4656 | |TWAMP | [OWAMP] | | | +--------------------------------------+----------+ | | A Two-Way Active Measurement Protocol| RFC 5357 | | | [TWAMP] | | | +--------------------------------------+----------+ | | Framework for IP Performance Metrics | RFC 2330 | | | [IPPM-FW] | | | +--------------------------------------+----------+ | | IPPM Metrics for Measuring | RFC 2678 | | | Connectivity [IPPM-Con] | | | +--------------------------------------+----------+ | | A One-way Delay Metric for IPPM | RFC 2679 | | | [IPPM-1DM] | | | +--------------------------------------+----------+ | | A One-way Packet Loss Metric for IPPM| RFC 2680 | | | [IPPM-1LM] | | | +--------------------------------------+----------+ | | A Round-trip Delay Metric for IPPM | RFC 2681 | | | [IPPM-2DM] | | | +--------------------------------------+----------+ | | Packet Reordering Metrics | RFC 4737 | | | [Reorder] | | | +--------------------------------------+----------+ | | A One-Way Packet Duplication Metric | RFC 5560 | | | [Dup] | | +-----------+--------------------------------------+----------+ Mizrahi, et al. Expires July 9, 2014 [Page 44] Internet-Draft Overview of OAM Tools January 2014 |TRILL OAM | Requirements for Operations, | RFC 6905 | | | Administration, and Maintenance (OAM)| | | | in Transparent Interconnection of | | | | Lots of Links (TRILL) | | +-----------+--------------------------------------+----------+ Table 5 Summary of IETF OAM Related RFCs A.2. List of Selected Non-IETF OAM Documents In addition to the OAM tools defined by the IETF, the IEEE and ITU-T have also defined various OAM tools that focus on Ethernet, and various other transport network environments. These various tools, defined by the three standard organizations, are often tightly coupled, and have had a mutual effect on each other. The ITU-T and IETF have both defined OAM tools for MPLS LSPs, [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to some extent linked to IETF OAM tools listed above and are mentioned here only as reference material: o OAM tools for Layer 2 have been defined by the ITU-T in [ITU-T-Y1731], and by the IEEE in 802.1ag [IEEE802.1Q] . The IEEE 802.3 standard defines OAM for one-hop Ethernet links [IEEE802.3ah]. o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. It should be noted that these non-IETF documents deal in many cases with OAM functions below the IP layer (Layer 2, Layer 2.5) and in some cases operators use a multi-layered OAM approach, which is a function of the way their networks are designed. Table 6 summarizes some of the main OAM standards published by non- IETF standard organizations. This document focuses on IETF OAM standards, but these non-IETF standards are referenced in this document where relevant. +-----------+--------------------------------------+---------------+ | | Title |Standard/Draft | +-----------+--------------------------------------+---------------+ |ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 | |MPLS OAM | for MPLS networks [ITU-T-Y1711] | | | +--------------------------------------+---------------+ | | Assignment of the 'OAM Alert Label' | RFC 3429 | | | for Multiprotocol Label Switching | | Mizrahi, et al. Expires July 9, 2014 [Page 45] Internet-Draft Overview of OAM Tools January 2014 | | Architecture (MPLS) Operation and | | | | Maintenance (OAM) Functions | | | | [OAM-Label] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T Y.1711. | | +-----------+--------------------------------------+---------------+ |ITU-T | Operations, administration and |ITU-T G.8113.2 | |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | | | | networks using the tools defined for | | | | MPLS [ITU-G8113.2] | | | | | | | | Note: this document describes the | | | | OAM toolset defined by the IETF for | | | | MPLS-TP, whereas ITU-T G.8113.1 | | | | describes the OAM toolset defined | | | | by the ITU-T. | | | +--------------------------------------+---------------+ | | Operations, Administration and |ITU-T G.8113.1 | | | Maintenance mechanism for MPLS-TP in | | | | Packet Transport Network (PTN) | | | +--------------------------------------+---------------+ | | Allocation of a Generic Associated | RFC 6671 | | | Channel Type for ITU-T MPLS Transport| | | | Profile Operation, Maintenance, and | | | | Administration (MPLS-TP OAM) | | | | [ITU-T-CT] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T G.8113.1. | | +-----------+--------------------------------------+---------------+ |ITU-T | OAM Functions and Mechanisms for | ITU-T Y.1731 | |Ethernet | Ethernet-based Networks | | |OAM | [ITU-T-Y1731] | | +-----------+--------------------------------------+---------------+ Mizrahi, et al. Expires July 9, 2014 [Page 46] Internet-Draft Overview of OAM Tools January 2014 |IEEE | Connectivity Fault Management | IEEE 802.1ag | |CFM | [IEEE802.1Q] | | | | | | | | Note: CFM was originally published | | | | as IEEE 802.1ag, but is now | | | | incorporated in the 802.1Q standard.| | +-----------+--------------------------------------+---------------+ |IEEE | Management of Data Driven and Data | IEEE 802.1ag | |DDCFM | Dependent Connectivity Faults | | | | [IEEE802.1Q] | | | | | | | | Note: DDCFM was originally published| | | | as IEEE 802.1Qaw, but is now | | | | incorporated in the 802.1Q standard.| | +-----------+--------------------------------------+---------------+ |IEEE | Media Access Control Parameters, | IEEE 802.3ah | |802.3 | Physical Layers, and Management | | |link level | Parameters for Subscriber Access | | |OAM | Networks [IEEE802.3ah] | | | | | | | | Note: link level OAM was originally | | | | defined in IEEE 802.3ah, and is now | | | | incorporated in the 802.3 standard. | | +-----------+--------------------------------------+---------------+ Table 6 Non-IETF OAM Standards Mentioned in this Document Authors' Addresses Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com Nurit Sprecher NSN 3 Hanagar St. Neve Ne'eman B Mizrahi, et al. Expires July 9, 2014 [Page 47] Internet-Draft Overview of OAM Tools January 2014 Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com Elisa Bellagamba Ericsson 6 Farogatan St. Stockholm, 164 40 Sweden Phone: +46 761440785 Email: elisa.bellagamba@ericsson.com Yaacov Weingarten 34 Hagefen St. Karnei Shomron, 4485500 Israel Email: wyaacov@gmail.com Mizrahi, et al. Expires July 9, 2014 [Page 48] On Jul 8, 2013:5:43 PM, at 5:43 PM, Tal Mizrahi > wrote: Hi, We have updated draft-ietf-opsawg-oam-overview following the comments we re= ceived in IETF last call. http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-09 This document went into IETF last call in January, and we received comments= from (in chronological order): Benoit Claise, Al Morton, Sam Aldrin, Tom N= adeau, Carlos Pignataro, Elwyn Davies, Sasha Vainshtein, Dan Romascanu, Tho= mas Narten, Joel Jaeggli. We carefully considered each and every comment, and significantly edited th= e document to address these comments. After we revised the document some of our reviewers kindly agreed to reiter= ate on the document in 1x1 sessions, allowing us to verify that we addresse= d the major comments. A brief summary of the changes in the document: - We practically rewrote the introduction; we added a subsection about the = target audience, and add general background about OAM including some histor= ical background. - The structure of the document went through a significant revision as well= ; for example, we moved the list of OAM documents to an appendix, and moved= the terminology section closer to the beginning. - We revised the terminology section: we added quite a few terms that were = used without definition, and we fixed some inaccurate existing definitions.= We also did some major editing throughout the document to verify that the = terminology is used consistently. - We added content that was missing in previous version of the draft, e.g.,= TRILL OAM. We encourage the reviewers to go over the updated document and let us know = if there are any further comments. Any further comments from the WG are welcome. Thanks, Tal. --_000_74470498B659FA4687F0B0018C19A89C01D43919C121ILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tom,

 

Thanks for reviewing the draft and sending us = your comments.

 =

Based on your comments we have= updated the draft:

http:/= /tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13

 

We made an effort to address all the comments you sent.<= /o:p>

Please see our inline replies t= o your comments, marked by [TM].

=  

Please let u= s know if you have further comments.

 

Thanks,<= o:p>

Tal.<= /p>

 

 

F= rom: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Mon= day, January 20, 2014 5:30 PM
To: Tal Mizrahi
Cc: opsaw= g@ietf.org; opsawg-chairs@tools.ietf.org; Carlos Pignataro (cpignata); Alex= ander Vainshtein; Elwyn Davies; MORTON JR., ALFRED C (AL); Thomas Narten; S= am Aldrin; Romascanu, Dan (Dan); joel jaeggli; Benoit Claise
Subject:= Re: Updated draft-ietf-opsawg-oam-overview

=

 

 &nbs= p;   Apol= ogies but I just realized I hadn't reviewed this document post the Vancouve= r IETF meeting when I was asked. My comments are included. I do not fe= el this document is ready to go forward as there are some major omissions a= s noted below.

    = --Tom




  &= nbsp;  I have reviewed this document. Comments inline start wit= h TOM:.  
General comments are:

1) Psedowire OAM messag= e mapping and ethernet OAM are missing.<= /o:p>

[TM] Point well ta= ken. Notice the document includes the section “4.6.3. Attachment Circ= uit – Pseudowire Mapping”. Following your comment we added text= about Ethernet mapping and RFC 7023.



2) There is no discussion about OAM for L2VPN or L3VPN = explicitly here. It is important to explain this applicability.

= [TM] Point well taken. We have added brief descriptions about L2VPN = and L3VPN, since the focus of this document is OAM *tools*, and no new tool= s are defined in the context of L2VPN and L3VPN. We have added a new subsec= tion, 4.4.3., that discusses L2VPN and L3VPN in the context of MPLS. We hav= e also added text to section 4.6.3 about L2VPNs in the context of pseudowir= es.



3) BFD for MPLS is not explained. It is a very= viable replacement for CV instead of LSP Ping.

[TM] Point= well taken. We have added a new subsection “4.4.2. BFD for MPLS̶= 1;.



--Tom




Operations and Manage= ment Area Working Group               &n= bsp;  T. Mizrahi
Internet Draft           =                      = ;                   MarvellIntended status: Informational             &= nbsp;                 N. SprecherExpires: July 2014                = ;                     &nb= sp;             NSN
      &= nbsp;                    =                     &nbs= p;          E. Bellagamba
      =                      = ;                     &nb= sp;               Ericsson
  &nb= sp;                     &= nbsp;                    =              Y. Weingarten

 = ;                     &nb= sp;                     &= nbsp;            January 9, 2014

 = ;                     &nb= sp;       An Overview of
        &nbs= p; Operations, Administration, and Maintenance (OAM) Tools
   =                draft-ietf-opsawg-o= am-overview-12.txt


Abstract

   Operations, Admi= nistration, and Maintenance (OAM) is a general term
   that re= fers to a toolset for fault detection and isolation, and for
  &nbs= p;performance measurement. Over the years various OAM tools have been
&n= bsp;  defined for various layers in the protocol stack.

  =  This document summarizes some of the OAM tools defined in the IETF in=
   the context of IP unicast, MPLS, MPLS for the transport pr= ofile
   (MPLS-TP), pseudowires, and TRILL. This document focu= ses on tools for
   detecting and isolating failures in networ= ks and for performance
   monitoring. Control and management a= spects of OAM are outside the
   scope of this document. Netwo= rk repair functions such as Fast Reroute
   (FRR) and protecti= on switching, which are often triggered by OAM
   protocols, a= re also out of the scope of this document.

   The target a= udience of this document includes network equipment
   vendors= , network operators and standard development organizations,
   = ;and can be used as an index to some of the main OAM tools defined in
&n= bsp;  the IETF. This document provides a brief description of each of = the
   OAM tools in the IETF. At the end of the document a lis= t of the OAM
   toolsets and a list of the OAM functions are p= resented as a summary.

Status of this Memo

   This = Internet-Draft is submitted to IETF in full conformance with the
  =  provisions of BCP 78 and BCP 79.

   Internet-Drafts = are working documents of the Internet Engineering
   Task Forc= e (IETF), its areas, and its working groups.  Note that
  &nbs= p;other groups may also distribute working documents as Internet-
 =  Drafts.




Mizrahi, et al.       &nbs= p; Expires July 9, 2014               &n= bsp;  [Page 1]
Internet-Draft          Ove= rview of OAM Tools             January 2014

   Internet-Drafts are draft documents valid for a maxi= mum of six months
   and may be updated, replaced, or obsolete= d by other documents at any
   time.  It is inappropriate= to use Internet-Drafts as reference
   material or to cite th= em other than as "work in progress."

   The list= of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abs= tracts.txt.

   The list of Internet-Draft Shadow Direc= tories can be accessed at
   http://www.ietf.org/shadow.html.

   This In= ternet-Draft will expire on July 9, 2014.

Copyright Notice

&n= bsp;  Copyright (c) 2014 IETF Trust and the persons identified as the<= br>   document authors. All rights reserved.

   = This document is subject to BCP 78 and the IETF Trust's Legal
  &nb= sp;Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) i= n effect on the date of
   publication of this document. Pleas= e review these documents
   carefully, as they describe your r= ights and restrictions with respect
   to this document. Code = Components extracted from this document must
   include Simpli= fied BSD License text as described in Section 4.e of
   the Tr= ust Legal Provisions and are provided without warranty as
   d= escribed in the Simplified BSD License.

Table of Contents

&nb= sp;  1. Introduction .................................................= 4
      1.1. Background ................................= .............. 4
      1.2. Target Audience..............= ............................ 5
      1.3. OAM-related Wor= k in the IETF ............................ 5
      1.4. F= ocusing on the Data Plane .............................. 6
   = 2. Terminology .................................................. 7
&nbs= p;     2.1. Abbreviations .......................................= .... 7
      2.2. Terminology used in OAM Standards .....= .................. 9
         2.2.1. General Te= rms ...................................... 9
       =  2.2.2. Operations, Administration and Maintenance ......... 9
&nb= sp;        2.2.3. Functions, Tools and Protocols ......= .............. 10
         2.2.4. Data Plane, C= ontrol Plane and Management Plane .... 10
        &n= bsp;2.2.5. The Players ....................................... 11
 =        2.2.6. Proactive and On-demand Activation .....= ........... 12
         2.2.7. Connectivity Ver= ification and Continuity Checks ... 12
         = ;2.2.8. Connection Oriented vs. Connectionless Communication13
  &n= bsp;      2.2.9. Point-to-point vs. Point-to-multipoint Serv= ices ... 14


Mizrahi, et al.         Expires = July 9, 2014                  = [Page 2]
Internet-Draft          Overview of OA= M Tools             January 2014


&= nbsp;        2.2.10. Failures .........................= ................ 15
   3. OAM Functions ......................= ......................... 15
   4. OAM Tools in the IETF - a D= etailed Description .............. 16
      4.1. IP Ping = ................................................ 16
     = 4.2. IP Traceroute .......................................... 17
 =     4.3. Bidirectional Forwarding Detection (BFD) ..............= . 18
         4.3.1. Overview .................= ......................... 18
         4.3.2. Te= rminology ....................................... 18
     = ;    4.3.3. BFD Control ....................................... 1= 8
         4.3.4. BFD Echo ....................= ...................... 19
      4.4. MPLS OAM ...........= .................................... 19
      4.5. MPLS-T= P OAM ............................................ 20
    &nbs= p;    4.5.1. Overview .......................................... = 20
         4.5.2. Terminology ................= ....................... 21
         4.5.3. Gene= ric Associated Channel ........................ 22
      =    4.5.4. MPLS-TP OAM Toolset ............................... 23<= br>            4.5.4.1. Continuity Check and = Connectivity Verification 23
            4= .5.4.2. Route Tracing ................................ 24
    =         4.5.4.3. Lock Instruct ........................= ........ 24
            4.5.4.4. Lock Repo= rting ............................... 24
        &nb= sp;   4.5.4.5. Alarm Reporting .............................. 24
&n= bsp;           4.5.4.6. Remote Defect Indication .= .................... 24
            4.5.4.= 7. Client Failure Indication .................... 25
     = ;       4.5.4.8. Performance Monitoring ....................= ... 25
               4.5.4.8.1.= Packet Loss Measurement (LM) ............ 25
       = ;        4.5.4.8.2. Packet Delay Measurement (DM) .....= ...... 25
      4.6. Pseudowire OAM .....................= .................... 26
         4.6.1. Pseudow= ire OAM using Virtual Circuit Connectivity
        &= nbsp;Verification (VCCV) ...................................... 26
 = ;        4.6.2. Pseudowire OAM using G-ACh ............= ............ 27
         4.6.3. Attachment Circ= uit - Pseudowire Mapping ........... 27
      4.7. OWAMP = and TWAMP......................................... 27
    &nbs= p;    4.7.1. Overview .......................................... = 27
         4.7.2. Control and Test Protocols .= ....................... 28
         4.7.3. OWAM= P ............................................. 29
      =    4.7.4. TWAMP ............................................. 29<= br>      4.8. TRILL ........................................= .......... 30
   5. Summary ..................................= ................... 30
      5.1. Summary of OAM Tools ..= ................................. 31
      5.2. Summary o= f OAM Functions ............................... 33
      = 5.3. Guidance to Network Equipment Vendors .................. 34
  =  6. Security Considerations ..................................... 34   7. IANA Considerations .....................................= .... 34
   8. Acknowledgments ................................= ............. 35
   9. References ............................= ...................... 35
      9.1. Informative Referenc= es ................................. 35
   Appendix A. List of= OAM Documents .............................. 40


Mizrahi, et al.=         Expires July 9, 2014       &nbs= p;          [Page 3]
Internet-Draft   &nbs= p;      Overview of OAM Tools         &n= bsp;   January 2014


      A.1. List of IETF = OAM Documents ............................. 40
      A.2.= List of Selected Non-IETF OAM Documents ................ 45

1. Intr= oduction

   OAM is a general term that refers to a toolset= for detecting,
   isolating and reporting failures and for mo= nitoring the network
   performance.

   There= are several different interpretations to the "OAM" acronym.
&= nbsp;  This document refers to Operations, Administration and Maintena= nce,
   as recommended in Section 3 of [OAM-Def].

 = ;  This document summarizes some of the OAM tools defined in the IETF = in
   the context of IP unicast, MPLS, MPLS for the transport = profile
   (MPLS-TP), pseudowires, and TRILL.

  &n= bsp;This document focuses on tools for detecting and isolating failures
=    and for performance monitoring. Hence, this document focuses o= n the
   tools used for monitoring and measuring the data plan= e; control and
   management aspects of OAM are outside the sc= ope of this document.
   Network repair functions such as Fast= Reroute (FRR) and protection
   switching, which are often tr= iggered by OAM protocols, are also out
   of the scope of this= document.

1.1. Background

   OAM was originally us= ed in traditional communication technologies
   such as E1 and= T1, evolving into PDH and then later in SONET/SDH. ATM
   was= probably the first technology to include inherent OAM support
  &n= bsp;from day one, while in other technologies OAM was typically defined
=    in an ad hoc manner after the technology was already defined a= nd
   deployed. Packet-based networks were traditionally consi= dered
   unreliable and best-effort, but as packet-based netwo= rks evolved,
   they have become the common transport for both= data and telephony,
   replacing traditional transport protoc= ols. Consequently, packet-based
   networks were expected to p= rovide a similar "carrier grade"
   experience, and = specifically to support OAM.

   As typical networks have a= multi-layer architecture, the set of OAM
   protocols similar= ly take a multi-layer structure; each layer has its
   own OAM= protocols. Moreover, OAM can be used at different levels of
  &nbs= p;hierarchy in the network to form a multi-layer OAM solution, as shown
=    in the example in Figure 1.

   Figure 1 illus= trates a network in which IP traffic between two
   customer e= dges is transported over an MPLS provider network. MPLS OAM


Mizr= ahi, et al.         Expires July 9, 2014     =              [Page 4]
Internet-Draft =          Overview of OAM Tools      = ;       January 2014


   is used at the = provider-level for monitoring the connection between
   the tw= o provider edges, while IP OAM is used at the customer-level
  &nbs= p;for monitoring the end-to-end connection between the two customer
&nbs= p;  edges.

           |<------= -------- Customer-level OAM -------------->|
      &nb= sp;          IP OAM (Ping, Traceroute, OWAMP, TWAM= P)

                  &n= bsp;     |<- Provider-level OAM ->|
     =                     &nbs= p; MPLS OAM (LSP Ping)

     +-----+     &nb= sp; +----+                   &= nbsp;    +----+       +-----+
    &nb= sp;|     |       |    |=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|    | &= nbsp;     |     |
     |    = ; |-------|    |          MPLS   &n= bsp;      |    |-------|     |
 =    |     |  IP   |    |   &nb= sp;                    | =    |  IP   |     |
     +--= ---+       +----+             =            +----+       +-----= +
     Customer     Provider     &nbs= p;                Provider   &= nbsp;  Customer
       Edge      = ;   Edge                  = ;        Edge          Edge
                    =  Figure 1 Example: Multi-layer OAM

1.2. Target Audience

=    The target audience of this document includes:

  &= nbsp;o Standard development organizations - both IETF working groups and      non-IETF organizations can benefit from this document= when
      designing new OAM protocols, or when looking = to reuse existing OAM
      tools for new technologies.
   o Network equipment vendors and network operators - can = use this
      document as an index to some of the common= IETF OAM tools.

   It should be noted that this document = is not necessarily suitable for
   beginners without any backg= round in OAM.

1.3. OAM-related Work in the IETF

   = This memo provides an overview of the different sets of OAM tools
 =  defined by the IETF. The set of OAM tools described in this memo are=
   applicable to IP unicast, MPLS, pseudowires, MPLS for the = transport
   profile (MPLS-TP), and TRILL. While OAM tools tha= t are applicable to
   other technologies exist, they are beyo= nd the scope of this memo.




Mizrahi, et al.    =     Expires July 9, 2014           &nbs= p;      [Page 5]
Internet-Draft       &nbs= p;  Overview of OAM Tools             Ja= nuary 2014


   This document focuses on IETF documents = that have been published as
   RFCs, while other ongoing OAM-r= elated work is outside the scope.

   The IETF has defined = OAM protocols and tools in several different
   contexts. We r= oughly categorize these efforts into a few sets of OAM-
   rel= ated RFCs, listed in Table 1. Each set defines a logically-coupled
 = ;  set of RFCs, although the sets are in some cases intertwined by
=    common tools and protocols.

   The discussion= in this document is ordered according to these sets.

    =                  +------------= --+------------+
               =      | Toolset      | Transport  |
&= nbsp;                    = |              | Technology |
  =                    +-----= ---------+------------+
             =        |IP Ping       | IPv4/IPv6  = ;|
                   =  +--------------+------------+
          =            |IP Traceroute | IPv4/IPv6  |=
                    &= nbsp;+--------------+------------+
          &n= bsp;          |BFD         &nb= sp; | generic    |
            &= nbsp;        +--------------+------------+
  &n= bsp;                  |MPLS OA= M      | MPLS       |
     =                +--------------+---= ---------+
                 = ;    |MPLS-TP OAM   | MPLS-TP    |
   = ;                  +----------= ----+------------+
              &nbs= p;      |Pseudowire OAM| Pseudowires|
     = ;                +--------------+--= ----------+
                &nbs= p;    |OWAMP and     | IPv4/IPv6  |
  &nbs= p;                  |TWAMP &nb= sp;       |            |
&n= bsp;                    += --------------+------------+
            &= nbsp;        |TRILL OAM     | TRILL   &n= bsp;  |
                &nb= sp;    +--------------+------------+
      &nbs= p;      Table 1 OAM Toolset Packages in the IETF Documents
   This document focuses on OAM tools that have been develo= ped in the
   IETF. A short summary of some of the significant= OAM standards that
   have been developed in other standard o= rganizations is presented in
   Appendix A.2.

1.4. Focu= sing on the Data Plane

   OAM tools may, and quite often d= o, work in conjunction with a control
   plane and/or manageme= nt plane.  OAM provides instrumentation tools
   for meas= uring and monitoring the data plane. OAM tools often use


Mizrahi= , et al.         Expires July 9, 2014     &nb= sp;            [Page 6]
Internet-Draft &nb= sp;        Overview of OAM Tools       &= nbsp;     January 2014


   control plane func= tions, e.g., to initialize OAM sessions and to
   exchange var= ious parameters. The OAM tools communicate with the
   managem= ent plane to raise alarms, and often OAM tools may be
   activ= ated by the management (as well as by the control plane), e.g.
  &n= bsp;to locate and localize problems.

   The considerations= of the control plane maintenance tools and the
   functionali= ty of the management plane are out of scope for this
   docume= nt, which concentrates on presenting the data plane tools that
  &n= bsp;are used for OAM. Network repair functions such as Fast Reroute (FRR)   and protection switching, which are often triggered by OAM p= rotocols,
   are also out of the scope of this document.
   Since OAM protocols are used for monitoring the data plane, = it is
   imperative for OAM tools to be capable of testing the= actual data
   plane in as much accuracy as possible. Thus, i= t is important to
   enforce fate-sharing between OAM traffic = that monitors the data plane
   and the data plane traffic it = monitors.

2. Terminology

2.1. Abbreviations

  &nb= sp;ACH    Associated Channel Header

   AIS  = ;  Alarm Indication Signal

   ATM    Asynch= ronous Transfer Mode

   BFD    Bidirectional For= warding Detection

   CC     Continuity Check
=
   CV     Connectivity Verification

  &= nbsp;DM     Delay Measurement

   ECMP   Equ= al Cost Multiple Paths

   FEC    Forwarding Equi= valence Class

   FRR    Fast Reroute

&nbs= p;  G-ACh   Generic Associated Channel

   GAL &n= bsp;  Generic Associated Label



Mizrahi, et al.   &= nbsp;     Expires July 9, 2014          =        [Page 7]
Internet-Draft      =    Overview of OAM Tools           &nbs= p; January 2014


   ICMP   Internet Control Messag= e Protocol

   L2TP   Layer Two Tunneling Protocol
=
   LCCE   L2TP Control Connection Endpoint

 =  LDP    Label Distribution Protocol

   LER=    Label Edge Router

   LM     Loss M= easurement

   LSP    Label Switched Path

=    LSR    Label Switched Router

   ME =     Maintenance Entity

   MEG    Maint= enance Entity Group

   MEP    MEG End Point
<= br>   MIP    MEG Intermediate Point

   = ;MP     Maintenance Point

   MPLS   Multipr= otocol Label Switching

   MPLS-TP MPLS Transport Profile
   MTU    Maximum Transmission Unit

 =  OAM    Operations, Administration, and Maintenance

=    OWAMP   One-way Active Measurement Protocol

 =  PDH    Plesiochronous Digital Hierarchy

  &nbs= p;PE     Provider Edge

   PW     Pseud= owire

   PWE3   Pseudowire Emulation Edge-to-Edge
=
   RBridge Routing Bridge

   RDI   &nbs= p;Remote Defect Indication


Mizrahi, et al.       =   Expires July 9, 2014              = ;    [Page 8]
Internet-Draft          = ;Overview of OAM Tools             January 20= 14


   SDH    Synchronous Digital Hierarchy
   SONET   Synchronous Optical Networking

 = ;  TRILL   Transparent Interconnection of Lots of Links

&n= bsp;  TTL    Time To Live

   TWAMP   T= wo-way Active Measurement Protocol

   VCCV   Virtual = Circuit Connectivity Verification

2.2. Terminology used in OAM Stand= ards

2.2.1. General Terms

   A wide variety of term= s is used in various OAM standards. This
   section presents a= comparison of the terms used in various OAM
   standards, wit= hout fully quoting the definition of each term.

   An inte= resting overview of the term OAM and its derivatives is
   pre= sented in [OAM-Def]. A thesaurus of terminology for MPLS-TP terms
 =  is presented in [TP-Term], and provides a good summary of some of th= e
   OAM related terminology.

2.2.2. Operations, Admini= stration and Maintenance

   The following definition of OA= M is quoted from [OAM-Def]:

   The components of the "= ;OAM" acronym (and provisioning) are defined as
   follow= s:

   o Operations - Operation activities are undertaken t= o keep the
      network (and the services that the netwo= rk provides) up and
      running.  It includes moni= toring the network and finding problems.
      Ideally th= ese problems should be found before users are affected.

   = ;o Administration - Administration activities involve keeping track
&nbs= p;     of resources in the network and how they are used.  I= t includes
      all the bookkeeping that is necessary to= track networking
      resources and the network under c= ontrol.








Mizrahi, et al.     &n= bsp;   Expires July 9, 2014             =      [Page 9]
Internet-Draft         =  Overview of OAM Tools             Janua= ry 2014


   o Maintenance - Maintenance activities are = focused on facilitating
      repairs and upgrades -- for= example, when equipment must be
      replaced, when a r= outer needs a patch for an operating system
      image, = or when a new switch is added to a network.  Maintenance
  &nb= sp;   also involves corrective and preventive measures to make the
=       managed network run more effectively, e.g., adjusting = device
      configuration and parameters.

2.2.3. = Functions, Tools and Protocols

OAM Function



  &n= bsp;An OAM function is an instrumentation measurement type or diagnostic.
   OAM functions are the atomic building blocks of OAM, whe= re each
   function defines an OAM capability.

  &= nbsp;Typical examples of OAM functions are presented in Section 3.

O= AM Protocol

   A protocol used for implementing one or mor= e OAM functions.

   The OWAMP-Test [OWAMP] is an example o= f an OAM protocol.

OAM Tool

   An OAM tool is a spe= cific means of applying one or more OAM
   functions.

&= nbsp;  In some cases an OAM protocol *is* an OAM tool, e.g., OWAMP-Tes= t. In
   other cases an OAM tool uses a set of protocols that = are not strictly
   OAM-related; for example, Traceroute (Sect= ion 4.2.) can be
   implemented using UDP and ICMP messages, w= ithout using an OAM
   protocol per se.

2.2.4. Data Pla= ne, Control Plane and Management Plane

Data Plane

  &nbs= p;The data plane is the set of functions used to transfer data in the
&n= bsp;  stratum or layer under consideration [ITU-Terms].

  =  The Data Plane is also known as the Forwarding Plane or the User
&= nbsp;  Plane.


Mizrahi, et al.         E= xpires July 9, 2014                = [Page 10]
Internet-Draft          Overview of = OAM Tools             January 2014

Control Plane

   The control plane is the set of protocol= s and mechanisms that enable
   routers to efficiently learn h= ow to forward packets towards their
   final destination (base= d on [Comp]).

Management Plane

   The term Manageme= nt Plane, as described in [Mng], is used to describe
   the ex= change of management messages through management protocols
   = (often transported by IP and by IP transport protocols) between
  &= nbsp;management applications and the managed entities such as network
&n= bsp;  nodes.

Data Plane vs. Control Plane vs. Management Plane<= br>
   The distinction between the planes is at times a bit va= gue. For
   example, the definition of "Control Plane&quo= t; above may imply that OAM
   tools such as ping, BFD and oth= ers are in fact in the control plane.

   This document foc= uses on tools used for monitoring the data plane.
   While the= se tools could arguably be considered to be in the control
   = plane, these tools monitor the data plane, and hence it is imperative
&n= bsp;  to have fate-sharing between OAM traffic that monitors the data = plane
   and the data plane traffic it monitors.

 =  Another potentially vague distinction is between the management plan= e
   and control plane. The management plane should be seen as= separate
   from, but possibly overlapping with, the control = plane (based on
   [Mng]).

2.2.5. The Players

&n= bsp;  An OAM tool is used between two (or more) "players". V= arious terms
   are used in IETF documents to refer to the pla= yers that take part in
   OAM. Table 2 summarizes the terms us= ed in each of the toolsets
   discussed in this document.
<= br>          +--------------------------+---------= -----------------+
          | Toolset   &= nbsp;              | Terms    =                |
    =       +--------------------------+--------------------------= +
          | Ping / Traceroute     &= nbsp;  |-Host                 =     |
          | ([ICMPv4], [ICMPv6]= ,     |-Node               &nb= sp;     |
          |  [TCPIP-To= ols])          |-Interface       &n= bsp;        |
          | &= nbsp;                    =    |-Gateway               &n= bsp;  |



Mizrahi, et al.         Exp= ires July 9, 2014                 [= Page 11]
Internet-Draft          Overview of OA= M Tools             January 2014


&= nbsp;         + ------------------------ + ------------= ------------ +
          | BFD [BFD]   &nb= sp;            | System       =             |
        =   + ------------------------ + ------------------------ +
  &n= bsp;       | MPLS OAM [MPLS-OAM-FW]   | LSR   &nbs= p;                  |
 = ;         + ------------------------ + ----------------= -------- +
          | MPLS-TP OAM [TP-OAM-FW] =  |-End Point - MEP          |
   = ;       |               &= nbsp;          |-Intermediate Point - MIP |
&nb= sp;         + ------------------------ + --------------= ---------- +
          | Pseudowire OAM [VCCV] =    |-PE                 &= nbsp;     |
          |    =                     &nbs= p;|-LCCE                   &nb= sp; |
          + ------------------------ + --= ---------------------- +
          | OWAMP and = TWAMP          |-Host         =             |
        =   | ([OWAMP], [TWAMP])       |-End system    =           |
         = + ------------------------ + ------------------------ +
    &= nbsp;     | TRILL OAM [TRILL-OAM]    |-RBridge   &= nbsp;              |
    &n= bsp;     +--------------------------+--------------------------+<= br>                   Tab= le 2 Maintenance Point Terminology



2.2.6. Proactive and On-d= emand Activation

   The different OAM tools may be used in= one of two basic types of
   activation:

Proactive
=
   Proactive activation - indicates that the tool is activate= d on a
   continual basis, where messages are sent periodicall= y, and errors are
   detected when a certain number of expecte= d messages are not received.

On-demand

   On-demand= activation - indicates that the tool is activated
   "ma= nually" to detect a specific anomaly.

2.2.7. Connectivity Verif= ication and Continuity Checks

   Two distinct classes of f= ailure management functions are used in OAM
   protocols, conn= ectivity verification and continuity checks. The
   distinctio= n between these terms is defined in [MPLS-TP-OAM], and is
   u= sed similarly in this document.

Continuity Check



Mizr= ahi, et al.         Expires July 9, 2014     =             [Page 12]
Internet-Draft  = ;        Overview of OAM Tools       &nb= sp;     January 2014


   Continuity checks ar= e used to verify that a destination is reachable,
   and are t= ypically sent proactively, though they can be invoked on-
   d= emand as well.

Connectivity Verification

   A conne= ctivity verification function allows Alice to check whether
   = ;she is connected to Bob or not. It is noted that while the CV
  &n= bsp;function is performed in the data plane, the "expected path" = is
   predetermined either in the control plane or in the mana= gement plane.
   A connectivity verification (CV) protocol typ= ically uses a CV
   message, followed by a CV reply that is se= nt back to the originator.
   A CV function can be applied pro= actively or on-demand.

   Connectivity Verification tools = often perform path verification as
   well, allowing Alice to = verify that messages from Bob are received
   through the corr= ect path, thereby verifying not only that the two MPs
   are c= onnected, but also that they are connected through the expected
  &= nbsp;path, allowing detection of unexpected topology changes.

 =  Connectivity verification and continuity checks are considered
&n= bsp;  complementary mechanisms, and are often used in conjunction with= each
   other.

2.2.8. Connection Oriented vs. Connecti= onless Communication

Connection Oriented

   In Conn= ection Oriented technologies an end-to-end connection is
   es= tablished (by a control protocol or provisioned by a management
  &= nbsp;system) prior to the transmission of data.

   Typical= ly a connection identifier is used to identify the connection.
  &n= bsp;In connection oriented technologies it is often the case (although
&= nbsp;  not always) that all packets belonging to a specific connection= use
   the same route through the network.

Connectionl= ess

   In Connectionless technologies data is typically se= nt between end
   points without prior arrangement. Packets ar= e routed independently
   based on their destination address, = and hence different packets may
   be routed in a different wa= y across the network.

Discussion




Mizrahi, et al. =         Expires July 9, 2014        = ;         [Page 13]
Internet-Draft     &nb= sp;    Overview of OAM Tools           &= nbsp; January 2014


   The OAM tools described in this = document include tools that support
   connection oriented tec= hnologies, as well as tools for connectionless
   technologies= .

   In connection oriented technologies OAM is used to mo= nitor a
   *specific* connection; OAM packets are forwarded th= rough the same
   route as the data traffic and receive the sa= me treatment. In
   connectionless technologies, OAM is used b= etween a source and
   destination pair without defining a spe= cific connection. Moreover, in
   some cases the route of OAM = packets may differ from the one of the
   data traffic. For ex= ample, the connectionless IP Ping (Section 4.1.)
   tests the = reachability from a source to a given destination, while
   th= e connection oriented LSP Ping (Section 4.4.) is used for
   m= onitoring a specific LSP (connection), and provides the capability
 = ;  to monitor all the available paths used by an LSP.

  &n= bsp;It should be noted that in some cases connectionless protocols are
&= nbsp;  monitored by connection oriented OAM protocols. For example, wh= ile IP
   is a connectionless protocol, it can monitored by BF= D (Section 4.3.
   ), which is connection oriented.

2.2= .9. Point-to-point vs. Point-to-multipoint Services

Point-to-point (= P2P)

   A P2P service delivers data from a single source t= o a single
   destination.

Point-to-multipoint (P2MP)
   A P2MP service delivers data from a single source to a o= ne or more
   destinations (based on [Signal]).

  =  An MP2MP service is a service that delivers data from more than one   source to one or more receivers (based on [Signal]).

=    Note: the two definitions for P2MP and MP2MP are quoted from   [Signal]. Although [Signal] describes a specific case of P2M= P and
   MP2MP which is MPLS-specific, these two definitions a= lso apply to
   non-MPLS cases.

Discussion

 = ;  The OAM tools described in this document include tools for P2P
&= nbsp;  services, as well as tools for P2MP services.



Mizrahi, et al.         Expires July 9, 2014   &= nbsp;             [Page 14]
Internet-Draft=          Overview of OAM Tools     &nbs= p;       January 2014


   The distinctio= n between P2P services and P2MP services affects the
   corres= ponding OAM tools. A P2P service is typically simpler to
   mo= nitor, as it consists of a single pair of end points. P2MP services
&nbs= p;  present several challenges. For example, in a P2MP service, the OA= M
   mechanism not only verifies that each of the destinations= is
   reachable from the source, but also verifies that the P= 2MP
   distribution tree is intact and loop-free.

2.2.1= 0. Failures

   The terms Failure, Fault, and Defect are us= ed interchangeably in the
   standards, referring to a malfunc= tion that can be detected by a
   connectivity or a continuity= check. In some standards, such as
   802.1ag [IEEE802.1Q] , t= here is no distinction between these terms,
   while in other = standards each of these terms refers to a different
   type of= malfunction.

   The terminology used in IETF MPLS-TP OAM = is based on the ITU-T
   terminology, which distinguishes betw= een these three terms in
   [ITU-T-G.806];

Fault
   The term Fault refers to an inability to perform a required a= ction,
   e.g., an unsuccessful attempt to deliver a packet.
Defect

   The term Defect refers to an interruption = in the normal operation,
   such as a consecutive period of ti= me where no packets are delivered
   successfully.

Fail= ure

   The term Failure refers to the termination of the r= equired function.
   While a Defect typically refers to a limi= ted period of time, a
   failure refers to a long period of ti= me.

3. OAM Functions

   This subsection provides a = brief summary of the common OAM functions
   used in OAM-relat= ed standards. These functions are used as building
   blocks i= n the OAM standards described in this document.

   o Conne= ctivity Verification (CV), Path Verification and Continuity
   = ;   Checks (CC):
      As defined in Section 2.2.7.<= br>

Mizrahi, et al.         Expires July 9, 2014=                 [Page 15]
Inter= net-Draft          Overview of OAM Tools   &n= bsp;         January 2014


   o Pat= h Discovery / Fault Localization:
      This function can= be used to trace the route to a destination,
      i.e.,= to identify the nodes along the route to the destination.
   =   When more than one route is available to a specific destination,      this function traces one of the available routes. Whe= n a failure
      occurs, this function also allows to de= tect the location of the
      failure.
    =   Note that the term route tracing (or Traceroute) that is used in
=       the context of IP and MPLS, is sometimes referred to a= s path
      tracing in the context of other protocols, s= uch as TRILL.

   o Performance Monitoring:
   = ;   Typically refers to:

        o Loss Mea= surement (LM) - monitors the packet loss rate.

      =   o Delay Measurement (DM) - monitors the delay and delay
  &n= bsp;       variation.

4. OAM Tools in the IETF - a De= tailed Description

   This section presents a detailed des= cription of the sets of OAM-
   related tools in each of the t= oolsets in Table 1.

4.1. IP Ping

   Ping is a commo= n network diagnosis application for IP networks that
   uses I= CMP. According to [NetTerms], 'Ping' is an abbreviation for
   = ;Packet internet groper, although the term has been so commonly used
&nb= sp;  that it stands on its own.  As defined in [NetTerms], it is = a program
   used to test reachability of destinations by send= ing them an ICMP
   echo request and waiting for a reply.
<= br>   The ICMP Echo request/reply exchange in Ping is used as a c= ontinuity
   check function for the Internet Protocol. The ori= ginator transmits an
   ICMP Echo request packet, and the rece= iver replies with an Echo
   reply. ICMP ping is defined in tw= o variants, [ICMPv4] is used for
   IPv4, and [ICMPv6] is used= for IPv6.

   Ping implementations typically use ICMP mess= ages. UDP Ping is a
   variant that uses UDP messages instead = of ICMP echo messages.

   Ping is a single-ended continuit= y check, i.e., it allows the
   *initiator* of the Echo reques= t to test the reachability. If it is
   desirable for both end= s to test the reachability, both ends have to
   invoke Ping i= ndependently.



Mizrahi, et al.         Ex= pires July 9, 2014                 = [Page 16]
Internet-Draft          Overview of O= AM Tools             January 2014


=    Note that since ICMP filtering is deployed in some routers and=
   firewalls, the usefulness of Ping is sometimes limited in = the wider
   internet. This limitation is equally relevant to = Traceroute.

4.2. IP Traceroute

   Traceroute ([TCPI= P-Tools], [NetTools]) is an application that allows
   users t= o discover a path between an IP source and an IP destination.

 =  The most common way to implement Traceroute [TCPIP-Tools] is
&nbs= p;  described as follows. Traceroute sends a sequence of UDP packets t= o
   UDP port 33434 at the destination. By default, Traceroute= begins by
   sending three packets (the number of packets is = configurable in most
   Traceroute implementations), each with= an IP Time-To-Live (or Hop
   Limit in IPv6) value of one to = the destination. These packets expire
   as soon as they reach= the first router in the path. Consequently,
   that router se= nds three ICMP Time Exceeded Messages back to the
   Tracerout= e application. Traceroute now sends another three UDP
   packe= ts, each with the TTL value of 2. These messages cause the
   = second router to return ICMP messages. This process continues, with
&nbs= p;  ever increasing values for the TTL field, until the packets actual= ly
   reach the destination. Because no application listens to= port 33434
   at the destination, the destination returns ICM= P Destination
   Unreachable Messages indicating an unreachabl= e port. This event
   indicates to the Traceroute application = that it is finished.  The
   Traceroute program displays = the round-trip delay associated with each
   of the attempts.<= br>
   While Traceroute is a tool that finds *a* path from A t= o B, it should
   be noted that traffic from A to B is often f= orwarded through Equal
   Cost Multiple Paths (ECMP). Paris Tr= aceroute [PARIS] is an extension
   to Traceroute that attempt= s to discovers all the available paths from
   A to B by scann= ing different values of header fields (such as UDP
   ports) i= n the probe packets.

   It is noted that Traceroute is an = application, and not a protocol. As
   such, it has various di= fferent implementations. One of the most
   common ones uses U= DP probe packets, as described above. Other
   implementations= exist that use other types of probe messages, such as
   ICMP= or TCP.

   Note that IP routing may be asymmetric. While = Traceroute discovers a
   path between a source and destinatio= n, it does not reveal the reverse
   path.

   = ;A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in
&nbs= p;  the context of Traceroute. These documents define several extensio= ns,


Mizrahi, et al.         Expires July 9, = 2014                 [Page 17]
I= nternet-Draft          Overview of OAM Tools  = ;           January 2014


   i= ncluding extensions to the ICMP Destination Unreachable message,
  =  that can be used by Traceroute applications.

4.3. Bidirectiona= l Forwarding Detection (BFD)

4.3.1. Overview

   Whi= le multiple OAM tools have been defined for various protocols in
  =  the protocol stack, Bidirectional Forwarding Detection [BFD], defined=
   by the IETF BFD working group, is a generic OAM tool that = can be
   deployed over various encapsulating protocols, and i= n various medium
   types. The IETF has defined variants of th= e protocol for IP ([BFD-
   IP], [BFD-Multi]), for MPLS LSPs [= BFD-LSP], and for pseudowires [BFD-
   VCCV]. The usage of BFD= in MPLS-TP is defined in [TP-CC-CV].

   BFD includes two = main OAM functions, using two types of BFD packets:
   BFD Con= trol packets, and BFD Echo packets.

4.3.2. Terminology

 =  BFD operates between *systems*. The BFD protocol is run between two<= br>   or more systems after establishing a *session*.

4.3.= 3. BFD Control

   BFD supports a bidirectional continuity = check, using BFD control
   packets, that are exchanged within= a BFD session. BFD sessions
   operate in one of two modes:
   o Asynchronous mode (i.e. proactive): in this mode BFD c= ontrol
      packets are sent periodically. When the rece= iver detects that no
      BFD control packets have been = received during a predetermined
      period of time, a f= ailure is detected.

   o Demand mode: in this mode, BFD co= ntrol packets are sent on-demand.
      Upon need, a syst= em initiates a series of BFD control packets to
      che= ck the continuity of the session. BFD control packets are sent
  &n= bsp;   independently in each direction.

   Each of th= e end-points (referred to as systems) of the monitored path
   = ;maintains its own session identification, called a Discriminator,
 = ;  both of which are included in the BFD Control Packets that are
&= nbsp;  exchanged between the end-points.  At the time of session<= br>   establishment, the Discriminators are exchanged between the= two-end
   points.  In addition, the transmission (and r= eception) rate is
   negotiated between the two end-points, ba= sed on information included



Mizrahi, et al.     &n= bsp;   Expires July 9, 2014             =     [Page 18]
Internet-Draft          = ;Overview of OAM Tools             January 20= 14


   in the control packets.  These transmission= rates may be renegotiated
   during the session.

 = ;  During normal operation of the session, i.e. no failures are
&nb= sp;  detected, the BFD session is in the Up state.  If no BFD Con= trol
   packets are received during a period of time called th= e Detection
   Time, the session is declared to be Down. The d= etection time is a
   function of the pre-configured or negoti= ated transmission time, and a
   parameter called Detect Mult.= Detect Mult determines the number of
   missing BFD Control p= ackets that cause the session to be declared as
   Down. This = parameter is included in the BFD Control packet.

4.3.4. BFD Echo
=
   A BFD echo packet is sent to a peer system, and is looped = back to the
   originator. The echo function can be used proac= tively, or on-demand.

   The BFD echo function has been de= fined in BFD for IPv4 and IPv6
   ([BFD-IP]), but is not used = in BFD for MPLS LSPs, PWs, or in BFD for
   MPLS-TP.

4.= 4. MPLS OAM

   The IETF MPLS working group has defined OAM= for MPLS LSPs. The
   requirements and framework of this effo= rt are defined in
   [MPLS-OAM-FW] and [MPLS-OAM], respectivel= y. The corresponding OAM
   tool defined, in this context, is = LSP Ping [LSP-Ping]. OAM for P2MP
   services is defined in [M= PLS-P2MP].

   LSP Ping is modeled after the Ping/Tracerout= e paradigm and thus it
   may be used in one of two modes:
=
   o "Ping" mode: In this mode LSP Ping is used for= end-to-end
      connectivity verification between two L= ERs.

   o "Traceroute" mode: This mode is used f= or hop-by-hop fault
      isolation.

   = LSP Ping extends the basic ICMP Ping operation (of data-plane
  &nb= sp;connectivity verification) with functionality to verify data-plane
&n= bsp;  vs. control-plane consistency for a Forwarding Equivalence Class=
   (FEC) and also Maximum Transmission Unit (MTU) problems.
TOM: This is misleading. LSP Ping does not extend any part of ICMP op= eration; its a completely new operation that is native to MPLS.  It is= important not to conflate these two things, as there are proprietary = versions of ICMP ping extended for MPLS that DO NOT work in all cases. This= is why LSP Ping was invented (and trace).

[TM] Point= well taken. Rephrased.

<= span style=3D'font-family:"Courier New"'>

   The Tracerout= e functionality may be used to isolate and localize the
   MPL= S faults, using the Time-to-live (TTL) indicator to incrementally
 =  identify the sub-path of the LSP that is successfully traversed
&= nbsp;  before the faulty link or node.


TOM: There is more t= o the LSP Traceroute than just using TTL. Please review the RFC for details= .

[TM] Our challenge in this overview document is to try t= o capture some of the most significant content of each of the RFCs we menti= on. Indeed, an overview document cannot (and should not) include all the de= tails about all the topics it covers. This is just an example where, as you= mention, there is more to the protocol than is currently described, and we= believe that it is quite reasonable that we do not cover the entire RFC. H= owever, if you believe there is a significant point that is currently missi= ng in the text, it would be great if you could explain what you are referri= ng to.



Mizrahi, et al.        = Expires July 9, 2014               &nbs= p; [Page 19]
Internet-Draft          Overview o= f OAM Tools             January 2014

<= br>   The challenge in MPLS networks is that the traffic of a giv= en LSP may
   be load balanced across Equal Cost Multiple path= s (ECMP). LSP Ping
   monitors all the available paths of an L= SP by monitoring its
   different Forwarding Equivalence Class= es (FEC). Conversely, MPLS-TP
   does not use ECMP, and thus d= oes not require OAM over multiple paths.

TOM: Why "conversely&q= uot;?  You imply that MPLS-TP is "better" somehow with that = statement; its different.  

[TM] We by no means = implied that MPLS-TP is better. In fact, we believe that all MPLS variants = are created equal. :)

= The sentence was rephrased.



   = ;Another challenge is that an MPLS LSP does not necessarily have a
 = ;  return path, and thus responding to an LSP Ping message is not
<= br>TOM: Strictily speaking, an LSP does not have a return path. There is a = return route at the other end that is used to return the response message. = This can be a different MPLS LSP, IP or whatever.

[TM= ] Point well taken. Rephrased.



   necess= arily as trivial as in IP Ping, where the responder just swaps
  &n= bsp;the source and destination IP addresses. Note that this challenge is   not applicable to MPLS-TP, where a return path is always avai= lable.

   It should be noted that LSP Ping supports unique= identification of
   the LSP within an addressing domain. The= identification is checked
   using the full FEC identificatio= n. LSP Ping is easily extensible to
   include additional info= rmation needed to support new functionality,
   by use of Type= -Length-Value (TLV) constructs. The usage of TLVs is
   typica= lly not easy to perform in hardware, and is thus typically
   = handled by the control plane.

   LSP Ping supports both as= ynchronous, as well as, on-demand
   activation.

4.5. M= PLS-TP OAM

4.5.1. Overview

   The MPLS working grou= p has defined the OAM toolset that fulfills the
   requirement= s for MPLS-TP OAM. The full set of requirements for MPLS-
   T= P OAM are defined in [MPLS-TP-OAM], and include both general
  &nbs= p;requirements for the behavior of the OAM tools and a set of
  &nb= sp;operations that should be supported by the OAM toolset.  The set of=
   mechanisms required are further elaborated in [TP-OAM-FW],= which
   describes the general architecture of the OAM system= as well as
   giving overviews of the functionality of the OA= M toolset.

   Some of the basic requirements for the OAM t= oolset for MPLS-TP are:

   o MPLS-TP OAM must be able to s= upport both an IP based and non-IP
      based environmen= t. If the network is IP based, i.e. IP routing and
      = forwarding are available, then the MPLS-TP OAM toolset should rely
 = ;     on the IP routing and forwarding capabilities. On the other= hand,
      in environments where IP functionality is no= t available, the OAM
      tools must still be able to op= erate without dependence on IP
      forwarding and routi= ng.




Mizrahi, et al.         Expires = July 9, 2014                 [Page = 20]
Internet-Draft          Overview of OAM Too= ls             January 2014


 =  o OAM packets and the user traffic are required to be congruent
&= nbsp;     (i.e. OAM packets are transmitted in-band) and there is= a need to
      differentiate OAM packets from data plan= e ones. Inherent in this
      requirement is the princip= le that MPLS-TP OAM be independent of
      any existing = control-plane, although it should not preclude use of
    &nbs= p; the control-plane functionality.
      OAM packets are= identified by the Generic Associated Label (GAL),
      = which is a reserved MPLS label value (13).

4.5.2. Terminology
Maintenance Entity (ME)

   The MPLS-TP OAM tools are desi= gned to monitor and manage a
   Maintenance Entity (ME).  = ;An ME, as defined in [TP-OAM-FW], defines a
   relationship b= etween two points of a transport path to which
   maintenance = and monitoring operations apply.

   The term Maintenance E= ntity (ME) is used in ITU-T Recommendations
   (e.g. [ITU-T-Y1= 731]), as well as in the MPLS-TP terminology
   ([TP-OAM-FW]).=

Maintenance Entity Group (MEG)

   The collection o= f one or more MEs that belongs to the same transport
   path a= nd that are maintained and monitored as a group are known as a
  &n= bsp;Maintenance Entity Group (based on [TP-OAM-FW]).

Maintenance Poi= nt (MP)

   A Maintenance Point (MP) is a functional entity= that is defined at a
   node in the network, and can initiate= and/or react to OAM messages.
   This document focuses on the= data-plane functionality of MPs, while
   MPs interact with t= he control plane and with the management plane as
   well.
=
   The term MP is used in IEEE 802.1ag, and was similarly ado= pted in
   MPLS-TP ([TP-OAM-FW]).

Maintenance End Point= (MEP)

   A Maintenance End Point (MEP) is one of the end = points of an ME, and
   can initiate OAM messages and respond = to them (based on [TP-OAM-FW]).

Maintenance Intermediate Point (MIP)=




Mizrahi, et al.         Expires Jul= y 9, 2014                 [Page 21]=
Internet-Draft          Overview of OAM Tools =             January 2014


  &n= bsp;In between MEPs, there are zero or more intermediate points, called
=    Maintenance Entity Group Intermediate Points  (based on [= TP-OAM-FW]).

   A Maintenance Intermediate Point (MIP) is = an intermediate point that
   does not generally initiate OAM = frames (one exception to this is the
   use of AIS notificatio= ns), but is able to respond to OAM frames that
   are destined= to it. A MIP in MPLS-TP identifies OAM packets destined
   to= it by the value of the TTL field in the OAM packet. The term
  &nb= sp;Maintenance Point is a general term for MEPs and MIPs.

Up and Dow= n MEPs

   The IEEE 802.1ag [IEEE802.1Q] defines a distinct= ion between Up MEPs
   and Down MEPs. A MEP is a bridge interf= ace that is monitored by an
   OAM protocol either in the dire= ction facing the network, or in the
   direction facing the br= idge. A Down MEP is a MEP that receives OAM
   packets from, a= nd transmits them to the direction of the network. An
   Up ME= P receives OAM packets from, and transmits them to the direction
  =  of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar
 = ;  distinction on the placement of the MEP - either at the ingress,   egress, or forwarding function of the node (Down / Up MEPs). =  This
   placement is important for localization of a fai= lure.

   The distinction between Up and Down MEPs was defi= ned in [TP-OAM-FW],
   but has not been used in other MPLS-TP = RFCs, as of the writing of
   this document.

4.5.3. Gen= eric Associated Channel

   In order to address the require= ment for in-band transmission of MPLS-
   TP OAM traffic, MPLS= -TP uses a Generic Associated Channel (G-ACh),
   defined in [= G-ACh] for LSP-based OAM traffic. This mechanism is based
   o= n the same concepts as the PWE3 ACH and VCCV mechanisms.  However,
=    to address the needs of LSPs as differentiated from PW, the fo= llowing
   concepts were defined for [G-ACh]:

  &n= bsp;o An Associated Channel Header (ACH), that uses a format similar to
=       the PW Control Word, is a 4-byte header that is prepen= ded to OAM
      packets.

   o A Generic= Associated Label (GAL). The GAL is a reserved MPLS label
    =   value (13) that indicates that the packet is an ACH packet and the      payload follows immediately after the label stack.
   It should be noted that while the G-ACh was defined as p= art of the
   MPLS-TP definition effort, the G-ACh is a generi= c tool that can be
   used in MPLS in general, and not only in= MPLS-TP.


Mizrahi, et al.         Expires Ju= ly 9, 2014                 [Page 22= ]
Internet-Draft          Overview of OAM Tools=             January 2014


4.5.4. M= PLS-TP OAM Toolset

   To address the functionality that is= required of the OAM toolset, the
   MPLS WG conducted an anal= ysis of the existing IETF and ITU-T OAM
   tools and their abi= lity to fulfill the required functionality.  The
   concl= usions of this analysis are documented in [OAM-Analys]. The MPLS
  =  working group currently plans to use a mixture of OAM tools that are<= br>   based on various existing standards, and adapt them to the<= br>   requirements of [MPLS-TP-OAM]. Some of the main building bl= ocks of
   this solution are based on:

   o B= idirectional Forwarding Detection ([BFD], [BFD-LSP]) for
    &= nbsp; proactive continuity check and connectivity verification.

&nbs= p;  o LSP Ping as defined in [LSP-Ping] for on-demand connectivity
=       verification.

   o New protocol packe= ts, using G-ACH, to address different
      functionality= .

   o Performance measurement protocols that are based on= the
      functionality that is described in [ITU-T-Y173= 1].

   The following sub-sections describe the OAM tools d= efined for MPLS-TP
   as described in [TP-OAM-FW].

4.5.= 4.1. Continuity Check and Connectivity Verification

   Con= tinuity Check and Connectivity Verification are presented in
  &nbs= p;Section 2.2.7. of this document.  As presented there, these tools ma= y
   be used either proactively or on-demand.  When using= these tools
   proactively, they are generally used in tandem= .

   For MPLS-TP there are two distinct tools, the proacti= ve tool is
   defined in [TP-CC-CV] while the on-demand tool i= s defined in
   [OnDemand-CV]. In on-demand mode, this functio= n should support
   monitoring between the MEPs and, in additi= on, between a MEP and MIP.
   [TP-OAM-FW] highlights,  wh= en performing Connectivity Verification,
   the need for the C= C-V messages to include unique identification of
   the MEG th= at is being monitored and the MEP that originated the
   messa= ge.

   The proactive tool [TP-CC-CV] is based on extension= s to BFD (see
   Section 4.3.) with the additional limitation = that the transmission
   and receiving rates are based on conf= iguration by the operator.  The
   on-demand tool [OnDema= nd-CV] is an adaptation of LSP Ping (see
   Section 4.4.) for = the required behavior of MPLS-TP.


Mizrahi, et al.     =     Expires July 9, 2014            = ;     [Page 23]
Internet-Draft         &nb= sp;Overview of OAM Tools             January = 2014


4.5.4.2. Route Tracing

   [MPLS-TP-OAM] de= fines that there is a need for functionality that
   would all= ow a path end-point to identify the intermediate and end-
   p= oints of the path. This function would be used in on-demand mode.
 =  Normally, this path will be used for bidirectional PW, LSP, and
&= nbsp;  sections, however, unidirectional paths may be supported only i= f a
   return path exists.  The tool for this is based on= the LSP Ping (see
   Section 4.4.) functionality and is descr= ibed in [OnDemand-CV].

4.5.4.3. Lock Instruct

   Th= e Lock Instruct function [Lock-Loop] is used to notify a transport
 = ;  path end-point of an administrative need to disable the transport   path.  This functionality will generally be used in con= junction with
   some intrusive OAM function, e.g. Performance= measurement, Diagnostic
   testing, to minimize the side-effe= ct on user data traffic.

4.5.4.4. Lock Reporting

   = ;Lock Reporting is a function used by an end-point of a path to report
&= nbsp;  to its far-end end-point that a lock condition has been affecte= d on
   the path.

4.5.4.5. Alarm Reporting

 = ;  Alarm Reporting [TP-Fault] provides the means to suppress alarms   following detection of defect conditions at the server sub-la= yer.
   Alarm reporting is used by an intermediate point of a = path, that
   becomes aware of a fault on the path, to report = to the end-points of
   the path. [TP-OAM-FW] states that this= may occur as a result of a
   defect condition discovered at = a server sub-layer. This generates an
   Alarm Indication Sign= al (AIS) that continues until the fault is
   cleared. The con= sequent action of this function is detailed in
   [TP-OAM-FW].=

4.5.4.6. Remote Defect Indication

   Remote Defect= Indication (RDI) is used proactively by a path end-
   point = to report to its peer end-point that a defect is detected on a
  &n= bsp;bidirectional connection between them. [MPLS-TP-OAM] points out that   this function may be applied to a unidirectional LSP only if = there a
   return path exists.  [TP-OAM-FW] points out th= at this function is
   associated with the proactive CC-V func= tion.





Mizrahi, et al.         Ex= pires July 9, 2014                 = [Page 24]
Internet-Draft          Overview of O= AM Tools             January 2014


= 4.5.4.7. Client Failure Indication

   Client Failure Indic= ation (CFI) is defined in [MPLS-TP-OAM] to allow
   the propag= ation information from one edge of the network to the
   other= . The information concerns a defect to a client, in the case
  &nbs= p;that the client does not support alarm notification.

4.5.4.8. Perf= ormance Monitoring

   The definition of MPLS performance m= onitoring was motivated by the
   MPLS-TP requirements [MPLS-T= P-OAM], but was defined generically for
   MPLS in [MPLS-LM-DM= ]. An additional document [TP-LM-DM] defines a
   performance = monitoring profile for MPLS-TP.

4.5.4.8.1. Packet Loss Measurement (= LM)

   Packet Loss Measurement is a function used to verif= y the quality of
   the service. Packet loss, as defined in [I= PPM-1LM] and [MPLS-TP-OAM],
   indicates the ratio of the numb= er of user packets lost to the total
   number of user packets= sent during a defined time interval.

   There are two pos= sible ways of determining this measurement:

   o Using OAM= packets, it is possible to compute the statistics based
    &= nbsp; on a series of OAM packets. This, however, has the disadvantage of      being artificial, and may not be representative since= part of the
      packet loss may be dependent upon pack= et sizes and upon the
      implementation of the MEPs th= at take part in the protocol.

   o Sending delimiting mess= ages for the start and end of a measurement
      period = during which the source and sink of the path count the
    &nb= sp; packets transmitted and received. After the end delimiter, the
 = ;     ratio would be calculated by the path OAM entity.

4.= 5.4.8.2. Packet Delay Measurement (DM)

   Packet Delay Mea= surement is a function that is used to measure one-
   way or = two-way delay of a packet transmission between a pair of the
  &nbs= p;end-points of a path (PW, LSP, or Section). Where:

   o = One-way packet delay, as defined in [IPPM-1DM], is the time
   = ;   elapsed from the start of transmission of the first bit of the
=       packet by a source node until the reception of the las= t bit of
      that packet by the destination node. Note = that one-way delay
      measurement requires the clocks = of the two end-points to be
      synchronized.


Mizrahi, et al.         Expires July 9, 2014 &nbs= p;               [Page 25]
Internet-D= raft          Overview of OAM Tools     =         January 2014


   o Two-way = packet delay, as defined in [IPPM-2DM], is the time
     = elapsed from the start of transmission of the first bit of the
  &= nbsp;   packet by a source node until the reception of the last bit of= the
      loop-backed packet by the same source node, wh= en the loopback is
      performed at the packet's destin= ation node. Note that due to
      possible path asymmetr= y, the one-way packet delay from one end-
      point to = another is not necessarily equal to half of the two-way
    &n= bsp; packet delay.
      As opposed to one-way delay meas= urement, two-way delay measurement
      does not require= the two end-points to be synchronized.

   For each of the= se two metrics, the DM function allows the MEP to
   measure t= he delay, as well as the delay variation. Delay measurement
   = ;is performed by exchanging timestamped OAM packets between the
  &= nbsp;participating MEPs.

4.6. Pseudowire OAM

4.6.1. Pseudowir= e OAM using Virtual Circuit Connectivity Verification
   (VCCV= )

   VCCV, as defined in [VCCV], provides a means for end-= to-end fault
   detection and diagnostics tools to be extended= for PWs (regardless of

TOM: Why "to be extended"?  T= hey've already been extended.

[TM] In this context “= to be extended” was not intended to refer to the future. <= /span>

Rephrased.



   the underlying tunneling technology). The VCCV sw= itching function
   provides a control channel associated with= each PW. [VCCV] defines
   three Control Channel (CC) types, = i.e., three possible methods for
   transmitting and identifyi= ng OAM messages:

   o CC Type 1: In-band VCCV, as describe= d in [VCCV], is also referred
      to as "PWE3 Cont= rol Word with 0001b as first nibble".  It uses the
  &nbs= p;   PW Associated Channel Header [PW-ACH].

   o CC T= ype 2: Out-of-band VCCV [VCCV], is also referred to as "MPLS
 =     Router Alert Label". In this case the control channel i= s created
      by using the MPLS router alert label [MPL= S-ENCAPS] immediately
      above the PW label.

&n= bsp;  o CC Type 3: TTL expiry VCCV [VCCV], is also referred to as &quo= t;MPLS PW
      Label with TTL =3D=3D 1", i.e., the = control channel is identified when
      the value of the= TTL field in the PW label is set to 1.

   VCCV currently = supports the following OAM tools: ICMP Ping, LSP Ping,
   and = BFD. ICMP and LSP Ping are IP encapsulated before being sent over
 =  the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of
  =  encapsulation - either IP/UDP encapsulated (with IP/UDP header) or   PW-ACH encapsulated (with no IP/UDP header) and provides supp= ort to
   signal the AC status. The use of the VCCV control ch= annel provides


Mizrahi, et al.         Expir= es July 9, 2014                 [Pa= ge 26]
Internet-Draft          Overview of OAM = Tools             January 2014


&nb= sp;  the context, based on the MPLS-PW label, required to bind and
=    bootstrap the BFD session to a particular pseudo wire (FEC),   eliminating the need to exchange Discriminator values.
   VCCV consists of two components: (1) signaled component to   communicate VCCV capabilities as part of VC label, and (2) s= witching
   component to cause the PW payload to be treated as= a control packet.

   VCCV is not directly dependent upon = the presence of a control plane.
   The VCCV capability negoti= ation may be performed as part of the PW

TOM: There is not really a = capability "negotiation" per se; its a capability advertisement w= ith strict and explicit rules for what each end should do when it rece= ives capability advertisements. 

[TM] Point well take= n. Rephrased.



   signaling when LDP is u= sed. In case of manual configuration of the
   PW, it is the r= esponsibility of the operator to set consistent
   options at = both ends. The manual option was created specifically to
   ha= ndle MPLS-TP use cases where no control plane was a requirement.
  =  However, new use cases such as pure mobile backhaul find this
&nbs= p;  functionality useful too.

   The PWE3 working gro= up has conducted an implementation survey of VCCV
   [VCCV-SUR= VEY], which analyzes which VCCV mechanisms are used in
   prac= tice.

4.6.2. Pseudowire OAM using G-ACh

   As menti= oned above, VCCV enables OAM for PWs by using a control
   cha= nnel for OAM packets. When PWs are used in MPLS-TP networks,
  &nbs= p;rather than the control channels defined in VCCV, the G-ACh can be
&nb= sp;  used as an alternative control channel. The usage of the G-ACh fo= r
   PWs is defined in [PW-G-ACh].

4.6.3. Attachment Ci= rcuit - Pseudowire Mapping

   The PWE3 working group has d= efined a mapping and notification of
   defect states between = a pseudowire (PW) and the Attachment Circuits
   (ACs) of the = end-to-end emulated service. This mapping is of key
   importa= nce to the end-to-end functionality. Specifically, the mapping
  &n= bsp;is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and
&n= bsp;  Section 5.3 of [ATM-L2] for ATM.

4.7. OWAMP and TWAMP
=
4.7.1. Overview

   The IPPM working group in the IETF = defines common criteria and
   metrics for measuring performan= ce of IP traffic ([IPPM-FW]). Some of
   the key RFCs publishe= d by this working group have defined metrics for
   measuring = connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]),
   an= d packet loss [IPPM-1LM]. It should be noted that the work of the

Mizrahi, et al.         Expires July 9, 2014   &= nbsp;             [Page 27]
Internet-Draft=          Overview of OAM Tools     &nbs= p;       January 2014


   IETF in the co= ntext of performance metrics is not limited to IP
   networks;= [PM-CONS] presents general guidelines for considering new
   = performance metrics.

   The IPPM working group has defined= not only metrics for performance
   measurement, but also pro= tocols that define how the measurement is
   carried out. The = One-way Active Measurement Protocol [OWAMP] and the
   Two-Way= Active Measurement Protocol [TWAMP] define a method and
   pr= otocol for measuring performance metrics in IP networks.

  &nbs= p;OWAMP [OWAMP] enables measurement of one-way characteristics of IP
&nb= sp;  networks, such as one-way packet loss and one-way delay.  Fo= r its
   proper operation OWAMP requires accurate time of day = setting at its
   end points.

   TWAMP [TWAMP= ] is a similar protocol that enables measurement of both
   on= e-way and two-way (round trip) characteristics.

   OWAMP a= nd TWAMP are both comprised of two separate protocols:

   = o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop
  =     test sessions and to fetch their results. Continuity Check an= d
      Connectivity Verification are tested and confirme= d by establishing
      the OWAMP/TWAMP Control Protocol = TCP connection.

   o OWAMP-Test/TWAMP-Test: used to exchan= ge test packets between two
      measurement nodes. Enab= les the loss and delay measurement
      functions, as we= ll as detection of other anomalies, such as packet
      = duplication and packet reordering.

   It should be noted t= hat while [OWAMP] and [TWAMP] define tools for
   performance = measurement, they do not define the accuracy of these
   tools= . The accuracy depends on scale, implementation and network
   = ;configurations.

   Alternative protocols for performance = monitoring are defined, for
   example, in MPLS-TP OAM ([MPLS-= LM-DM], [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].
=
4.7.2. Control and Test Protocols

   OWAMP and TWAMP c= ontrol protocols run over TCP, while the test
   protocols run= over UDP.  The purpose of the control protocols is to
   = ;initiate, start, and stop test sessions, and for OWAMP to fetch
  =  results.  The test protocols introduce test packets (which conta= in
   sequence numbers and timestamps) along the IP path under= test
   according to a schedule, and record statistics of pac= ket arrival.


Mizrahi, et al.         Expires= July 9, 2014                 [Page= 28]
Internet-Draft          Overview of OAM To= ols             January 2014


 = ;  Multiple sessions may be simultaneously defined, each with a sessio= n
   identifier, and defining the number of packets to be sent= , the amount
   of padding to be added (and thus the packet si= ze), the start time,
   and the send schedule (which can be ei= ther a constant time between
   test packets or exponentially = distributed pseudo-random). Statistics
   recorded conform to = the relevant IPPM RFCs.

   OWAMP and TWAMP test traffic is= designed with security in mind. Test
   packets are hard to d= etect because they are simply UDP streams
   between negotiate= d port numbers, with potentially nothing static in
   the pack= ets.  OWAMP and TWAMP also include optional authentication
  &= nbsp;and encryption for both control and test packets.

4.7.3. OWAMP<= br>
   OWAMP defines the following logical roles: Session-Send= er, Session-
   Receiver, Server, Control-Client, and Fetch-Cl= ient.  The Session-
   Sender originates test traffic tha= t is received by the Session-
   Receiver.  The Server co= nfigures and manages the session, as well as
   returning the = results.  The Control-Client initiates requests for
   te= st sessions, triggers their start, and may trigger their
   te= rmination.  The Fetch-Client requests the results of a completed
&n= bsp;  session.  Multiple roles may be combined in a single host -= for
   example, one host may play the roles of Control-Client= , Fetch-Client,
   and Session-Sender, and a second playing th= e roles of Server and
   Session-Receiver.

   = ;In a typical OWAMP session the Control-Client establishes a TCP
  =  connection to port 861 of the Server, which responds with a server   greeting message indicating supported security/integrity mode= s. The
   Control-Client responds with the chosen communicatio= ns mode and the
   Server accepts the modes.  The Control= -Client then requests and fully
   describes a test session to= which the Server responds with its
   acceptance and supporti= ng information.  More than one test session
   may be req= uested with additional messages.  The Control-Client then
  &n= bsp;starts a test session and the Server acknowledges.  The Session-   Sender then sends test packets with pseudorandom padding to = the
   Session-Receiver until the session is complete or until= the Control-
   client stops the session.  Once finished= , the Fetch-Client sends a
   fetch request to the server, whi= ch responds with an acknowledgement
   and immediately thereaf= ter the result data.

4.7.4. TWAMP

   TWAMP defines = the following logical roles: session-sender, session-
   refle= ctor, server, and control-client.  These are similar to the


Mizrahi, et al.         Expires July 9, 2014  = ;               [Page 29]
Internet-Dr= aft          Overview of OAM Tools     &= nbsp;       January 2014


   OWAMP roles= , except that the Session-Reflector does not collect any
   pa= cket information, and there is no need for a Fetch-Client.

  &n= bsp;In a typical TWAMP session the Control-Client establishes a TCP
&nbs= p;  connection to port 862 of the Server, and mode is negotiated as in=
   OWAMP.  The Control-Client then requests sessions and= starts them.
   The Session-Sender sends test packets with ps= eudorandom padding to
   the Session-Reflector which returns t= hem with insertion of
   timestamps.

4.8. TRILL

=    The requirements of OAM in TRILL are defined in [TRILL-OAM]. T= he
   challenge in TRILL OAM, much like in MPLS networks, is t= hat traffic
   between RBridges RB1 and RB2 may be forwarded t= hrough more than one
   path. Thus, an OAM protocol between RB= ridges RB1 and RB2 must be able
   to monitor all the availabl= e paths between the two RBridge.

   During the writing of = this document the detailed definition of the
   TRILL OAM tool= s are still work in progress. This subsection presents
   the = main requirements of TRILL OAM.

   The main requirements d= efined in [TRILL-OAM] are:

   o Continuity Checking (CC) -= the TRILL OAM protocol must support a
      function for= CC between any two RBridges RB1 and RB2.

   o Connectivit= y Verification (CV) - connectivity between two RBridges
    &n= bsp; RB1 and RB2 can be verified on a per-flow basis.

   o= Path Tracing - allows an RBridge to trace all the available paths
 = ;     to a peer RBridge.

   o Performance monito= ring - allows an RBridge to monitor the packet
      loss= and packet delay to a peer RBridge.

5. Summary

   = This section summarizes the OAM tools and functions presented in this
&n= bsp;  document. This summary is an index to some of the main OAM tools=
   defined in the IETF. This compact index that can be useful= to all
   readers from network operators to standard developm= ent organizations.
   The summary includes a short subsection = that presents some guidance
   to network equipment vendors.




Mizrahi, et al.         Expires J= uly 9, 2014                 [Page 3= 0]
Internet-Draft          Overview of OAM Tool= s             January 2014


5.1. Su= mmary of OAM Tools

   This subsection provides a short sum= mary of each of the OAM toolsets
   described in this document= .

   A detailed list of the RFCs related to each toolset i= s given in
   Appendix A.1.

   +-----------+-= -----------------------------------------+------------+
   | T= oolset   | Description              = ;                | Transport  = |
   |           |     &nbs= p;                     &n= bsp;              | Technology |
&nbs= p;  +-----------+------------------------------------------+----------= --+
   |IP Ping    | Ping ([IntHost], [NetTerms]) is= a simple | IPv4/IPv6  |
   |        =   | application for testing reachability that|       &= nbsp;    |
   |           |= uses ICMP Echo messages ([ICMPv4],       |     &n= bsp;      |
   |         &n= bsp; | [ICMPv6]).                 &= nbsp;             |       &nbs= p;    |
   +-----------+----------------------------= --------------+------------+
   |IP        = ; | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6  |
  =  |Traceroute | an application that allows users to trace|    = ;        |
   |        = ;   | the path between an IP source and an IP  |     &n= bsp;      |
   |         &n= bsp; | destination, i.e., to identify the nodes |       &nbs= p;    |
   |           | al= ong the path. If more than one path    |       &nb= sp;    |
   |           | e= xists between the source and destination|          = ;  |
   |           | Traceroute= traces *a* path. The most     |         &nbs= p;  |
   |           | common im= plementation of Traceroute      |        = ;    |
   |           | use= s UDP probe messages, although there  |         &n= bsp;  |
   |           | are oth= er implementations that use       |       &nb= sp;    |
   |           | d= ifferent probes, such as ICMP or TCP.   |         =    |
   +-----------+-------------------------------= -----------+------------+
   |BFD        |= Bidirectional Forwarding Detection (BFD) | generic    |
 = ;  |           | is defined in [BFD] as a fra= mework for a |            |
   |=           | lightweight generic OAM tool.  T= he       |            |
&nb= sp;  |           | intention is to define a b= ase tool       |            |<= br>   |           | that can be used wit= h various            |       &= nbsp;    |
   |           |= encapsulation types, network             | &= nbsp;          |
   |     &= nbsp;     | environments, and in various medium     &nb= sp;|            |
   |   &n= bsp;       | types.            = ;                     &nb= sp; |            |
   +---------= --+------------------------------------------+------------+
   = ;|MPLS OAM   | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS   =     |
   |           | [MPL= S-OAM-FW] and [LSP-Ping], is an OAM  |         &nb= sp;  |
   |           | tool for= point-to-point and              |  = ;          |
   |      = ;     | point-to-multipoint MLPS LSPs.        = ;   |            |


Mizrahi, e= t al.         Expires July 9, 2014      =           [Page 31]
Internet-Draft   &nbs= p;      Overview of OAM Tools         &n= bsp;   January 2014


   |       &nb= sp;   | It includes two main functions: Ping and |      = ;      |
   |          = ; | Traceroute.                 &nb= sp;            |         =    |
   |           | It is= noted that while this category     |        =    |
   |           | focu= ses on LSP Ping, other OAM tools     |        = ;    |
   |           | can= be used in MPLS networks, e.g., BFD. |           =  |
   +-----------+--------------------------------------= ----+------------+
   |MPLS-TP OAM| MPLS-TP OAM is defined in = a set of RFCs. | MPLS-TP    |
   |     &nb= sp;     | The OAM requirements for MPLS Transport  |   =          |
   |       =     | Profile (MPLS-TP) are defined in        = ; |            |
   |   &nb= sp;       | [MPLS-TP-OAM]. Each of the tools in the  | =            |
   |     =       | OAM toolset is defined in its own RFC, as|   &n= bsp;        |
   |       &n= bsp;   | specified in Section A.1.           =      |            |
  =  +-----------+------------------------------------------+------------+=
   |Pseudowire | The PWE3 OAM architecture defines control| P= seudowire |
   |OAM        | channels that= support the use of existing|            |   |           | IETF OAM tools to be u= sed for a pseudo-  |            |
&nb= sp;  |           | wire (PW).  The contr= ol channels that are|            |
  =  |           | defined in [VCCV] and [PW-G-AC= h] may be  |            |
  &nbs= p;|           | used in conjunction with ICMP Ping= , LSP  |            |
   | =           | Ping, and BFD to perform CC and CV &nb= sp;     |            |
  &n= bsp;|           | functionality.  In addition= the channels |            |
   = |           | support use of any of the MPLS-TP ba= sed  |            |
   | &n= bsp;         | OAM tools for completing their respectiv= e|            |
   |   &nbs= p;       | OAM functionality for a PW.       =        |            |
=    +-----------+------------------------------------------+------= ------+
   |OWAMP and  | The One Way Active Measurement P= rotocol  | IPv4/IPv6  |
   |TWAMP     &nbs= p;| (OWAMP) and the Two Way Active Measure-  |       &n= bsp;    |
   |           | = ment Protocols (TWAMP) are two protocols |         &nbs= p;  |
   |           | defined i= n the IP Performance Metrics    |         &nb= sp;  |
   |           | (IPPM) w= orking group in the IETF. These  |           =  |
   |           | protocols al= low various performance      |         &= nbsp;  |
   |           | metric= s to be measured, such as packet   |          = ;  |
   |           | loss, dela= y and delay variation,         |       &= nbsp;    |
   |           |= duplication and reordering.             &nbs= p;|            |
   +-----------= +------------------------------------------+------------+
   |= TRILL OAM  | The requirements of OAM in TRILL are     | TRIL= L      |
   |          = ; | defined in [TRILL-OAM]. These            = |            |
   |    = ;       | requirements include continuity checking,|   =          |
   |       =     | connectivity verification, path tracing  |   &nbs= p;        |
   |       &nbs= p;   | and performance monitoring. During the   |     &= nbsp;      |
   |         &= nbsp; | writing of this document the detailed    |     =        |


Mizrahi, et al.      = ;   Expires July 9, 2014             &nb= sp;   [Page 32]
Internet-Draft          Ov= erview of OAM Tools             January 2014<= br>

   |           | definition o= f the TRILL OAM tools        |       &nb= sp;    |
   |           | i= s work in progress.                =     |            |
   = ;+-----------+------------------------------------------+------------+
&= nbsp;                Table 3 Summar= y of OAM-related IETF Tools

5.2. Summary of OAM Functions

&nb= sp;  Table 4 summarizes the OAM functions that are supported in each o= f
   the toolsets that were analyzed in this section. The colu= mns of this
   tables are the typical OAM functions described = in Section 1.3.

       +-----------+-------+----= ----+--------+-------+----------+
       |   &n= bsp;       |Continu|Connecti|Path    |Perform|Othe= r     |
       |       &nbs= p;   |ity    |vity    |Discover|ance   |Funct= ion  |
       |         &nb= sp; |Check  |Verifica|y       |Monitor|s     =     |
       | Toolset   |   &nb= sp;   |tion    |        |ing   &nbs= p;|          |
       +----= -------+-------+--------+--------+-------+----------+
    &nbs= p;  |IP Ping    |Echo   |        | =        |       |       &n= bsp;  |
       + --------- + ----- + ------ + -= ----- + ----- + -------- +
       |IP     =     |       |        |Tracerou= |       |          |
  &nbs= p;    |Traceroute |       |       &= nbsp;|te      |       |       =    |
       + --------- + ----- + ------ += ------ + ----- + -------- +
       |BFD   &nbs= p;    |BFD    |BFD     |      =  |       |RDI usi-  |
      &nb= sp;|           |Control|Control |     &n= bsp;  |       |ng BFD    |
    &= nbsp;  |           |/ Echo |     &n= bsp;  |        |       |Control &nb= sp; |
       + --------- + ----- + ------ + ------ += ----- + -------- +
       |MPLS OAM   |  =     |"Ping"  |"Tracero|      = |          |
       |(LSP = Ping) |       |mode    |ute"    | &= nbsp;     |          |
    =    |           |       | =        |mode    |       | &nbs= p;        |
       + --------- += ----- + ------ + ------ + ----- + -------- +
       = ;|MPLS-TP    |CC     |CV/pro- |Route   |-LM  =  |-Diagnos- |
       |OAM      =  |       |active  |Tracing |-DM    | ti= c Test |
       |          = |       |or on-  |        |  =     |-Lock     |
       |  = ;         |       |demand  |  =      |       |-Alarm    |
 = ;      |           |     =   |        |        |   &= nbsp;   |Reporting |
       |     &nb= sp;     |       |        | &nb= sp;      |       |-Client   |
  =      |           |     &n= bsp; |        |        |   &nb= sp;   |Failure   |
       |     =       |       |        | =        |       |Indication|
  &n= bsp;    |           |     &nbs= p; |        |        |    = ;   |-RDI      |
       + ------= --- + ----- + ------ + ------ + ----- + -------- +
      =  |Pseudowire |BFD    |-BFD    |LSP-Ping|   &n= bsp;   |          |
      &= nbsp;|OAM        |       |-ICMP   |=        |       |       &= nbsp;  |


Mizrahi, et al.         Expire= s July 9, 2014                 [Pag= e 33]
Internet-Draft          Overview of OAM T= ools             January 2014


&nbs= p;      |           |    =   | Ping   |        |       |=          |
       |  =         |       |-LSP-   |   =      |       |         &n= bsp;|
       |           | =       | Ping   |        |   &n= bsp;   |          |
      &= nbsp;+ --------- + ----- + ------ + ------ + ----- + -------- +
  &= nbsp;    |OWAMP and  | - control      |  = ;      |-Delay |          |
&nbs= p;      |TWAMP      |   protocol   =   |        | measur|         &= nbsp;|
       |           |=                |     &nb= sp;  | ement |          |
    &n= bsp;  |           |       &nbs= p;        |        |-Packet|  =        |
       |    =       |               &n= bsp;|        | loss  |        =  |
       |          = |                |     &= nbsp;  | measur|          |
    =    |           |       &n= bsp;        |        | ement | &nbs= p;        |
       + --------- += ----- + ------ + ------ + ----- + -------- +
       = ;|TRILL OAM  |CC     |CV      |Path   &n= bsp;|-Delay |          |
      &= nbsp;|           |       |   &= nbsp;    |tracing | measur|          |       |           |   =     |        |        | e= ment |          |
       | =           |       |     &= nbsp;  |        |-Packet|       &nb= sp;  |
       |         &nb= sp; |       |        |     &nb= sp;  | loss  |          |
  &nbs= p;    |           |      = |        |        | measur|  =        |
       |    =       |       |        |=        | ement |          |       +-----------+-------+--------+--------+-------= +----------+
         Table 4 Summary of the OA= M Functionality in IETF OAM Tools

5.3. Guidance to Network Equipment= Vendors

   As mentioned in Section 1.4. , it is imperativ= e for OAM tools to be
   capable of testing the actual data pl= ane in as much accuracy as
   possible. While this guideline m= ay appear obvious, it is worthwhile
   to emphasize the key im= portance of enforcing fate-sharing between OAM
   traffic that= monitors the data plane and the data plane traffic it
   moni= tors.

6. Security Considerations

   This memo prese= nts an overview of existing OAM tools, and proposes
   no new = OAM tools. Therefore, this document introduces no security
   = considerations. However, the OAM tools reviewed in this document can
&nb= sp;  and do present security issues. The reader is encouraged to revie= w
   the Security Considerations section of each document refe= renced by
   this memo.

7. IANA Considerations

&= nbsp;  There are no new IANA considerations implied by this document.<= br>


Mizrahi, et al.         Expires July 9, = 2014                 [Page 34]
I= nternet-Draft          Overview of OAM Tools  = ;           January 2014


8. Acknowledgm= ents

   The authors gratefully acknowledge Sasha Vainshtei= n, Carlos
   Pignataro, David Harrington, Dan Romascanu, Ron B= onica and other
   members of the OPSAWG mailing list for thei= r helpful comments.

   This document was prepared using 2-= Word-v2.0.template.dot.

9. References

9.1. Informative Refere= nces

   [ATM-L2]      Singh, S., Townsley, = M., and C. Pignataro,
              &= nbsp;  "Asynchronous Transfer Mode (ATM) over Layer 2
  &= nbsp;              Tunneling Protocol Ve= rsion 3 (L2TPv3)", RFC 4454, May
         =        2006.

   [BFD]     &= nbsp;   Katz, D., Ward, D., "Bidirectional Forwarding Detection                 (BFD)"= , RFC 5880, June 2010.

   [BFD-Gen]     Katz, D.= , Ward, D., "Generic Application of
        &nb= sp;        Bidirectional Forwarding Detection (BFD)&quo= t;, RFC 5882,
                &n= bsp;June 2010.

   [BFD-IP]      Katz, D., W= ard, D., "Bidirectional Forwarding Detection
      &= nbsp;          (BFD) for IPv4 and IPv6 (Single Hop= )", RFC 5881, June
             =    2010.

   [BFD-LSP]     Aggarwal, R= ., Kompella, K., Nadeau, T., and Swallow,
        &n= bsp;        G., "Bidirectional Forwarding Detectio= n (BFD) for MPLS
               =  Label Switched Paths (LSPs)", RFC 5884, June 2010.

 = ;  [BFD-Multi]   Katz, D., Ward, D., "Bidirectional Forwardi= ng Detection
                &nb= sp;(BFD) for Multihop Paths", RFC 5883, June 2010.

   = ;[BFD-VCCV]    Nadeau, T., Pignataro, C., "Bidirectional For= warding
                 De= tection (BFD) for the Pseudowire Virtual Circuit
      &n= bsp;          Connectivity Verification (VCCV)&quo= t;, RFC 5885, June
              &nbs= p;  2010.

   [Comp]        Bonave= nture, O., "Computer Networking: Principles,
      &= nbsp;          Protocols and Practice", 2008.=

   [Dup]         Uijterwaal, H., &quo= t;A One-Way Packet Duplication Metric",
       =          RFC 5560, May 2009.




M= izrahi, et al.         Expires July 9, 2014   &nbs= p;             [Page 35]
Internet-Draft &n= bsp;        Overview of OAM Tools       =       January 2014


   [G-ACh]   &n= bsp;   Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic
&nb= sp;                Associated Chann= el", RFC 5586, June 2009.

   [ICMP-Ext]    = Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP
   =              Extensions for Multiprotoc= ol Label Switching", RFC
            =      4950, August 2007.

   [ICMP-Int]  = ;  Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers,
  &= nbsp;              JR., "Extending = ICMP for Interface and Next-Hop
           = ;      Identification", RFC 5837, April 2010.

&n= bsp;  [ICMP-MP]     Bonica, R., Gan, D., Tappan, D., Pignata= ro, C.,
                 &q= uot;Extended ICMP to Support Multi-Part Messages", RFC
   = ;              4884, April 2007.

=    [ICMPv4]      Postel, J., "Internet Contro= l Message Protocol", STD 5,
          &nbs= p;      RFC 792, September 1981.

   [ICMPv6= ]      Conta, A., Deering, S., and M. Gupta, "Internet = Control
                 Me= ssage Protocol (ICMPv6) for the Internet Protocol
      &= nbsp;          Version 6 (IPv6) Specification"= ;, RFC 4443, March 2006.

   [IEEE802.1Q]  IEEE 802.1Q= , "IEEE Standard for Local and metropolitan
      &n= bsp;          area networks - Media Access Control= (MAC) Bridges and
              &nbs= p;  Virtual Bridged Local Area Networks", October 2012.

&n= bsp;  [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information te= chnology -
                 = ;Local and metropolitan area networks - Carrier sense
    &nbs= p;            multiple access with collision = detection (CSMA/CD)
              &nb= sp;  access method and physical layer specifications",
  =                clause 57, December = 2008.

   [IntHost]     Braden, R., "Require= ments for Internet Hosts --
            &n= bsp;    Communication Layers", RFC 1122, October 1989.
   [IPPM-1DM]    Almes, G., Kalidindi, S., Zekauskas,= M., "A One-way
              &n= bsp;  Delay Metric for IPPM", RFC 2679, September 1999.

&n= bsp;  [IPPM-1LM]    Almes, G., Kalidindi, S., Zekauskas, M.,= "A One-way
               =  Packet Loss Metric for IPPM", RFC 2680, September
  &nb= sp;              1999.

  &nb= sp;[IPPM-2DM]    Almes, G., Kalidindi, S., Zekauskas, M., "A= Round-trip
                &nbs= p;Delay Metric for IPPM", RFC 2681, September 1999.

  &nbs= p;[IPPM-Con]    Mahdavi, J., Paxson, V., "IPPM Metrics for M= easuring
                 C= onnectivity", RFC 2678, September 1999.


Mizrahi, et al. &nb= sp;       Expires July 9, 2014         &= nbsp;       [Page 36]
Internet-Draft      =    Overview of OAM Tools           &nbs= p; January 2014


   [IPPM-FW]     Paxson, V.,= Almes, G., Mahdavi, J., and Mathis, M.,
        &nb= sp;        "Framework for IP Performance Metrics&q= uot;, RFC 2330, May
              &nb= sp;  1998.

   [ITU-G8113.1] ITU-T Recommendation G.81= 13.1/Y.1372.1, "Operations,
          &nbs= p;      Administration and Maintenance mechanism for MPLS-TP=
                 in Packet= Transport Network (PTN)", November 2012.

   [ITU-G81= 13.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations,
  &= nbsp;              administration and ma= intenance mechanisms for MPLS-TP
          &nbs= p;      networks using the tools defined for MPLS", Nov= ember
                 2012= .

   [ITU-T-CT]    Betts, M., "Allocation o= f a Generic Associated Channel
           =      Type for ITU-T MPLS Transport Profile Operation,
&n= bsp;                Maintenance, an= d Administration (MPLS-TP OAM)", RFC
        &n= bsp;        6671, November 2012.

   [I= TU-T-G.806] ITU-T Recommendation G.806, "Characteristics of
  =                transport equipment = - Description methodology and
            =      generic functionality", January 2009.

 = ;  [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Ma= intenance
                 = mechanism for MPLS networks", February 2004.

   [ITU-= T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and
&nb= sp;                Mechanisms for E= thernet-based Networks", July 2011.

   [ITU-Terms] &n= bsp; ITU-R/ITU-T Terms and Definitions, online, 2013.

   [= L2TP-EC]     McGill, N. and C. Pignataro, "Layer 2 Tunneling=
                 Protocol = Version 3 (L2TPv3) Extended Circuit Status
        &= nbsp;        Values", RFC 5641, August 2009.
   [Lock-Loop]   Boutros, S., Sivabalan, S., Aggarwal, R.,= Vigoureux,
                &nbs= p;M., Dai, X., "MPLS Transport Profile Lock Instruct and
  &nb= sp;              Loopback Functions"= ;, RFC 6435, November 2011.

   [LSP-Ping]    Kom= pella, K., Swallow, G., "Detecting Multi-Protocol
    &nb= sp;            Label Switched (MPLS) Data Pla= ne Failures", RFC 4379,
            &= nbsp;    February 2006.

   [Mng]     &= nbsp;   Farrel, A., "Inclusion of Manageability Sections in
&n= bsp;                Path Computatio= n Element (PCE) Working Group Drafts",
        =          RFC 6123, February 2011.



<= br>Mizrahi, et al.         Expires July 9, 2014   =               [Page 37]
Internet-Draf= t          Overview of OAM Tools     &nb= sp;       January 2014


   [MPLS-ENCAPS]= Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
      =            Farinacci, D., Li, T. and A. Conta= , "MPLS Label Stack
             = ;    Encoding", RFC 3032, January 2001.

   = [MPLS-LM-DM]  Frost, D., Bryant, S., "Packet Loss and Delay
&n= bsp;                Measurement for= MPLS Networks", RFC 6374, September
        &n= bsp;        2011.

   [MPLS-OAM]  =  Nadeau, T., Morrow, M., Swallow, G., Allan, D.,
    &nb= sp;            Matsushima, S., "Operatio= ns and Management (OAM)
             =    Requirements for Multi-Protocol Label Switched (MPLS)
&nbs= p;                Networks", R= FC 4377, February 2006.

   [MPLS-OAM-FW] Allan, D., Nadeau= , T., "A Framework for Multi-Protocol
        &= nbsp;        Label Switching (MPLS) Operations and Mana= gement
                 (OA= M)", RFC 4378, February 2006.

   [MPLS-P2MP]   Y= asukawa, S., Farrel, A., King, D., Nadeau, T.,
      &nbs= p;          "Operations and Management (OAM) = Requirements for
               =  Point-to-Multipoint MPLS Networks", RFC 4687,
    =              September 2006.

&nbs= p;  [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requiremen= ts for
                 OAM= in MPLS Transport Networks", RFC 5860, May 2010.

   = [NetTerms]    Jacobsen, O., Lynch, D., "A Glossary of Networ= king
                 Terms= ", RFC 1208, March 1991.

   [NetTools]    E= nger, R., Reynolds, J., "FYI on a Network Management
    =              Tool Catalog: Tools for Mon= itoring and Debugging
              &= nbsp;  TCP/IP Internets and Interconnected Devices", RFC
 = ;                1470, June 1993.
   [OAM-Analys]  Sprecher, N., Fang, L., "An Over= view of the OAM Tool
              &n= bsp;  Set for  MPLS based Transport Networks", RFC 6669,
=                  July 2012.
   [OAM-Def]     Andersson, L., Van Helvoort, H., = Bonica, R., Romascanu,
              =    D., Mansfield, S., "Guidelines for the use of the OAM
=                  acronym in th= e IETF ", RFC 6291, June 2011.

   [OAM-Label]   = Ohta, H., "Assignment of the 'OAM Alert Label' for
    &n= bsp;            Multiprotocol Label Switching= Architecture (MPLS)
              &n= bsp;  Operation and Maintenance (OAM) Functions", RFC 3429,
&n= bsp;                November 2002.<= br>



Mizrahi, et al.         Expires July= 9, 2014                 [Page 38]<= br>Internet-Draft          Overview of OAM Tools &= nbsp;           January 2014


  &nb= sp;[OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPL= S
                 On-Deman= d Connectivity Verification and Route
         =        Tracing", RFC 6426, November 2011.

=    [OWAMP]       Shalunov, S., Teitelbaum, B., Kar= p, A., Boote, J., and
              &= nbsp;  Zekauskas, M., "A One-way Active Measurement Protocol
&= nbsp;                (OWAMP)",= RFC 4656, September 2006.

   [PARIS]      = Brice Augustin, Timur Friedman and Renata Teixeira,
     = ;            "Measuring Load-balanced Pa= ths in the Internet", IMC,
           = ;      2007.

   [PM-CONS]     Cla= rk, A. and B. Claise, "Guidelines for Considering
    &nb= sp;            New Performance Metric Develop= ment", BCP 170, RFC
             = ;    6390, October 2011.

   [PW-ACH]   &nbs= p;  Bryant, S., Swallow, G., Martini, L., McPherson, D.,
  &nb= sp;              "Pseudowire Emulat= ion Edge-to-Edge (PWE3) Control Word
          =        for Use over an MPLS PSN", RFC 4385, Februa= ry 2006.

   [PW-G-ACh]    Li, H., Martini, L., H= e, J., Huang, F., "Using the
          &nb= sp;      Generic Associated Channel Label for Pseudowire in = the
                 MPLS T= ransport Profile (MPLS-TP)", RFC 6423, November
     = ;            2011.

   [PW-MA= P]      Aissaoui, M., Busschbach, P., Martini, L., Morrow, M= .,
                 Nadeau,= T., and Y(J). Stein, "Pseudowire (PW)
        =          Operations, Administration, and Maintenan= ce (OAM)
                 M= essage Mapping", RFC 6310, July 2011.

   [Reorder] &n= bsp;   Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
&nbs= p;                S., and J. Perser= , "Packet Reordering Metrics", RFC
       =          4737, November 2006.

   = ;[Signal]      Yasukawa, S., "Signaling Requirements fo= r Point-to-
                &nbs= p;Multipoint Traffic-Engineered MPLS Label Switched
     =            Paths (LSPs)", RFC 4461, Apr= il 2006.

   [TCPIP-Tools] Kessler, G., Shepard, S., "= A Primer On Internet and
             = ;    TCP/IP Tools and Utilities", RFC 2151, June 1997.
   [TP-CC-CV]    Allan, D., Swallow, G., Drake, J., &= quot;Proactive
                &= nbsp;Connectivity Verification, Continuity Check and Remote
   = ;              Defect indication for MPL= S Transport Profile", RFC
           =      6428, November 2011.




Mizrahi, et al= .         Expires July 9, 2014       &nb= sp;         [Page 39]
Internet-Draft     &= nbsp;    Overview of OAM Tools          =   January 2014


   [TP-Fault]    Swallo= w, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
      &= nbsp;          "MPLS Fault Management Operati= ons, Administration, and
             = ;    Maintenance (OAM)", RFC 6427, November 2011.

&nb= sp;  [TP-LM-DM]    Frost, D., Bryant, S., "A Packet Los= s and Delay
                &nbs= p;Measurement Profile for MPLS-Based Transport
      &nbs= p;          Networks", RFC 6375, September 20= 11.

   [TP-OAM-FW]   Busi, I., Allan, D., "Opera= tions, Administration and
            &nbs= p;    Maintenance Framework for MPLS-based Transport
  &n= bsp;              Networks ", RFC 6= 371, September 2011.

   [TP-Term]     Van Helvoo= rt, H., Andersson, L., Sprecher, N., "A
       =          Thesaurus for the Terminology used in MP= LS Transport
                &nb= sp;Profile (MPLS-TP) Internet-Drafts and RFCs in the
     = ;            Context of the ITU-T's Transport= Network
                 R= ecommendations", RFC 7087, December 2013.

   [TRILL-O= AM]   Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve,
 =                R., "Requireme= nts for Operations, Administration, and
        &nbs= p;        Maintenance (OAM) in Transparent Interconnect= ion of
                 Lot= s of Links (TRILL)", RFC 6905, March 2013.

   [TWAMP]=       Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and=
                 Babiarz, = J., "A Two-Way Active Measurement Protocol
      &nb= sp;          (TWAMP)", RFC 5357, October 2008= .

   [VCCV]        Nadeau, T., Pignata= ro, C., "Pseudowire Virtual Circuit
        &nb= sp;        Connectivity Verification (VCCV): A Control = Channel
                 fo= r Pseudowires", RFC 5085, December 2007.

   [VCCV-SUR= VEY] Del Regno, N., Malis, A., "The Pseudowire (PW) and
  &nbs= p;              Virtual Circuit Connecti= vity Verification (VCCV)
             = ;    Implementation Survey Results", RFC 7079, November
&= nbsp;                2013.

<= br>
Appendix A.                 = List of OAM Documents

A.1. List of IETF OAM Documents

  =  Table 5 summarizes the OAM related RFCs published by the IETF.
   It is important to note that the table lists various RFCs tha= t are
   different by nature. For example, some of these docum= ents define OAM
   tools or OAM protocols (or both), while oth= ers define protocols that


Mizrahi, et al.       &= nbsp; Expires July 9, 2014              =   [Page 40]
Internet-Draft          Overv= iew of OAM Tools             January 2014
=

   are not strictly OAM-related, but are used by OAM tool= s. The table
   also includes RFCs that define the requirement= s or the framework of
   OAM in a specific context (e.g., MPLS= -TP).

   The RFCs in the table are categorized in a few se= ts as defined in
   Section 1.3.

   +--------= ---+--------------------------------------+----------+
   | To= olset   | Title                = ;                | RFC    = ;  |
   +-----------+------------------------------------= --+----------+
   |IP Ping    | Requirements for Int= ernet Hosts --   | RFC 1122 |
   |       &= nbsp;   | Communication Layers [IntHost]       |  =        |
   |        =   +--------------------------------------+----------+
   = ;|           | A Glossary of Networking Terms &nbs= p;     | RFC 1208 |
   |        =   | [NetTerms]                = ;           |          |<= br>   |           +---------------------= -----------------+----------+
   |        =   | Internet Control Message Protocol    | RFC 792  |<= br>   |           | [ICMPv4]   &nbs= p;                     &n= bsp;   |          |
   |   =         +--------------------------------------+-------= ---+
   |           | Internet Contro= l Message Protocol    | RFC 4443 |
   |    = ;       | (ICMPv6) for the Internet Protocol   |  =        |
   |        =   | Version 6 (IPv6) Specification       |   &nbs= p;      |
   |         &nbs= p; | [ICMPv6]                  = ;           |          |<= br>   +-----------+--------------------------------------+-------= ---+
   |IP         | A Primer On Internet= and TCP/IP      | RFC 2151 |
   |Traceroute | = Tools and Utilities [TCPIP-Tools]    |        = ;  |
   |           +-----------= ---------------------------+----------+
   |     &nb= sp;     | FYI on a Network Management Tool     | RFC 14= 70 |
   |           | Catalog: Tools = for Monitoring and    |          |
&n= bsp;  |           | Debugging TCP/IP Internet= s and       |          |
  =  |           | Interconnected Devices [NetToo= ls]    |          |
   | &n= bsp;         +--------------------------------------+--= --------+
   |           | Internet C= ontrol Message Protocol    | RFC 792  |
   | &n= bsp;         | [ICMPv4]         &nb= sp;                   |  =        |
   |        =   +--------------------------------------+----------+
   = ;|           | Internet Control Message Protocol &= nbsp;  | RFC 4443 |
   |         &nbs= p; | (ICMPv6) for the Internet Protocol   |        = ;  |
   |           | Version 6 = (IPv6) Specification       |         &nb= sp;|
   |           | [ICMPv6]  =                     &nbs= p;     |          |
   | &n= bsp;         +--------------------------------------+--= --------+
   |           | Extended I= CMP to Support Multi-Part  | RFC 4884 |
   |    = ;       | Messages [ICMP-MP]         &nb= sp;         |          |

Mizrahi, et al.         Expires July 9, 2014 &nbs= p;               [Page 41]
Internet-D= raft          Overview of OAM Tools     =         January 2014


   |   &= nbsp;       +--------------------------------------+--------= --+
   |           | Extending ICMP f= or Interface and     | RFC 5837 |
   |    =       | Next-Hop Identification [ICMP-Int]   |   =        |
   +-----------+-----------------= ---------------------+----------+
   |BFD      =  | Bidirectional Forwarding Detection   | RFC 5880 |
  &= nbsp;|           | [BFD]       &nbs= p;                     &n= bsp;  |          |
   |   &= nbsp;       +--------------------------------------+--------= --+
   |           | Bidirectional Fo= rwarding Detection   | RFC 5881 |
   |     &nbs= p;     | (BFD) for IPv4 and IPv6 (Single Hop) |     &nb= sp;    |
   |           | [= BFD-IP]                   &nbs= p;         |          |
&nb= sp;  |           +---------------------------= -----------+----------+
   |          = ; | Generic Application of Bidirectional | RFC 5882 |
   | &nb= sp;         | Forwarding Detection [BFD-Gen]   &nb= sp;   |          |
   |   &= nbsp;       +--------------------------------------+--------= --+
   |           | Bidirectional Fo= rwarding Detection   | RFC 5883 |
   |     &nbs= p;     | (BFD) for Multihop Paths [BFD-Multi] |     &nb= sp;    |
   |           +--= ------------------------------------+----------+
   |   &= nbsp;       | Bidirectional Forwarding Detection   | RF= C 5884 |
   |           | for MPLS La= bel Switched Paths (LSPs) |          |
  &= nbsp;|           | [BFD-LSP]       =                      = ;|          |
   |     &nbs= p;     +--------------------------------------+----------+
&nb= sp;  |           | Bidirectional Forwarding D= etection   | RFC 5885 |
   |         =   | for the Pseudowire Virtual Circuit   |       &= nbsp;  |
   |           | Connec= tivity Verification (VCCV)     |         &nbs= p;|
   |           | [BFD-VCCV]  = ;                     &nb= sp;   |          |
   +---------= --+--------------------------------------+----------+
   |MPLS= OAM   | Operations and Management (OAM)      | RFC 437= 7 |
   |           | Requirements for= Multi-Protocol Label|          |
   = |           | Switched (MPLS) Networks [MPLS-OAM] =  |          |
   |    =       +--------------------------------------+----------+   |           | A Framework for Multi= -Protocol       | RFC 4378 |
   |    =       | Label Switching (MPLS) Operations    | &n= bsp;        |
   |       &n= bsp;   | and Management (OAM) [MPLS-OAM-FW]   |     &nb= sp;    |
   |           +--= ------------------------------------+----------+
   |   &= nbsp;       | Detecting Multi-Protocol Label     &= nbsp; | RFC 4379 |
   |           | S= witched (MPLS) Data Plane Failures  |         &nbs= p;|
   |           | [LSP-Ping]  = ;                     &nb= sp;   |          |
   |   &= nbsp;       +--------------------------------------+--------= --+
   |           | Operations and M= anagement (OAM)      | RFC 4687 |
   |   &= nbsp;       | Requirements for Point-to-Multipoint |   =        |
   |         =   | MPLS Networks [MPLS-P2MP]            = ;|          |


Mizrahi, et al.   &n= bsp;     Expires July 9, 2014           =       [Page 42]
Internet-Draft        = ;  Overview of OAM Tools             Jan= uary 2014


   |           +---= -----------------------------------+----------+
   |   &n= bsp;       | ICMP Extensions for Multiprotocol    = | RFC 4950 |
   |           | Label S= witching [ICMP-Ext]           |     &nbs= p;    |
   +-----------+----------------------------= ----------+----------+
   |MPLS-TP    | Requirements= for OAM in MPLS-TP      | RFC 5860 |
   |OAM &= nbsp;      | [MPLS-TP-OAM]          = ;              |       &n= bsp;  |
   |           +--------= ------------------------------+----------+
   |     =       | MPLS Generic Associated Channel      = | RFC 5586 |
   |           | [G-ACh]=                     &nbs= p;        |          |
&nbs= p;  |           +----------------------------= ----------+----------+
   |          = | MPLS-TP OAM Framework               &= nbsp;| RFC 6371 |
   |           | [T= P-OAM-FW]                   &n= bsp;      |          |
  &n= bsp;|           +---------------------------------= -----+----------+
   |           | Pr= oactive Connectivity Verification, | RFC 6428 |
   |   &n= bsp;       | Continuity Check, and Remote Defect  | &nb= sp;        |
   |       &nb= sp;   | Indication for the MPLS Transport    |    =      |
   |          = | Profile [TP-CC-CV]               &nbs= p;   |          |
   |   &n= bsp;       +--------------------------------------+---------= -+
   |           | MPLS On-Demand Co= nnectivity          | RFC 6426 |
   |=           | Verification and Route Tracing  =     |          |
   | &nbs= p;         | [OnDemand-CV]         =                |     &nbs= p;    |
   |           +---= -----------------------------------+----------+
   |   &n= bsp;       | MPLS Fault Management Operations,    = | RFC 6427 |
   |           | Adminis= tration, and Maintenance (OAM)|          |
&nbs= p;  |           | [TP-Fault]     &n= bsp;                     = |          |
   |      = ;     +--------------------------------------+----------+
&nbs= p;  |           | MPLS Transport Profile Lock= Instruct | RFC 6435 |
   |          = | and Loopback Functions [Lock-Loop]   |         =  |
   |           +-------------= -------------------------+----------+
   |      = ;     | Packet Loss and Delay Measurement for| RFC 6374 |
&nbs= p;  |           | MPLS Networks [MPLS-LM-DM] =           |          |   |           +-----------------------= ---------------+----------+
   |         &= nbsp; | A Packet Loss and Delay Measurement  | RFC 6375 |
  &n= bsp;|           | Profile for MPLS-Based Transport=     |          |
   | &nbs= p;         | Networks [TP-LM-DM]       &= nbsp;          |          = ;|
   +-----------+--------------------------------------+----= ------+
   |Pseudowire | Pseudowire Virtual Circuit   &nb= sp;       | RFC 5085 |
   |OAM     &n= bsp;  | Connectivity Verification (VCCV):    |    =      |
   |          = | A Control Channel for Pseudowires    |       &n= bsp;  |
   |           | [VCCV] =                      = ;         |          |
&nbs= p;  |           +----------------------------= ----------+----------+


Mizrahi, et al.       &nbs= p; Expires July 9, 2014               &n= bsp; [Page 43]
Internet-Draft          Overview= of OAM Tools             January 2014

   |           | Bidirectional Forw= arding Detection   | RFC 5885 |
   |      =     | for the Pseudowire Virtual Circuit   |     =      |
   |           = | Connectivity Verification (VCCV)     |       &nb= sp;  |
   |           | [BFD-VCC= V]                     &n= bsp;     |          |
   | =           +--------------------------------------+= ----------+
   |           | Using th= e Generic Associated Channel | RFC 6423 |
   |     &= nbsp;     | Label for Pseudowire in the MPLS     | &nbs= p;        |
   |       &nbs= p;   | Transport Profile (MPLS-TP)          |=          |
   |      =     | [PW-G-ACh]              = ;             |         &= nbsp;|
   |           +--------------= ------------------------+----------+
   |      =     | Pseudowire (PW) Operations,         &n= bsp;| RFC 6310 |
   |           | Adm= inistration, and Maintenance (OAM)|          |
=    |           | Message Mapping [PW-MAP= ]             |         &= nbsp;|
   +-----------+--------------------------------------+= ----------+
   |OWAMP and  | A One-way Active Measurement= Protocol| RFC 4656 |
   |TWAMP      | [OWAMP] =                      = ;        |          |
 = ;  |           +-----------------------------= ---------+----------+
   |           = | A Two-Way Active Measurement Protocol| RFC 5357 |
   |  = ;         | [TWAMP]           =                    | &nbs= p;        |
   |       &nbs= p;   +--------------------------------------+----------+
  &nb= sp;|           | Framework for IP Performance Metr= ics | RFC 2330 |
   |           | [IP= PM-FW]                    = ;        |          |
 = ;  |           +-----------------------------= ---------+----------+
   |           = | IPPM Metrics for Measuring           | RFC 2678 = |
   |           | Connectivity [IPPM= -Con]              |      = ;    |
   |           +----= ----------------------------------+----------+
   |   &nb= sp;       | A One-way Delay Metric for IPPM     &n= bsp;| RFC 2679 |
   |           | [IP= PM-1DM]                   &nbs= p;       |          |
  &nb= sp;|           +----------------------------------= ----+----------+
   |           | A O= ne-way Packet Loss Metric for IPPM| RFC 2680 |
   |   &nb= sp;       | [IPPM-1LM]           &n= bsp;               |      = ;    |
   |           +----= ----------------------------------+----------+
   |   &nb= sp;       | A Round-trip Delay Metric for IPPM   | RFC = 2681 |
   |           | [IPPM-2DM] &n= bsp;                     =     |          |
   |  = ;         +--------------------------------------+-----= -----+
   |           | Packet Reorde= ring Metrics            | RFC 4737 |
 = ;  |           | [Reorder]     &nbs= p;                     &n= bsp;|          |
   |     &= nbsp;     +--------------------------------------+----------+
=    |           | A One-Way Packet Duplic= ation Metric  | RFC 5560 |
   |       &nbs= p;   | [Dup]                 &= nbsp;              |      = ;    |
   +-----------+-----------------------------= ---------+----------+


Mizrahi, et al.        = ; Expires July 9, 2014               &nb= sp; [Page 44]
Internet-Draft          Overview = of OAM Tools             January 2014

=
   |TRILL OAM  | Requirements for Operations,   &nb= sp;     | RFC 6905 |
   |        = ;   | Administration, and Maintenance (OAM)|       &nbs= p;  |
   |           | in Transp= arent Interconnection of    |          |=
   |           | Lots of Links (TRIL= L)                |     &= nbsp;    |
   +-----------+-------------------------= -------------+----------+
            &nbs= p;    Table 5 Summary of IETF OAM Related RFCs

A.2. List o= f Selected Non-IETF OAM Documents

   In addition to the OA= M tools defined by the IETF, the IEEE and ITU-T
   have also d= efined various OAM tools that focus on Ethernet, and
   variou= s other transport network environments. These various tools,
  &nbs= p;defined by the three standard organizations, are often tightly
  =  coupled, and have had a mutual effect on each other. The ITU-T and   IETF have both defined OAM tools for MPLS LSPs, [ITU-T-Y1711]= and
   [LSP-Ping]. The following OAM standards by the IEEE an= d ITU-T are to
   some extent linked to IETF OAM tools listed = above and are mentioned
   here only as reference material:
   o OAM tools for Layer 2 have been defined by the ITU-T in=
      [ITU-T-Y1731], and by the IEEE in 802.1ag [IEEE802= .1Q] . The IEEE
      802.3 standard defines OAM for one-= hop Ethernet links
      [IEEE802.3ah].

  &nb= sp;o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and
 = ;     MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2].

&nbs= p;  It should be noted that these non-IETF documents deal in many case= s
   with OAM functions below the IP layer (Layer 2, Layer 2.5= ) and in
   some cases operators use a multi-layered OAM appro= ach, which is a
   function of the way their networks are desi= gned.

   Table 6 summarizes some of the main OAM standards= published by non-
   IETF standard organizations. This docume= nt focuses on IETF OAM
   standards, but these non-IETF standa= rds are referenced in this
   document where relevant.

=    +-----------+--------------------------------------+----------= -----+
   |           | Title   =                      = ;        |Standard/Draft |
   +-----------= +--------------------------------------+---------------+
   |I= TU-T      | Operation & Maintenance mechanism   &nb= sp;| ITU-T Y.1711  |
   |MPLS OAM   | for MPLS netwo= rks [ITU-T-Y1711]      |           =     |
   |           +-----= ---------------------------------+---------------+
   |  =         | Assignment of the 'OAM Alert Label'  | = RFC 3429      |
   |        = ;   | for Multiprotocol Label Switching    |     &= nbsp;         |


Mizrahi, et al.    = ;     Expires July 9, 2014           &nb= sp;     [Page 45]
Internet-Draft         &= nbsp;Overview of OAM Tools             Januar= y 2014


   |           | Archi= tecture (MPLS) Operation and    |         &nb= sp;     |
   |           | = Maintenance (OAM) Functions          |   &nbs= p;           |
   |     &nb= sp;     | [OAM-Label]             &= nbsp;            |        = ;       |
   |         &nbs= p; |                     =                  |   &nbs= p;           |
   |     &nb= sp;     |  Note: although this is an IETF     &nbs= p;|               |
   | &n= bsp;         |  document, it is listed as one of t= he|               |
   | &n= bsp;         |  non-IETF OAM standards, since it &= nbsp;  |               |
  =  |           |  was defined as a complem= entary part |               |
  =  |           |  of ITU-T Y.1711.   =                  |   &nbs= p;           |
   +-----------+------= --------------------------------+---------------+
   |ITU-T &n= bsp;    | Operations, administration and       |IT= U-T G.8113.2 |
   |MPLS-TP OAM| Maintenance mechanisms for MPL= S-TP   |               |
  =  |           | networks using the tools defin= ed for |               |
   = ;|           | MPLS [ITU-G8113.2]     &n= bsp;             |        = ;       |
   |         &nbs= p; |                     =                  |   &nbs= p;           |
   |     &nb= sp;     |  Note: this document describes the   |  =             |
   |    = ;       |  OAM toolset defined by the IETF for |  =             |
   |    = ;       |  MPLS-TP, whereas ITU-T G.8113.1    = ; |               |
   | &n= bsp;         |  describes the OAM toolset defined =   |               |
   = ;|           |  by the ITU-T.     &= nbsp;                 |   &nbs= p;           |
   |     &nb= sp;     +--------------------------------------+---------------+<= br>   |           | Operations, Administ= ration and       |ITU-T G.8113.1 |
   |   =         | Maintenance mechanism for MPLS-TP in |  =             |
   |    = ;       | Packet Transport Network (PTN)      = ; |               |
   | &n= bsp;         +--------------------------------------+--= -------------+
   |           | Alloc= ation of a Generic Associated   | RFC 6671      |
&n= bsp;  |           | Channel Type for ITU-T MP= LS Transport|               |
  =  |           | Profile Operation, Maintenance= , and  |               |
  =  |           | Administration (MPLS-TP OAM) &= nbsp;       |             &nbs= p; |
   |           | [ITU-T-CT] &nbs= p;                     &n= bsp;   |               |
  =  |           |         &n= bsp;                     =        |             &nbs= p; |
   |           |  Note: alt= hough this is an IETF      |         &nb= sp;     |
   |           | =  document, it is listed as one of the|         &nb= sp;     |
   |           | =  non-IETF OAM standards, since it    |       =         |
   |        =   |  was defined as a complementary part |       =         |
   |        =   |  of ITU-T G.8113.1.            = ;      |               |<= br>   +-----------+--------------------------------------+-------= --------+
   |ITU-T      | OAM Functions and Me= chanisms for     | ITU-T Y.1731  |
   |Ethernet=   | Ethernet-based Networks            =  |               |
   = ;|OAM        | [ITU-T-Y1731]        = ;                |     &n= bsp;         |
   +-----------+-----------= ---------------------------+---------------+


Mizrahi, et al. &nb= sp;       Expires July 9, 2014         &= nbsp;       [Page 46]
Internet-Draft      =    Overview of OAM Tools           &nbs= p; January 2014


   |IEEE       | Connec= tivity Fault Management        | IEEE 802.1ag  |   |CFM        | [IEEE802.1Q]    =                     | &n= bsp;             |
   |   &= nbsp;       |             &nbs= p;                     &n= bsp;  |               |
  &= nbsp;|           |  Note: CFM was originally = published  |               |
&nb= sp;  |           |  as IEEE 802.1ag, but= is now         |           &n= bsp;   |
   |           |  = incorporated in the 802.1Q standard.|           &n= bsp;   |
   +-----------+--------------------------------= ------+---------------+
   |IEEE       | Manage= ment of Data Driven and Data   | IEEE 802.1ag  |
   = |DDCFM      | Dependent Connectivity Faults     &n= bsp;  |               |
  &= nbsp;|           | [IEEE802.1Q]     &nbs= p;                   |   =             |
   |    =       |               &n= bsp;                     =  |               |
   = |           |  Note: DDCFM was originally pub= lished|               |
   = |           |  as IEEE 802.1Qaw, but is now &= nbsp;      |              = ; |
   |           |  incorporat= ed in the 802.1Q standard.|              = ; |
   +-----------+--------------------------------------+---= ------------+
   |IEEE       | Media Access Con= trol Parameters,     | IEEE 802.3ah  |
   |802.= 3      | Physical Layers, and Management      = ;|               |
   |link= level | Parameters for Subscriber Access     |     &nb= sp;         |
   |OAM      =  | Networks [IEEE802.3ah]             &= nbsp; |               |
   = |           |           &= nbsp;                    =      |               |   |           |  Note: link leve= l OAM was originally |               |   |           |  defined in IEEE= 802.3ah, and is now |               |   |           |  incorporated in= the 802.3 standard. |               |   +-----------+--------------------------------------+--------= -------+
         Table 6 Non-IETF OAM Standard= s Mentioned in this Document



Authors' Addresses

 = ;  Tal Mizrahi
   Marvell
   6 Hamada St.   Yokneam, 20692
   Israel

   Ema= il: talmi@marvell.com

=
   Nurit Sprecher
   NSN
   3 Hanag= ar St. Neve Ne'eman B



Mizrahi, et al.       &= nbsp; Expires July 9, 2014              =   [Page 47]
Internet-Draft          Overv= iew of OAM Tools             January 2014
=

   Hod Hasharon,   45241
   Israel
<= br>   Email: nurit= .sprecher@nsn.com


   Elisa Bellagamba
  &n= bsp;Ericsson
   6 Farogatan St.
   Stockholm, &nb= sp; 164 40
   Sweden

   Phone: +46 761440785<= br>   Email: elisa.bellagamba@ericsson.com


   Yaacov Weingart= en
   34 Hagefen St.
   Karnei Shomron,   44= 85500
   Israel

   Email: wyaacov@gmail.com
























Mizrahi, et al.         Expires July 9, 2014   &= nbsp;             [Page 48]=

 

 

On Jul 8,= 2013:5:43 PM, at 5:43 PM, Tal Mizrahi <talmi@marvell.com> wrote:



Hi,

 

We have updated draft-ietf-opsawg-oam-overview following the comments= we received in IETF last call.

&n= bsp;

This document went into = IETF last call in January, and we received comments from (in chronological = order): Benoit Claise, Al Morton, Sam Aldrin, Tom Nadeau, Carlos Pignataro,= Elwyn Davies, Sasha Vainshtein, Dan Romascanu, Thomas Narten, Joel Jaeggli= .

We carefully considered eac= h and every comment, and significantly edited the document to address these= comments.

After we revised t= he document some of our reviewers kindly agreed to reiterate on the documen= t in 1x1 sessions, allowing us to verify that we addressed the major commen= ts.

A brief summary of the ch= anges in the document:

- We p= ractically rewrote the introduction; we added a subsection about the target= audience, and add general background about OAM including some historical b= ackground.

- The structure of= the document went through a significant revision as well; for example, we = moved the list of OAM documents to an appendix, and moved the terminology s= ection closer to the beginning.

- We revised the terminology section: we added quite a few terms that we= re used without definition, and we fixed some inaccurate existing definitio= ns. We also did some major editing throughout the document to verify that t= he terminology is used consistently.

- We added content that was missing in previous version of the draf= t, e.g., TRILL OAM.

 

We encourage the reviewers to g= o over the updated document and let us know if there are any further commen= ts.

Any further comments from= the WG are welcome.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> 

Thanks,

<= /div>

Tal.

 

= --_000_74470498B659FA4687F0B0018C19A89C01D43919C121ILMB01marve_-- From talmi@marvell.com Tue Jan 28 02:08:00 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8083E1A0379 for ; Tue, 28 Jan 2014 02:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.391 X-Spam-Level: * X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9b0Woo_bFvy for ; Tue, 28 Jan 2014 02:07:36 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id D64B41A0258 for ; Tue, 28 Jan 2014 02:07:35 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s0SA7SUC022366; Tue, 28 Jan 2014 02:07:28 -0800 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1hknvxakwb-17 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jan 2014 02:07:25 -0800 Received: from YK-HUB01.marvell.com (10.4.102.51) by SC-OWA.marvell.com (10.93.76.28) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 28 Jan 2014 02:07:21 -0800 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB01.marvell.com ([10.4.102.51]) with mapi; Tue, 28 Jan 2014 12:07:16 +0200 From: Tal Mizrahi To: Thomas Nadeau Date: Tue, 28 Jan 2014 12:07:09 +0200 Thread-Topic: Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC Thread-Index: Ac8V9G+KN1jh8e9QQjS09RgaXdvTlQGAvLGw Message-ID: <74470498B659FA4687F0B0018C19A89C01D43919C122@IL-MB01.marvell.com> References: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> <50F437BF.8040005@cisco.com> <50F972FC.2030707@cisco.com> <6C3490D7-3727-41BA-8980-683DF84451A2@lucidvision.com> In-Reply-To: <6C3490D7-3727-41BA-8980-683DF84451A2@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01D43919C122ILMB01marve_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-28_04:2014-01-27,2014-01-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401280019 Cc: "draft-ietf-opsawg-oam-overview@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 10:08:00 -0000 --_000_74470498B659FA4687F0B0018C19A89C01D43919C122ILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks again for your comments. A link to the updated draft: http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13 We believe the current draft addresses all the comments below. We have replied to every single comment below (search for [TM]). Please let us know if you believe something is still amiss. Thanks, Tal. From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Monday, January 20, 2014 5:29 PM To: Benoit Claise Cc: draft-ietf-opsawg-oam-overview@tools.ietf.org; opsawg@ietf.org; IETF Di= sgust Subject: Re: Last Call: (An Overvie= w of Operations, Administration, and Maintenance (OAM) Mechanisms) to Infor= mational RFC Reviewing the current version of the draft (12), many of the co= mments below are still not addressed. --Tom Here is Tom Nadeau's feedback, forwarded with permission: Regards, Benoit =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some general comments: 1. I did not find any discussion around use of configuration within OAM m= echanisms. This is clearly something that is happening in groups like PWE3 = and CCAMP. The motivation for this should be explained and documented to at= least guide these efforts. [TM] The current draft includes a significantly clearer explanation, up fro= nt in the abstract and introduction, that this document focuses on OAM too= ls, i.e., on the data plane of OAM. That is why, for example we do not disc= uss configuration contexts such as CCAMP. 2. There is no real discussion around the security aspects of these tools. = Should there be? [TM] We received a similar comment from other reviewers, as well as the Sec= Dir review in the previous IETF last call. After some discussion between ou= r AD at the time (Ron Bonica) and the Sec AD (Sean Turner), the current phr= asing of the "Security Considerations" section was agreed. It is mainly an = issue of where you draw the line between which content to include and which= content not to include in the draft, and security is currently out of scop= e. 3. While the document provides a nice taxonomy of various OAM tools, it doe= s not really discuss the techniques for using them. I do not expect anythin= g in detail, but it is not obvious that many of these tools can be orchestr= ated to form a "toolset" that can be used to do multi-layer OAM functions f= or services such as carrier Ethernet over VPLS over MPLS, for example. [TM] Following your comment, we added quite a bit of text to the introducti= on to explain this multi-layer orchestration. You can take full credit for = the fact that this doll IETF draft now includes an ASCII art figure (Figure= 1). :) 4. It might be useful to at least mention in the performance metrics sectio= n, a discussion around the accuracy of these tools and how it depends on sc= ale, implementation and network configurations. [TM] Following your comment we added a note about this in section 4.7.1. Se= e the paragraphs beginning with "It should be noted that while [OWAMP]...". My detailed comments inline starting with TOM: --Tom Expires: July 2013 Nokia Siemens Networks E. Bellagamba Ericsson Y. Weingarten January 9, 2013 An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms draft-ietf-opsawg-oam-overview-08.txt Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2013. Mizrahi, et al. Expires July 9, 2013 [Page 1] Internet-Draft Overview of OAM Mechanisms January 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 3 1.1. The Building Blocks of OAM .............................. 3 1.2. Forwarding Plane vs. Management Plane ................... 4 1.3. The OAM toolsets ........................................ 4 1.4. IETF OAM Documents ...................................... 6 1.5. Non-IETF OAM Documents ................................. 10 2. Basic Terminology ........................................... 12 2.1. Abbreviations .......................................... 12 2.2. Terminology used in OAM Standards ...................... 13 2.2.1. General Terms ..................................... 13 2.2.2. OAM Maintenance Entities .......................... 13 2.2.3. OAM Maintenance Points ............................ 14 2.2.4. Proactive and On-demand activation ................ 15 2.2.5. Connectivity Verification and Continuity Checks ... 15 2.2.6. Failures .......................................... 15 3. OAM Tools ................................................... 16 3.1. IP Ping and Traceroute ................................. 16 3.1.1. Ping .............................................. 16 3.1.2. Traceroute......................................... 16 3.2. Bidirectional Forwarding Detection (BFD) ............... 17 3.2.1. Overview .......................................... 17 3.2.2. BFD Control ....................................... 17 3.2.3. BFD Echo .......................................... 18 3.3. MPLS OAM ............................................... 18 3.4. MPLS-TP OAM ............................................ 19 3.4.1. Overview .......................................... 19 3.4.2. Generic Associated Channel ........................ 19 3.4.3. MPLS-TP OAM Toolset ............................... 20 3.4.3.1. Continuity Check and Connectivity Verification 20 Mizrahi, et al. Expires July 9, 2013 [Page 2] Internet-Draft Overview of OAM Mechanisms January 2013 3.4.3.2. Route Tracing ................................ 21 3.4.3.3. Lock Instruct ................................ 21 3.4.3.4. Lock Reporting ............................... 21 3.4.3.5. Alarm Reporting .............................. 21 3.4.3.6. Remote Defect Indication ..................... 22 3.4.3.7. Client Failure Indication .................... 22 3.4.3.8. Packet Loss Measurement (LM) ................. 22 3.4.3.9. Packet Delay Measurement (DM) ................ 22 3.5. PWE3 OAM ............................................... 23 3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV) ................................................... 23 3.5.2. PWE3 OAM using G-ACh .............................. 24 3.6. OWAMP and TWAMP......................................... 24 3.6.1. Overview .......................................... 24 3.6.2. Control and Test Protocols ........................ 24 3.6.3. OWAMP ............................................. 25 3.6.4. TWAMP ............................................. 26 3.7. Summary of OAM Functions ............................... 26 4. Security Considerations ..................................... 27 5. IANA Considerations ......................................... 27 6. Acknowledgments ............................................. 27 7. References .................................................. 28 7.1. Normative References ................................... 28 7.2. Informative References ................................. 31 1. Introduction OAM is a general term that refers to a toolset for detecting, isolating and reporting connection failures and performance degradation. This document summarizes the OAM tools and mechanisms defined in the IETF. The term OAM in this document refers to Operations, Administration and Maintenance [OAM-Def], focusing on the forwarding plane of OAM. Hence, management aspects are outside the scope of this document. TOM: This is a curious sentence to me since to me, OAM is management, or a = subset of it. Also, if you look at the referenced documents, there are ma= ny indirect references to MIBs, Netconf, etc... making this sentence furthe= r confusing. It might be helpful to explain more clearly that the authors h= ere intended to not cover those things explicitly rather than grouping them= arbitrarily under the definition of "management aspects" Further, to clar= ify, it might be useful to expand on what "forwarding plane" is here just t= o be clear. That is, is this "in band" or "out-of band" or both? Some of = the tools referred to here also are part of the control AND data planes. [TM] We significantly improved the distinction between the different planes= : data plane, control plane, management plane. We added a definition of eac= h of the terms, and we now explicitly explain that the draft focuses on the= data plane. We also explain in the current draft that we adopt the OAM acr= onym as recommended in RFC 6291: Operations, Administration and Maintenance= (without Management...). Please let us know if you think something is stil= l missing here. 1.1. The Building Blocks of OAM An OAM protocol is run in the context of a Maintenance Domain, consisting of two or more nodes that run the OAM protocol, referred to as Maintenance Points (MP). This subsection provides a brief summary of the common tools used by OAM protocols. An OAM protocol typically supports one or more of the tools described below. Mizrahi, et al. Expires July 9, 2013 [Page 3] Internet-Draft Overview of OAM Mechanisms January 2013 o Continuity Checking (CC): Used for verifying the liveness of a connection between two MPs. o Connectivity Verification (CV): Allows an MP to check whether it is connected to a peer MP, and to verify that messages from the peer MP are received through the expected path. o Path Discovery / Fault Localization: An MP uses this mechanism to trace the route to a peer MP, i.e., to identify the nodes along the path to the peer MP. When a connection fails, this mechanism also allows the MP to detect the location of the failure. TOM: The definition calls this "path discovery" but then talks about tracin= g routes. A better way of describing this in the paragraph would be that th= ere I a use of path tracing in order to discover (or re-discover) paths tha= t have been changed, created or destroyed. [TM] We rephrased this paragraph, and hopefully it is clearer and more accu= rate now. o Performance Monitoring: Consists of 3 main functions o Loss Measurement (LM) - monitors the packet loss rate of a connection. o Delay Measurement (DM) - monitors the delay and delay variation between MPs. o Throughput measurement - monitors the throughput of a connection. TOM: Along with the discussion above around path trace/discovery, it is imp= erative that paths be discovered (one way or another) in order to successfu= lly d performance monitoring on those paths. [TM] True. However this section presents a short list of typical OAM functi= ons, and we would rather stick with succinct descriptions in this section. 1.2. Forwarding Plane vs. Management Plane While the OAM tools may, and quite often do, work in conjunction with a control-plane or management plane, they are usually defined to be independent of the control-plane. The OAM tools communicate with the management plane to raise alarms, and often the on-demand tools may be activated by the management, e.g. to locate and localize problems. The considerations of the control-plane maintenance tools or the functionality of the management-plane are out of scope for this document, which will concentrate on presenting the forwarding-plane tools that are used for OAM. TOM: What about the data plane? For example, the GACH OAM type is such an e= xample. VCCV also operates within the data plane after its configuration ca= pabilities have been signaled. It should also be mentioned that it is impe= rative that when required, OAM tools are capable of testing the actual data= plane in as much accuracy as possible, but that they all should note how a= ccurate. Not all OAM tools are created equal. [TM] We rephrased this subsection, and now have a much clearer definition o= f each plane in "2.2.4. Data Plane, Control Plane and Management Plane". We= also added specific text about the importance of fate-sharing (see section= 1.4), which addresses the second part of your comment. 1.3. The OAM toolsets This memo provides an overview of the different sets of OAM mechanisms defined by the IETF. It is intended for those with little or no familiarity with the described mechanisms. The set of OAM mechanisms described in this memo are applicable to IP unicast, MPLS, pseudowires, and MPLS for the transport environment (MPLS-TP). While OAM mechanisms that are applicable to other technologies exist, they Mizrahi, et al. Expires July 9, 2013 [Page 4] Internet-Draft Overview of OAM Mechanisms January 2013 are beyond the scope of this memo. This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM- related work is outside the scope. The IETF has defined OAM protocols and mechanisms in several different fronts: o IP Ping and Traceroute: Ping is a very simple and common application for failure diagnosis TOM: I am not sure the term "common" is necessary. [TM] Removed. that uses ICMP Echo requests, as defined in [ICMPv4], and [ICMPv6]. Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to trace the path between an IP source and an IP destination, i.e., to identify the nodes along the path. o BFD: Bidirectional Forwarding Detection (BFD) is defined in [BFD] as a framework for a lightweight generic OAM mechanism. The intention is to define a base mechanism that can be used with various encapsulation types, network environments, and in various medium types. o MPLS OAM: MPLS LSP Ping, as defined in [MPLS-OAM], [MPLS-OAM-FW] and [LSP- Ping], is an OAM mechanism for point to point MPLS LSPs. It includes two main functions: Ping and Traceroute. o MPLS-TP OAM: MPLS-TP OAM is defined in a set of RFCs. The OAM requirements for MPLS Transport Profile (MPLS-TP) are defined in [MPLS-TP-OAM]. Each of the tools in the OAM toolset is defined in its own RFC, as specified in Section 1.4. o PWE3 OAM: The PWE3 OAM architecture defines control channels that support the use of existing IETF OAM tools to be used for a pseudowire (PW). The control channels that are defined in [VCCV] and [PW-G- ACH] may be used in conjunction with ICMP Ping, LSP Ping, and BFD to perform CC and CV functionality. In addition the channels support use of any of the MPLS-TP based OAM tools for completing their respective OAM functionality for a PW. o OWAMP and TWAMP: The One Way Active Measurement Protocol (OWAMP) and the Two Way Active Measurement Protocols (TWAMP) are two protocols defined in the IP Performance Metrics (IPPM) working group in the IETF. These protocols allow delay and packet loss measurement in IP networks. Mizrahi, et al. Expires July 9, 2013 [Page 5] Internet-Draft Overview of OAM Mechanisms January 2013 This document summarizes the OAM mechanisms defined by the IETF. We first present a comparison of the terminology used in various OAM standards, and then summarize the OAM functions that each OAM standard provides. 1.4. IETF OAM Documents Table 1 summarizes the IETF OAM related RFCs discussed in this document. The table includes a "Type" column, specifying the nature of each of the listed documents: o Tool: documents that define an OAM tool or mechanism. o Prof.: documents that define a profile or a variant for an OAM tool that is defined in other documents. o Inf.: documents that define an infrastructure that is used by OAM tools. o Misc.: other OAM related documents, e.g., OAM requirement and framework documents. +-----------+--------------------------------------+-----+----------+ | | Title |Type | RFC | +-----------+--------------------------------------+-----+----------+ |IP Ping and| Internet Control Message Protocol |Tool | RFC 792 | |Traceroute | [ICMPv4] | | | | +--------------------------------------+-----+----------+ | | Internet Control Message Protocol |Tool | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | | Version 6 (IPv6) Specification | | | | | [ICMPv6] | | | | +--------------------------------------+-----+----------+ | | A Primer On Internet and TCP/IP |Tool | RFC 2151 | | | Tools and Utilities [TCPIP-Tools] | | | | +--------------------------------------+-----+----------+ | | FYI on a Network Management Tool |Tool | RFC 1147 | | | Catalog: Tools for Monitoring and | | | | | Debugging TCP/IP Internets and | | | | | Interconnected Devices [NetTools] | | | | +--------------------------------------+-----+----------+ | | Extended ICMP to Support Multi-Part |Tool | RFC 4884 | Mizrahi, et al. Expires July 9, 2013 [Page 6] Internet-Draft Overview of OAM Mechanisms January 2013 | | Messages [ICMP-MP] | | | | +--------------------------------------+-----+----------+ | | ICMP Extensions for Multiprotocol |Tool | RFC 4950 | | | Label Switching [ICMP-Ext] | | | | +--------------------------------------+-----+----------+ | | Extending ICMP for Interface and |Tool | RFC 5837 | | | Next-Hop Identification [ICMP-Int] | | | +-----------+--------------------------------------+-----+----------+ |BFD | Bidirectional Forwarding Detection |Tool | RFC 5880 | | | [BFD] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5881 | | | (BFD) for IPv4 and IPv6 (Single Hop) | | | | | [BFD-IP] | | | | +--------------------------------------+-----+----------+ | | Generic Application of Bidirectional |Misc.| RFC 5882 | | | Forwarding Detection [BFD-Gen] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5883 | | | (BFD) for Multihop Paths [BFD-Multi] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5884 | | | for MPLS Label Switched Paths (LSPs) | | | | | [BFD-LSP] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | | Connectivity Verification (VCCV) | | | | | [BFD-VCCV] | | | +-----------+--------------------------------------+-----+----------+ |MPLS OAM | Operations and Management (OAM) |Misc.| RFC 4377 | | | Requirements for Multi-Protocol Label| | | | | Switched (MPLS) Networks [MPLS-OAM] | | | | +--------------------------------------+-----+----------+ | | A Framework for Multi-Protocol |Misc.| RFC 4378 | | | Label Switching (MPLS) Operations | | | | | and Management (OAM) [MPLS-OAM-FW] | | | | +--------------------------------------+-----+----------+ | | Detecting Multi-Protocol Label |Tool | RFC 4379 | | | Switched (MPLS) Data Plane Failures | | | | | [LSP-Ping] | | | Mizrahi, et al. Expires July 9, 2013 [Page 7] Internet-Draft Overview of OAM Mechanisms January 2013 | +--------------------------------------+-----+----------+ | | Operations and Management (OAM) |Misc.| RFC 4687 | | | Requirements for Point-to-Multipoint | | | | | MPLS Networks [MPLS-P2MP] | | | +-----------+--------------------------------------+-----+----------+ |MPLS-TP | Requirements for OAM in MPLS-TP |Misc.| RFC 5860 | |OAM | [MPLS-TP-OAM] | | | | +--------------------------------------+-----+----------+ | | MPLS Generic Associated Channel |Inf. | RFC 5586 | | | [G-ACh] | | | | +--------------------------------------+-----+----------+ | | MPLS-TP OAM Framework |Misc.| RFC 6371 | | | [TP-OAM-FW] | | | | +--------------------------------------+-----+----------+ | | Proactive Connectivity Verification, |Tool | RFC 6428 | | | Continuity Check, and Remote Defect | | | | | Indication for the MPLS Transport | | | | | Profile [TP-CC-CV] | | | | +--------------------------------------+-----+----------+ | | MPLS On-Demand Connectivity |Tool | RFC 6426 | | | Verification and Route Tracing | | | | | [OnDemand-CV] | | | | +--------------------------------------+-----+----------+ | | MPLS Fault Management Operations, |Tool | RFC 6427 | | | Administration, and Maintenance (OAM)| | | | | [TP-Fault] | | | | +--------------------------------------+-----+----------+ | | MPLS Transport Profile Lock Instruct |Tool | RFC 6435 | | | and Loopback Functions [Lock-Loop] | | | | +--------------------------------------+-----+----------+ | | Packet Loss and Delay Measurement for|Tool | RFC 6374 | | | MPLS Networks [MPLS-LM-DM] | | | | +--------------------------------------+-----+----------+ | | A Packet Loss and Delay Measurement |Prof.| RFC 6375 | | | Profile for MPLS-Based Transport | | | | | Networks [TP-LM-DM] | | | +-----------+--------------------------------------+-----+----------+ |PWE3 OAM | Pseudowire Virtual Circuit |Inf. | RFC 5085 | | | Connectivity Verification (VCCV): | | | | | A Control Channel for Pseudowires | | | | | [VCCV] | | | Mizrahi, et al. Expires July 9, 2013 [Page 8] Internet-Draft Overview of OAM Mechanisms January 2013 | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | | Connectivity Verification (VCCV) | | | | | [BFD-VCCV] | | | | +--------------------------------------+-----+----------+ | | Using the Generic Associated Channel |Inf. | RFC 6423 | | | Label for Pseudowire in the MPLS | | | | | Transport Profile (MPLS-TP) | | | | | [PW-G-ACh] | | | | +--------------------------------------+-----+----------+ | | Pseudowire (PW) Operations, |Misc.| RFC 6310 | | | Administration, and Maintenance (OAM)| | | | | Message Mapping [PW-Map] | | | +-----------+--------------------------------------+-----+----------+ |OWAMP and | A One-way Active Measurement Protocol|Tool | RFC 4656 | |TWAMP | [OWAMP] | | | | +--------------------------------------+-----+----------+ | | A Two-Way Active Measurement Protocol|Tool | RFC 5357 | | | [TWAMP] | | | | +--------------------------------------+-----+----------+ | | Framework for IP Performance Metrics |Misc.| RFC 2330 | | | [IPPM-FW] | | | | +--------------------------------------+-----+----------+ | | IPPM Metrics for Measuring |Misc.| RFC 2678 | | | Connectivity [IPPM-Con] | | | | +--------------------------------------+-----+----------+ | | A One-way Delay Metric for IPPM |Misc.| RFC 2679 | | | [IPPM-1DM] | | | | +--------------------------------------+-----+----------+ | | A One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 | | | [IPPM-1LM] | | | | +--------------------------------------+-----+----------+ | | A Round-trip Delay Metric for IPPM |Misc.| RFC 2681 | | | [IPPM-2DM] | | | +-----------+--------------------------------------+-----+----------+ Table 1 Summary of IETF OAM Related RFCs Mizrahi, et al. Expires July 9, 2013 [Page 9] Internet-Draft Overview of OAM Mechanisms January 2013 1.5. Non-IETF OAM Documents In addition to the OAM mechanisms defined by the IETF, the IEEE and ITU-T have also defined various OAM mechanisms that focus on Ethernet, and various other transport network environments. These various mechanisms, defined by the three standard organizations, are often tightly coupled, and have had a mutual effect on each other. The ITU-T and IETF have both defined OAM mechanisms for MPLS LSPs, [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to some extent linked to IETF OAM mechanisms listed above and are mentioned here only as reference material: o OAM mechanisms for Ethernet based networks have been defined by both the ITU-T in [ITU-T-Y1731], and by the IEEE in [IEEE802.1ag]. The IEEE 802.3 standard defines OAM for one-hop Ethernet links [IEEE802.3ah]. o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. Table 2 summarizes the OAM standards mentioned in this document. This document focuses on IETF OAM standards, but these non-IETF standards are referenced where relevant. +-----------+--------------------------------------+---------------+ | | Title |Standard/Draft | +-----------+--------------------------------------+---------------+ |ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 | |MPLS OAM | for MPLS networks [ITU-T-Y1711] | | | +--------------------------------------+---------------+ | | Assignment of the 'OAM Alert Label' | RFC 3429 | | | for Multiprotocol Label Switching | | | | Architecture (MPLS) Operation and | | | | Maintenance (OAM) Functions | | | | [OAM-Label] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T Y.1711. | | +-----------+--------------------------------------+---------------+ |ITU-T | Operations, administration and |ITU-T G.8113.2 | |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | | Mizrahi, et al. Expires July 9, 2013 [Page 10] Internet-Draft Overview of OAM Mechanisms January 2013 | | networks using the tools defined for | | | | MPLS [ITU-G8113.2] | | | | | | | | Note: this document describes the | | | | OAM toolset defined by the IETF for | | | | MPLS-TP, whereas ITU-T G.8113.1 | | | | describes the OAM toolset defined | | | | by the ITU-T. | | | +--------------------------------------+---------------+ | | Operations, Administration and |ITU-T G.8113.1 | | | Maintenance mechanism for MPLS-TP in | | | | Packet Transport Network (PTN) | | | +--------------------------------------+---------------+ | | Allocation of a Generic Associated | RFC 6671 | | | Channel Type for ITU-T MPLS Transport| | | | Profile Operation, Maintenance, and | | | | Administration (MPLS-TP OAM) | | | | [ITU-T-CT] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T G.8113.1. | | +-----------+--------------------------------------+---------------+ |ITU-T | OAM Functions and Mechanisms for |[ITU-T-Y1731] | |Ethernet | Ethernet-based Networks | | |OAM | | | +-----------+--------------------------------------+---------------+ |IEEE | Connectivity Fault Management | IEEE 802.1ag | |CFM | [IEEE802.1ag] | | | | | | | | Note: CFM was originally published | | | | as IEEE 802.1ag, but is now | | | | incorporated in the 802.1Q standard.| | +-----------+--------------------------------------+---------------+ |IEEE | Media Access Control Parameters, | IEEE 802.3ah | |802.3 | Physical Layers, and Management | | |link level | Parameters for Subscriber Access | | |OAM | Networks [IEEE802.3ah] | | | | | | Mizrahi, et al. Expires July 9, 2013 [Page 11] Internet-Draft Overview of OAM Mechanisms January 2013 | | Note: link level OAM was originally | | | | defined in IEEE 802.3ah, and is now | | | | incorporated in the 802.3 standard. | | +-----------+--------------------------------------+---------------+ Table 2 Non-IETF OAM Standards Mentioned in this Document 2. Basic Terminology 2.1. Abbreviations ACH Associated Channel Header AIS Alarm Indication Signal BFD Bidirectional Forwarding Detection CC Continuity Check CV Connectivity Verification DM Delay Measurement FEC Forwarding Equivalence Class GAL Generic Associated Label ICMP Internet Control Message Protocol LDP Label Distribution Protocol LM Loss Measurement LSP Label Switched Path ME Maintenance Entity MEG Maintenance Entity Group MEP MEG End Point MIP MEG Intermediate Point MP Maintenance Point MPLS Multiprotocol Label Switching Mizrahi, et al. Expires July 9, 2013 [Page 12] Internet-Draft Overview of OAM Mechanisms January 2013 MPLS-TP MPLS Transport Profile MTU Maximum Transmission Unit OAM Operations, Administration, and Maintenance PW Pseudowire PWE3 Pseudowire Emulation Edge-to-Edge RDI Remote Defect Indication TTL Time To Live VCCV Virtual Circuit Connectivity Verification TOM: Why is this section not at the top of this document, as is customary f= or RFCs? [TM] The introduction is now significantly shorter than it was when you sen= t this comment, which means that the terminology section is now much closer= to the beginning of the document. 2.2. Terminology used in OAM Standards 2.2.1. General Terms A wide variety of terms is used in various OAM standards. Each of the OAM standards listed in the reference section includes a section that defines terms relevant to that tool. A thesaurus of terminology for MPLS-TP terms is presented in [TP-Term], and provides a good summary of some of the OAM related terminology. This section presents a comparison of the terms used in various OAM standards, without fully quoting the definition of each term. For a formal definition of each term, refer to the references at the end of this document. 2.2.2. OAM Maintenance Entities OAM tools are designed to monitor and manage a Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a relationship between two points of a transport path to which maintenance and monitoring operations apply. The following related terms are also quoted from [TP-OAM-FW]: o MEP: The two points that define a maintenance entity. o MEG: The collection of one or more MEs that belongs to the same transport path and that are maintained and monitored as a group are known as a Maintenance Entity Group (MEG). Mizrahi, et al. Expires July 9, 2013 [Page 13] Internet-Draft Overview of OAM Mechanisms January 2013 o MIP: In between MEPs, there are zero or more intermediate points, called Maintenance Entity Group Intermediate Points (MIPs). A pair of MEPs engaged in an ME are connected by a communication link, which may be one of several types of connection, e.g. a single physical connection, a set of physical connections, or a virtual link such as an MPLS LSP. The term Maintenance Entity (ME) is used in ITU-T Recommendations (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology ([TP-OAM- FW]). Various terms are used to refer to an ME. For example, BFD does not explicitly use a term that is equivalent to ME, but rather uses the term "session", referring to the relationship between two nodes using a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) terminology simply uses the term "LSP" in this context. MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG) in [TP-OAM-FW], similar to the terms defined by ITU-T. A MEG allows the monitoring of a compound set of MEs, for example when monitoring a p2mp MEG that is considered to be the set of MEs between the root and each individual destination MEP. 2.2.3. OAM Maintenance Points A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages. A Maintenance End Point (MEP) is one of the end points of an ME, and can initiate OAM messages and respond to them. A Maintenance Intermediate Point (MIP) is an intermediate point between two MEPs, that does not generally initiate OAM frames (one exception to this is the use of AIS notifications), but is able to respond to OAM frames that are destined to it. A MIP in MPLS-TP identifies OAM packets destined to it by the value of the TTL field in the OAM packet. The term Maintenance Point is a general term for MEPs and MIPs. The 802.1ag defines a finer distinction between Up MPs and Down MPs. An MP is a bridge interface, that is monitored by an OAM protocol either in the direction facing the network, or in the direction facing the bridge. A Down MP is an MP that receives OAM packets from, and transmits them to the direction of the network. An Up MP receives OAM packets from, and transmits them to the direction of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the MP - either at the ingress, egress, or forwarding function of the node (Down / Up MPs). This placement is important for localization of a connection failure. Mizrahi, et al. Expires July 9, 2013 [Page 14] Internet-Draft Overview of OAM Mechanisms January 2013 2.2.4. Proactive and On-demand activation The different OAM tools may be used in one of two basic types of activation: o Proactive activation - indicates that the tool is activated on a continual basis periodically, where messages are sent between the two MEPs, and errors are detected when a certain number of expected messages are not received. o On-demand activation - indicates that the tool is activated "manually" to detect a specific anomaly. In this activation a small number of OAM messages are sent by a MEP and the reply message is received. 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. Continuity checks are used to verify the liveness of a connection or a path between two MPs, and are typically sent proactively, though they can be invoked on-demand as well. A connectivity verification function allows an MP to check whether it is connected to a peer MP or not. This function also allows the MP to verify that messages from the peer MP are received through the correct path, thereby verifying not only that the two MPs are connected, but also that they are connected through the expected path. This allows detection of unexpected topology changes. A connectivity verification (CV) protocol typically uses a CV message, followed by a CV reply that is sent back to the originator. A CV function can be applied proactively or on-demand. Connectivity verification and continuity checks are considered complementary mechanisms, and are often used in conjunction with each other. 2.2.6. Failures The terms Failure, Fault, and Defect are used interchangeably in the standards, referring to a malfunction that can be detected by a connectivity or a continuity check. In some standards, such as [IEEE802.1ag], there is no distinction between these terms, while in Mizrahi, et al. Expires July 9, 2013 [Page 15] Internet-Draft Overview of OAM Mechanisms January 2013 other standards each of these terms refers to a different type of malfunction. The terminology used in IETF MPLS-TP OAM takes after the ITU-T, which distinguishes between these terms in [ITU-T-G.806]; The term Fault refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. The term Defect refers to an interruption in the normal operation, such as a consecutive period of time where no packets are delivered successfully. The term Failure refers to the termination of the required function. While a Defect typically refers to a limited period of time, a failure refers to a long period of time. 3. OAM Tools 3.1. IP Ping and Traceroute 3.1.1. Ping Ping is a common network diagnosis application for IP networks that uses ICMP. The ICMP Echo request/reply exchange is a connectivity verification function for the Internet Protocol. The originator transmits an ICMP Echo request packet, and the receiver replies with an Echo reply. ICMP ping is defined in two variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6. 3.1.2. Traceroute Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to discover the path between an IP source and an IP destination. Traceroute sends a sequence of UDP packets to UDP port 33434 at the destination. By default, Traceroute begins by sending three packets (the number of packets is configurable in most Traceroute implementations), each with an IP Time-To-Live (TTL) value of one to the destination. These packets expire as soon as they reach the first router in the path. That router responds by sending three ICMP Time Exceeded Messages to the Traceroute application. Traceroute now sends another three UDP packets, each with the TTL value of 2. These messages cause the second router to return ICMP messages. This process continues, with ever increasing values for the TTL field, until the packets actually reach the destination. Because no application listens to port 33434 at the destination, the destination returns ICMP Destination Unreachable Messages indicating an unreachable port. This event indicates to the Traceroute application that it is finished. The Traceroute program displays the round-trip delay associated with each of the attempts. Mizrahi, et al. Expires July 9, 2013 [Page 16] Internet-Draft Overview of OAM Mechanisms January 2013 Note that IP routing may be asymmetric. While Traceroute reveals the path between a source and destination, it may not reveal the reverse path. A few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have been defined in the context of Traceroute. These extensions augment the ICMP Destination Unreachable message, and can be used by Traceroute applications. 3.2. Bidirectional Forwarding Detection (BFD) 3.2.1. Overview While multiple OAM mechanisms have been defined for various protocols in the protocol stack, Bidirectional Forwarding Detection [BFD], defined by the IETF BFD working group, is a generic OAM mechanism that can be deployed over various encapsulating protocols, and in various medium types. The IETF has defined variants of the protocol for IP ([BFD-IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for PWE3 [BFD-VCCV]. The usage of BFD in MPLS-TP is defined in [MPLS-TP-CC- CV]. BFD includes two main OAM functions, using two types of BFD packets: BFD Control packets, and BFD Echo packets. 3.2.2. BFD Control BFD supports a bidirectional continuity check, using BFD control packets, that are exchanged within a BFD session. BFD sessions operate in one of two modes: o Asynchronous mode (i.e. proactive): in this mode BFD control packets are sent periodically. When the receiver detects that no BFD control packet have been received during a predetermined period of time, a failure is detected. o Demand mode: in this mode, BFD control packets are sent on-demand. Upon need, a system initiates a series of BFD control packets to verify the liveness of the session. BFD control packets are sent independently in each direction. Each of the end-points of the monitored path maintains its own session identification, called a Discriminator, both of which are included in the BFD Control Packets that are exchanged between the end-points. At the time of session establishment, the Discriminators are exchanged between the two-end points. In addition, the transmission (and reception) rate is negotiated between the two end- Mizrahi, et al. Expires July 9, 2013 [Page 17] Internet-Draft Overview of OAM Mechanisms January 2013 points, based on information included in the control packets. These transmission rates may be renegotiated during the session. During normal operation of the session, i.e. no failures are detected, the BFD session is in the Up state. If no BFD Control packets are received during a fixed period of time, called the TOM: Fixed, pre-configured or negotiated period of time (i.e.: BFD interval= ) [TM] We rephrased this sentence. Detection Time, the session is declared to be Down. The detection time is a function of the negotiated transmission time, and a parameter called Detect Mult. Detect Mult determines the number of missing BFD Control packets that cause the session to be declared as Down. This parameter is included in the BFD Control packet. 3.2.3. BFD Echo A BFD echo packet is sent to a peer system, and is looped back to the originator. The echo function can be used proactively, or on-demand. The BFD echo function has been defined in BFD for IPv4 and IPv6 ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for MPLS-TP. 3.3. MPLS OAM The IETF MPLS working group has defined OAM for MPLS LSPs. The requirements and framework of this effort are defined in [MPLS-OAM- FW] and [MPLS-OAM], respectively. The corresponding OAM mechanism defined, in this context, is LSP Ping [LSP-Ping]. LSP Ping is based on ICMP Ping and just like its predecessor may be used in one of two modes: o "Ping" mode: In this mode LSP ping is used for end-to-end connectivity verification between two LERs. o "Traceroute" mode: This mode is used for hop-by-hop fault isolation. LSP Ping extends the basic ICMP Ping operation (of data-plane connectivity verification) with functionality to verify data-plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC) and also Maximum Transmission Unit (MTU) problems. The traceroute functionality may be used to isolate and localize the MPLS faults, using the Time-to-live (TTL) indicator to incrementally identify the sub-path of the LSP that is successfully traversed before the faulty link or node. Mizrahi, et al. Expires July 9, 2013 [Page 18] Internet-Draft Overview of OAM Mechanisms January 2013 It should be noted that LSP Ping supports unique identification of the LSP within an addressing domain. The identification is checked using the full FEC identification. LSP Ping is easily extensible to include additional information needed to support new functionality, by use of Type-Length-Value (TLV) constructs. The usage of TLVs is typically not easy to perform in hardware, and is thus typically handled by the control plane. LSP Ping supports both asynchronous, as well as, on-demand activation. 3.4. MPLS-TP OAM 3.4.1. Overview The MPLS working group is currently working on defining the OAM toolset that fulfills the requirements for MPLS-TP OAM. The full set of requirements for MPLS-TP OAM are defined in [MPLS-TP-OAM], and include both general requirements for the behavior of the OAM mechanisms and a set of operations that should be supported by the OAM toolset. The set of mechanisms required are further elaborated in [TP-OAM-FW], which describes the general architecture of the OAM system as well as giving overviews of the functionality of the OAM toolset. Some of the basic requirements for the OAM toolset for MPLS-TP are: o MPLS-TP OAM must be able to support both an IP based and non-IP based environment. If the network is IP based, i.e. IP routing and forwarding are available, then the MPLS-TP OAM toolset should rely on the IP routing and forwarding capabilities. On the other hand, in environments where IP functionality is not available, the OAM tools must still be able to operate without dependence on IP forwarding and routing. o OAM packets and the user traffic are required to be congruent (i.e. OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from user-plane ones. Inherent in this requirement is the principle that MPLS-TP OAM be independent of any existing control-plane, although it should not preclude use of the control-plane functionality. 3.4.2. Generic Associated Channel In order to address the requirement for in-band transmission of MPLS- TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based Mizrahi, et al. Expires July 9, 2013 [Page 19] Internet-Draft Overview of OAM Mechanisms January 2013 on the same concepts as the PWE3 ACH and VCCV mechanisms. However, to address the needs of LSPs as differentiated from PW, the following concepts were defined for [G-ACh]: o An Associated Channel Header (ACH), that uses a format similar to the PW Control Word, is a 4-byte header that is prepended to OAM packets. o A Generic Associated Label (GAL). The GAL is a reserved MPLS label value (13) that indicates that the packet is an ACH packet and the payload follows immediately after the label stack. 3.4.3. MPLS-TP OAM Toolset To address the functionality that is required of the OAM toolset, the MPLS WG conducted an analysis of the existing IETF and ITU-T OAM mechanisms and their ability to fulfill the required functionality. The conclusions of this analysis are documented in [OAM-Analys]. The MPLS working group currently plans to use a mixture of OAM mechanisms that are based on various existing standards, and adapt them to the requirements of [MPLS-TP-OAM]. Some of the main building blocks of this solution are based on: o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for proactive continuity check and connectivity verification. o LSP Ping as defined in [LSP-Ping] for on-demand connectivity verification. o New protocol packets, using G-ACH, to address different functionality. o Performance measurement protocols that are based on the functionality that is described in [ITU-T-Y1731]. The following sub-sections describe the OAM tools defined for MPLS-TP as described in [TP-OAM-FW]. 3.4.3.1. Continuity Check and Connectivity Verification Continuity Check and Connectivity Verification are presented in Section 2.2.5. of this document. As presented there, these tools may be used either proactively or on-demand. When using these tools proactively, they are generally used in tandem. For MPLS-TP there are two distinct tools, the proactive tool is defined in [TP-CC-CV] while the on-demand tool is defined in Mizrahi, et al. Expires July 9, 2013 [Page 20] Internet-Draft Overview of OAM Mechanisms January 2013 [OnDemand-CV].Proactively [MPLS-TP-OAM] states that the function should allow the MEPs to monitor the liveness and connectivity of a transport path. In on-demand mode, this function should support monitoring between the MEPs and, in addition, between a MEP and MIP. [TP-OAM-FW] highlights, when performing Connectivity Verification, the need for the CC-V messages to include unique identification of the MEG that is being monitored and the MEP that originated the message. The proactive tool [TP-CC-CV] is based on extensions to BFD (see Section 3.2. ) with the additional limitation that the transmission and receiving rates are based on configuration by the operator. The on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see Section 3.3. ) for the required behavior of MPLS-TP. 3.4.3.2. Route Tracing [MPLS-TP-OAM] defines that there is a need for functionality that would allow a path end-point to identify the intermediate and end- points of the path. This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP, and sections, however, unidirectional paths may be supported only if a return path exists. The tool for this is based on the LSP Ping (see Section 3.3. ) functionality and is described in [OnDemand-CV]. 3.4.3.3. Lock Instruct The Lock Instruct function [Lock-Loop] is used to notify a transport path end-point of an administrative need to disable the transport path. This functionality will generally be used in conjunction with some intrusive OAM function, e.g. Performance measurement, Diagnostic testing, to minimize the side-effect on user data traffic. 3.4.3.4. Lock Reporting Lock Reporting is a function used by an end-point of a path to report to its far-end end-point that a lock condition has been affected on the path. 3.4.3.5. Alarm Reporting Alarm Reporting is a function used by an intermediate point of a path, that becomes aware of a fault on the path, to report to the end-points of the path. [TP-OAM-FW] states that this may occur as a result of a defect condition discovered at a server sub-layer. This generates an Alarm Indication Signal (AIS) that continues until the Mizrahi, et al. Expires July 9, 2013 [Page 21] Internet-Draft Overview of OAM Mechanisms January 2013 fault is cleared. The consequent action of this function is detailed in [TP-OAM-FW]. 3.4.3.6. Remote Defect Indication Remote Defect Indication (RDI) is used proactively by a path end- point to report to its peer end-point that a defect is detected on a bidirectional connection between them. [MPLS-TP-OAM] points out that this function may be applied to a unidirectional LSP only if there a return path exists. [TP-OAM-FW] points out that this function is associated with the proactive CC-V function. 3.4.3.7. Client Failure Indication Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow the propagation information from one edge of the network to the other. The information concerns a defect to a client, in the case that the client does not support alarm notification. 3.4.3.8. Packet Loss Measurement (LM) Packet Loss Measurement is a function used to verify the quality of the service. This function indicates the ratio of packets that are not delivered out of all packets that are transmitted by the path source. There are two possible ways of determining this measurement: o Using OAM packets, it is possible to compute the statistics based on a series of OAM packets. This, however, has the disadvantage of being artificial, and may not be representative since part of the packet loss may be dependent upon packet sizes. TOM: Not just packet sizes. Things like implementation (as I mentioned abov= e with the comment about the accuracy or truthfulness of the data plane pro= cessing of OAM packets). Doing very accurate RTT as a simple example, with= just IP Pings, is a tricky thing to make work. Also, it is important to m= ention that the scale in terms of number of packets, number of tests, etc..= . can and will impact these parameters too. [TM] Following your comment we rephrased this sentence. o Sending delimiting messages for the start and end of a measurement period during which the source and sink of the path count the packets transmitted and received. After the end delimiter, the ratio would be calculated by the path OAM entity. 3.4.3.9. Packet Delay Measurement (DM) Packet Delay Measurement is a function that is used to measure one- way or two-way delay of a packet transmission between a pair of the end-points of a path (PW, LSP, or Section). Where: Mizrahi, et al. Expires July 9, 2013 [Page 22] Internet-Draft Overview of OAM Mechanisms January 2013 o One-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of that packet by the destination node. o Two-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop-backed packet by the same source node, when the loopback is performed at the packet's destination node. Similarly to the packet loss measurement this could be performed in either of the two ways outlined above. 3.5. PWE3 OAM 3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV) VCCV, as defined in [VCCV], provides a means for end-to-end fault detection and diagnostics tools to be extended for PWs (regardless of the underlying tunneling technology). The VCCV switching function provides a control channel associated with each PW (based on the PW Associated Channel Header (ACH) which is defined in [PW-ACH]), and allows transmitting the OAM packets in-band with PW data (using CC Type 1: In-band VCCV). VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of encapsulation - either IP/UDP encapsulated (with IP/UDP header) or PW-ACH encapsulated (with no IP/UDP header) and provides support to signal the AC status. The use of the VCCV control channel provides the context, based on the MPLS-PW label, required to bind and bootstrap the BFD session to a particular pseudo wire (FEC), eliminating the need to exchange Discriminator values. VCCV consists of two components: (1) signaled component to communicate VCCV capabilities as part of VC label, and (2) switching component to cause the PW payload to be treated as a control packet. VCCV is not directly dependent upon the presence of a control plane. The VCCV capability negotiation may be performed as part of the PW signaling when LDP is used. In case of manual configuration of the PW, it is the responsibility of the operator to set consistent options at both ends. TOM: Might be helpful to note that the static mode was created specifically= to handle the MPLS-TP cases where no control plane was a requirement. Howe= ver, new use cases such as pure mobile backhaul, etc... find this functiona= lity useful too. [TM] Following your comment we added some text to explain this. Mizrahi, et al. Expires July 9, 2013 [Page 23] Internet-Draft Overview of OAM Mechanisms January 2013 3.5.2. PWE3 OAM using G-ACh As mentioned above, VCCV enables OAM for PWs by using a control channel for OAM packets. When PWs are used in MPLS-TP networks, rather than the control channels defined in VCCV, the G-ACh can be used as an alternative control channel. The usage of the G-ACh for PWs is defined in [PW-G-ACh]. 3.6. OWAMP and TWAMP 3.6.1. Overview The IPPM working group in the IETF defines common criteria and metrics for measuring performance of IP traffic ([IPPM-FW]). Some of the key RFCs published by this working group have defined metrics for measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), and packet loss [IPPM-1LM]. Alternative protocols for performance measurement are defined, for example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet OAM [ITU-T-Y1731]. The IPPM working group has defined not only metrics for performance measurement, but also protocols that define how the measurement is carried out. The One-way Active Measurement Protocol [OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] define a method and protocol for measuring delay and packet loss in IP networks. OWAMP [OWAMP] enables measurement of one-way characteristics of IP networks, such as one-way packet loss and one-way delay. For its proper operation OWAMP requires accurate time of day setting at its end points. TWAMP [TWAMP] is a similar protocol that enables measurement of two- way (round trip) characteristics. TWAMP does not require accurate time of day, and, furthermore, allows the use of a simple session reflector, making it an attractive alternative to OWAMP. OWAMP and TWAMP use two separate protocols: a Control plane protocol, and a Test plane protocol. 3.6.2. Control and Test Protocols OWAMP and TWAMP control protocols run over TCP, while the test protocols run over UDP. The purpose of the control protocols is to initiate, start, and stop test sessions, and for OWAMP to fetch results. The test protocols introduce test packets (which contain Mizrahi, et al. Expires July 9, 2013 [Page 24] Internet-Draft Overview of OAM Mechanisms January 2013 sequence numbers and timestamps) along the IP path under test according to a schedule, and record statistics of packet arrival. Multiple sessions may be simultaneously defined, each with a session identifier, and defining the number of packets to be sent, the amount of padding to be added (and thus the packet size), the start time, and the send schedule (which can be either a constant time between test packets or exponentially distributed pseudo-random). Statistics recorded conform to the relevant IPPM RFCs. OWAMP and TWAMP test traffic is designed with security in mind. Test packets are hard to detect because they are simply UDP streams between negotiated port numbers, with potentially nothing static in the packets. OWAMP and TWAMP also include optional authentication and encryption for both control and test packets. 3.6.3. OWAMP OWAMP defines the following logical roles: Session-Sender, Session- Receiver, Server, Control-Client, and Fetch-Client. The Session- Sender originates test traffic that is received by the Session- Receiver. The Server configures and manages the session, as well as returning the results. The Control-Client initiates requests for test sessions, triggers their start, and may trigger their termination. The Fetch-Client requests the results of a completed session. Multiple roles may be combined in a single host - for example, one host may play the roles of Control-Client, Fetch-Client, and Session-Sender, and a second playing the roles of Server and Session-Receiver. In a typical OWAMP session the Control-Client establishes a TCP connection to port 861 of the Server, which responds with a server greeting message indicating supported security/integrity modes. The Control-Client responds with the chosen communications mode and the Server accepts the modes. The Control-Client then requests and fully describes a test session to which the Server responds with its acceptance and supporting information. More than one test session may be requested with additional messages. The Control-Client then starts a test session and the Server acknowledges. The Session- Sender then sends test packets with pseudorandom padding to the Session-Receiver until the session is complete or until the Control- client stops the session. Once finished, the Fetch-Client sends a fetch request to the server, which responds with an acknowledgement and immediately thereafter the result data. Mizrahi, et al. Expires July 9, 2013 [Page 25] Internet-Draft Overview of OAM Mechanisms January 2013 3.6.4. TWAMP TWAMP defines the following logical roles: session-sender, session- reflector, server, and control-client. These are similar to the OWAMP roles, except that the Session-Reflector does not collect any packet information, and there is no need for a Fetch-Client. In a typical TWAMP session the Control-Client establishes a TCP connection to port 862 of the Server, and mode is negotiated as in OWAMP. The Control-Client then requests sessions and starts them. The Session-Sender sends test packets with pseudorandom padding to the Session-Reflector which returns them with insertion of timestamps. 3.7. Summary of OAM Functions Table 3 summarizes the OAM functions that are supported in each of the categories that were analyzed in this section. +-----------+-------+--------+--------+-----------+-------+--------+ | Standard |Continu|Connecti|Path |Defect |Perform|Other | | |ity |vity |Discover|Indications|ance |Function| | |Check |Verifica|y | |Monitor|s | | | |tion | | |ing | | +-----------+-------+--------+--------+-----------+-------+--------+ |IP Ping | |Echo | | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |IP | | |Tracerou| | | | |Traceroute | | |te | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |BFD |BFD |BFD | | | | | | |Control|Echo | | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |MPLS OAM | |"Ping" |"Tracero| | | | |(LSP Ping) | |mode |ute" | | | | | | | |mode | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |MPLS-TP |CC |CV/pro- |Route |-Alarm |-LM |-Diagnos| |OAM | |active |Tracing | Reporting |-DM | tic Tes| | | |or on- | |-Client | | t | | | |demand | | Failure | |-Lock | | | | | | Indication| | | | | | | |-Remote | | | Mizrahi, et al. Expires July 9, 2013 [Page 26] Internet-Draft Overview of OAM Mechanisms January 2013 | | | | | Defect | | | | | | | | Indication| | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |PWE3 OAM |BFD |-BFD |LSP-Ping| | | | | | |-ICMP | | | | | | | | Ping | | | | | | | |-LSP- | | | | | | | | Ping | | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |OWAMP and | | | | |-Delay | | |TWAMP | | | | | measur| | | | | | | | ement | | | | | | | |-Packet| | | | | | | | loss | | | | | | | | measur| | | | | | | | ement | | +-----------+-------+--------+--------+-----------+-------+--------+ Table 3 Summary of OAM Functions 4. Security Considerations This memo presents an overview of existing OAM mechanisms, and proposes no new OAM mechanisms. Therefore, this document introduces no security considerations. However, the OAM mechanism reviewed in this document can and do present security issues. The reader is encouraged to review the Security Considerations section of each document reference by this memo. 5. IANA Considerations There are no new IANA considerations implied by this document. 6. Acknowledgments The authors gratefully acknowledge Sasha Vainshtein, Carlos Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other members of the OPSAWG mailing list for their helpful comments. This document was prepared using 2-Word-v2.0.template.dot. Mizrahi, et al. Expires July 9, 2013 [Page 27] Internet-Draft Overview of OAM Mechanisms January 2013 7. References 7.1. Normative References [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., Matsushima, S., "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006. [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002. [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for OAM in MPLS Transport Networks", RFC 5860, May 2010. [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic Associated Channel", RFC 5586, June 2009. [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T., "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006. Mizrahi, et al. Expires July 9, 2013 [Page 28] Internet-Draft Overview of OAM Mechanisms January 2013 [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007. [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers, JR., "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010. [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and TCP/IP Tools and Utilities", RFC 2151, June 1997. [NetTools] Stine, R., "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", RFC 1147, April 1990. [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework for IP Performance Metrics", RFC 2330, May 1998. [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [IPPM-2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and Zekauskas, M., "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and Babiarz, J., "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008. [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. Mizrahi, et al. Expires July 9, 2013 [Page 29] Internet-Draft Overview of OAM Mechanisms January 2013 [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [BFD-Gen] Katz, D., Ward, D., "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010. [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration and Maintenance Framework for MPLS-based Transport Networks ", RFC 6371, September 2011. [TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile", RFC 6428, November 2011. [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011. [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. [TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011. [TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011. Mizrahi, et al. Expires July 9, 2013 [Page 30] Internet-Draft Overview of OAM Mechanisms January 2013 [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., Dai, X., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011. [ITU-T-CT] Betts, M., "Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)", RFC 6671, November 2012. [PW-Map] M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011. [PW-G-ACh] Li, H., Martini, L., He, J., Huang, F., "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, November 2011. 7.2. Informative References [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, D., Mansfield, S., "Guidelines for the use of the OAM acronym in the IETF ", RFC 6291, June 2011. [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool Set for MPLS based Transport Networks", RFC 6669, July 2012. [TP-Term] Van Helvoort, H., Andersson, L., Sprecher, N., "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations", work-in-progress, draft-ietf-mpls- tp-rosetta-stone, July 2012. [IEEE802.1ag] IEEE 802.1Q, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", October 2012. [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and Mechanisms for Ethernet-based Networks", July 2011. [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance mechanism for MPLS networks", February 2004. Mizrahi, et al. Expires July 9, 2013 [Page 31] Internet-Draft Overview of OAM Mechanisms January 2013 [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology - Local and metropolitan area networks - Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", clause 57, December 2008. [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January 2009. [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS", November 2012. [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)", November 2012. Authors' Addresses Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com Elisa Bellagamba Ericsson 6 Farogatan St. Stockholm, 164 40 Sweden Mizrahi, et al. Expires July 9, 2013 [Page 32] Internet-Draft Overview of OAM Mechanisms January 2013 Phone: +46 761440785 Email: elisa.bellagamba@ericsson.com Yaacov Weingarten 34 Hagefen St. Karnei Shomron, 4485500 Israel Email: wyaacov@gmail.com draft-ietf-opsawg-oam-overview authors, Here is my feedback on this document. 1. Is this document in line with http://tools.ietf.org/html/draft-ietf-trill-o= am-req-04? * For example, the following definitions could be reused. Fault: The term Fault refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. Defect: The term Defect refers to an interruption in the normal operation, such that over a period of time no packets are delivered successfully. Failure: The term Failure refers to the termination of the required function over a longer period of time. Persistence of a defect for a period of time is interpreted as a failure. * For example, on the basic abstract Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. Abstract (draft-ietf-trill-oam-req-04) OAM (Operations, Administration and Maintenance) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents, OAM Requirements applicable to TRILL. So, as an example: does OAM include function? I advice to review draft-ietf-trill-oam-req-04 2. draft-ietf-trill-oam is not mentioned, while the abstract mentions: This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. Search for OAM in the current draft names (https://datatracker.ietf.org/), = and you will find many references. Ok, I see later on: This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM- related work is outside the scope. Ok, fine then: we don't need a reference to all the drafts. However, draft-ietf-trill-oam is closed to be a RFC, and should be mentione= d. 3. Section 1 The term OAM in this document refers to Operations, Administration and Maintenance [OAM-Def], focusing on the forwarding plane of OAM. What does it mean "focusing on the forwarding plane of OAM"? Do you take a subset of the definition for this document? Btw, I don't see a definition in the terminology section. In section 2.2.3 A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages. Which plane is MP? 4. Section 1, Introduction "Hence, management aspects are outside the scope of this document." I don't understand which management aspects we speak about here. 5. Clarifying question regarding 1.2 If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, cont= rol plane, or management plane? Note that I found later on in the draft: OWAMP and TWAMP use two separate protocols: a Control plane protocol, and a Test plane protocol. Interestingly enough, after reading the document, I reviewed http://datatra= cker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, and saw the same = feedback from Stewart Bryant: Provide a clear view of OAM functionality and its relationship to various "planes" of networking (data plane, control plane, management plane). In particular, the importance of fate-sharing of OAM and user traffic flows in packet networks should be explained. 6. I see a multiplication of "plane" terms in the IETF document, and in this d= ocument in particular. I could find: forwarding plane, management plane, control plane, data plane= , user plane, and test plane. Way too many. Please be consistent 7. Table 1 summarizes the IETF OAM related RFCs discussed in this document. Table 2 summarizes the OAM standards mentioned in this document. You need to change the Table 2 description. Do you want to say something al= ong the lines of: Table 2 summarizes the OAM standards specified by other Standard Develop= ment Organization (SDO) than the IETF, along with IETF references where applicable. 8. Section 2.2.1 For a formal definition of each term, refer to the references at the end= of this document. Without a reference to a specific RFC, this is the type of statement which = is not useful: you have 5 pages of references. You position this document as "An Overview of Operations, Administration, a= nd Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to = know about the terms, just read first all references!" 9. You specify some terms and some OAM categories, 2.2.2. OAM Maintenance Entities .......................... 13 2.2.3. OAM Maintenance Points ............................ 14 2.2.4. Proactive and On-demand activation ................ 15 2.2.5. Connectivity Verification and Continuity Checks ... 15 2.2.6. Failures .......................................... 15 ... but you don't use them in the section 3 Just one example with section 3.2.2 - o Demand mode: in this mode, BFD control packets are sent on-demand. Upon need, a system initiates a series of BFD control packets to verify the liveness of the session Instead of liveness, you have defined Connectivity Verification and Continu= ity Checks in section 2.2.5 - OLD: Each of the end-points of the monitored path maintains its own session identification NEW: Each of the MEP maintains its own session identification OR NEW (actually I don't know) Each of the MP maintains its own session identification - OLD A BFD echo packet is sent to a peer system Peer system =3D MEP, MP, or something else? - etc... 10. This document is composed of a list of OAM content and references, but I'm = really missing the document "scope and target audience". When we did RFC 6632, which is the companion document, we had http://tools.= ietf.org/html/rfc6632#section-1.1 The target audience of the document is, on the one hand, IETF working groups, which aim to select appropriate standard management protocols and data models to address their needs concerning network management. On the other hand, the document can be used as an overview and guideline by non-IETF Standards Development Organizations (SDOs) planning to use IETF management technologies and data models for the realization of management applications. The document can also be used to initiate a discussion between the bodies with the goal to gather new requirements and to detect possible gaps. Finally, this document is directed to all interested parties that seek to get an overview of the current set of the IETF network management protocols such as network administrators or newcomers to the IETF. You should have something similar. 11. Section 3.6.1, put the paragraph 2 at the end of the section. The "alternat= ive" in the following sentence would then make sense Alternative protocols for performance measurement are defined, for example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet OAM [ITU-T-Y1731]. My conclusions: this document still needs some work Regards, Benoit The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-25. Exceptiona= lly, comments may be sent to iesg@ietf.org instead. In either case, please= retain the beginning of the Subject line to allow automated sorting. Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ No IPR declarations have been submitted directly on this I-D. --_000_74470498B659FA4687F0B0018C19A89C01D43919C122ILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tom, <= o:p>

 

Thanks again for your comments.

A link to the updated draft:=

http://tools.ietf.org/html/draft-ietf-= opsawg-oam-overview-13

 

We believe the cur= rent draft addresses all the comments below.

We have replied to every single comment below (search f= or [TM]).

 

Please let us know if you believe s= omething is still amiss.

<= o:p> 

Thanks,

Tal.

 

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent= : Monday, January 20, 2014 5:29 PM
To: Benoit Claise
Cc= : draft-ietf-opsawg-oam-overview@tools.ietf.org; opsawg@ietf.org; IETF = Disgust
Subject: Re: Last Call: <draft-ietf-opsawg-oam-overvie= w-08.txt> (An Overview of Operations, Administration, and Maintenance (O= AM) Mechanisms) to Informational RFC

 

 <= /o:p>

 &nbs= p;          Reviewing t= he current version of the draft (12), many of the comments below are still = not addressed.

 

  &= nbsp;         --Tom

 

 

&n= bsp;

Here is T= om Nadeau's feedback, forwarded with permission:

Regards, Benoit
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Some general comments:

 

  1. I did not find any discussion around use of configuration wit= hin OAM mechanisms. This is clearly something that is happening in groups l= ike PWE3 and CCAMP. The motivation for this should be explained and documen= ted to at least guide these efforts.

[TM] The current draft includes a significantly clearer explanation, up f= ront  in the abstract and introduction, that this document focuses on = OAM tools, i.e., on the data plane of OAM. That is why, for example we do n= ot discuss configuration contexts such as CCAMP.

2. There is no real discussion = around the security aspects of these tools. Should there be?

=

 

[TM] We received a= similar comment from other reviewers, as well as the SecDir review in the = previous IETF last call. After some discussion between our AD at the time (= Ron Bonica) and the Sec AD (Sean Turner), the current phrasing of the "= ;Security Considerations" section was agreed. It is mainly an issue of= where you draw the line between which content to include and which content= not to include in the draft, and security is currently out of scope.

 

3. = While the document provides a nice taxonomy of various OAM tools, it does n= ot really discuss the techniques for using them. I do not expect anything i= n detail, but it is not obvious that many of these tools can be orchestrate= d to form a "toolset" that can be used to do multi-layer OAM func= tions for services such as carrier Ethernet over VPLS over MPLS, for exampl= e.

 =

[TM] Following your comment, = we added quite a bit of text to the introduction to explain this multi-laye= r orchestration. You can take full credit for the fact that this doll IETF = draft now includes an ASCII art figure (Figure 1). :)

 

 

4. It might be u= seful to at least mention in the performance metrics section, a discussion = around the accuracy of these tools and how it depends on scale, implementat= ion and network configurations.

[TM] Following your comment we added a note about this in section 4.7.= 1. See the paragraphs beginning with “It should be noted that while [= OWAMP]…”.

 

=  

My detailed comments i= nline starting with TOM:

 

--Tom

=

 

 

 <= /p>

 

 

 

Expires: July 2013           &nb= sp;                    No= kia Siemens Networks

  &= nbsp;                    =                     &nbs= p;              E. Bellagamba=

          &nbs= p;                     &n= bsp;                     =           Ericsson

                &nbs= p;                     &n= bsp;                    Y= . Weingarten

 

          &nb= sp;                     &= nbsp;                    =    January 9, 2013

 

      =                      = ;   An Overview of

 = ;       Operations, Administration, and Maintenance (OAM) Me= chanisms

     =              draft-ietf-opsawg-oam-over= view-08.txt

 =

 

Abstract

&= nbsp;

   Operations, Adm= inistration, and Maintenance (OAM) is a general term

   that refers to a toolset that can = be used for fault detection and

   isolation, and for performance measurement. OAM mechanisms = have been

   define= d for various layers in the protocol stack, and are used with a<= /p>

   variety of protocols.<= /o:p>

 

   This document presents an overview of the O= AM mechanisms that have

 = ;  been defined and are currently being defined by the IETF.

 

Status of this Memo

 

   Thi= s Internet-Draft is submitted to IETF in full conformance with the

   provisions of BCP 78 and= BCP 79.

 

   Internet-Drafts are working d= ocuments of the Internet Engineering

   Task Force (IETF), its areas, and its working groups. =  Note that

   = other groups may also distribute working documents as Internet-<= /p>

   Drafts.

 

   Internet-Drafts are draft documents valid for a maximum o= f six months

   and= may be updated, replaced, or obsoleted by other documents at any

   time.  It is inappro= priate to use Internet-Drafts as reference

   material or to cite them other than as "wor= k in progress."

&nb= sp;

   The list of curre= nt Internet-Drafts can be accessed at

=

 

&= nbsp;  The list of Internet-Draft Shadow Directories can be accessed a= t

 

   This Internet-Draft will expire on July 9, 201= 3.

 

 

 

Mizrahi, et al. &= nbsp;       Expires July 9, 2013        =          [Page 1]

Internet-Draft       Overview of OAM Mechanis= ms           January 2013

 

=  

Copyright Notice<= /o:p>

 

   Copyright (c) 2013 IETF Trust and the perso= ns identified as the

  &= nbsp;document authors. All rights reserved.

 

  =  This document is subject to BCP 78 and the IETF Trust's Legal

   Provisions Relating to = IETF Documents

   (= http://trustee.ietf.org/li= cense-info) in effect on the date of

   publication of this document. Please review these= documents

   caref= ully, as they describe your rights and restrictions with respect=

   to this document. Code Com= ponents extracted from this document must

   include Simplified BSD License text as described = in Section 4.e of

  &nbs= p;the Trust Legal Provisions and are provided without warranty as

   described in the Simplifi= ed BSD License.

 

Table of Contents

 

 

   1.= Introduction ................................................. 3

      1.1. The Building= Blocks of OAM .............................. 3

      1.2. Forwarding Plane vs. Managemen= t Plane ................... 4

      1.3. The OAM toolsets ...............................= ......... 4

    &nb= sp; 1.4. IETF OAM Documents ...................................... 6

      1.5. Non-IETF = OAM Documents ................................. 10

   2. Basic Terminology ...................= ........................ 12

&= nbsp;     2.1. Abbreviations ....................................= ...... 12

     = ; 2.2. Terminology used in OAM Standards ...................... 13

         2.2= .1. General Terms ..................................... 13

         2.2.2. OAM = Maintenance Entities .......................... 13

         2.2.3. OAM Maintena= nce Points ............................ 14

         2.2.4. Proactive and On-dem= and activation ................ 15

         2.2.5. Connectivity Verification an= d Continuity Checks ... 15

&n= bsp;        2.2.6. Failures ...........................= ............... 15

  &nb= sp;3. OAM Tools ................................................... 16=

      3.1. IP Ping= and Traceroute ................................. 16

         3.1.1. Ping .....= ......................................... 16

         3.1.2. Traceroute........= ................................. 16

      3.2. Bidirectional Forwarding Detection (BFD) = ............... 17

  &nb= sp;      3.2.1. Overview ...................................= ....... 17

    &nbs= p;    3.2.2. BFD Control ....................................... = 17

       = ;  3.2.3. BFD Echo .......................................... 18<= /o:p>

      3.3. MPLS OAM= ............................................... 18

      3.4. MPLS-TP OAM ..............= .............................. 19

         3.4.1. Overview ....................= ...................... 19

&nb= sp;        3.4.2. Generic Associated Channel ..........= .............. 19

  &nbs= p;      3.4.3. MPLS-TP OAM Toolset .........................= ...... 20

     = ;       3.4.3.1. Continuity Check and Connectivity Verificat= ion 20

 

<= /div>

 

Mizrahi, et al.         Expires July 9, 2013 &= nbsp;                [Page 2]<= /o:p>

Internet-Draft      = ; Overview of OAM Mechanisms           January 201= 3

 

=

 

            3.4.3.2. Route Tracing ......= .......................... 21

            3.4.3.3. Lock Instruct .........= ....................... 21

&n= bsp;           3.4.3.4. Lock Reporting ...........= .................... 21

 = ;           3.4.3.5. Alarm Reporting .............= ................. 21

  &= nbsp;         3.4.3.6. Remote Defect Indication .......= .............. 22

  &nbs= p;         3.4.3.7. Client Failure Indication .........= ........... 22

    =         3.4.3.8. Packet Loss Measurement (LM) .........= ........ 22

    &nb= sp;       3.4.3.9. Packet Delay Measurement (DM) ...........= ..... 22

     = 3.5. PWE3 OAM ............................................... 23

         3.5.= 1. PWE3 OAM using Virtual Circuit Connectivity Verification

<= /div>

         (VCCV) ...= ................................................ 23

         3.5.2. PWE3 OAM us= ing G-ACh .............................. 24

      3.6. OWAMP and TWAMP...................= ...................... 24

&nb= sp;        3.6.1. Overview ............................= .............. 24

  &nbs= p;      3.6.2. Control and Test Protocols ..................= ...... 24

     = ;    3.6.3. OWAMP ............................................. 2= 5

       =  3.6.4. TWAMP ............................................. 26

      3.7. Summary o= f OAM Functions ............................... 26

   4. Security Considerations .............= ........................ 27

&= nbsp;  5. IANA Considerations ........................................= . 27

   6. Acknowle= dgments ............................................. 27

   7. References ....................= .............................. 28

      7.1. Normative References .......................= ............ 28

   =   7.2. Informative References ................................. 31

 

1. Introduction

 

   = OAM is a general term that refers to a toolset for detecting,

   isolating and reporting conne= ction failures and performance

   degradation.

 

   This d= ocument summarizes the OAM tools and mechanisms defined in the

   IETF.

 

   The term OAM in this document refers to Operations, Administ= ration

   and Maint= enance [OAM-Def], focusing on the forwarding plane of OAM.

   Hence, management aspects are ou= tside the scope of this document.

 

TOM: This is a curious sentence to me since to me, OAM is management, or = a subset of it.   Also, if you look at the referenced documents, there= are many indirect references to MIBs, Netconf, etc… making this sent= ence further confusing. It might be helpful to explain more clearly that th= e authors here intended to not cover those things explicitly rather than gr= ouping them arbitrarily under the definition of "management aspects&qu= ot;  Further, to clarify, it might be useful to expand on what "f= orwarding plane" is here just to be clear.   That is, is this &qu= ot;in band" or "out-of band" or both? Some of the tools refe= rred to here also are part of the control AND data planes. =

[TM] We significantly improved the di= stinction between the different planes: data plane, control plane, manageme= nt plane. We added a definition of each of the terms, and we now explicitly= explain that the draft focuses on the data plane. We also explain in the c= urrent draft that we adopt the OAM acronym as recommended in RFC 6291: Oper= ations, Administration and Maintenance (without Management...). Please let = us know if you think something is still missing here.=

 <= /p>

 

1.= 1. The Building Blocks of OAM

 

   An OAM p= rotocol is run in the context of a Maintenance Domain,

=

   consisting of two or more nodes that= run the OAM protocol, referred

   to as Maintenance Points (MP).

 

&nbs= p;  This subsection provides a brief summary of the common tools used = by

   OAM protocols= . An OAM protocol typically supports one or more of the

   tools described below.

 

 

Mizrahi, = et al.         Expires July 9, 2013      = ;            [Page 3]

Internet-Draft       Overview of OAM = Mechanisms           January 2013

 

 

   o= Continuity Checking (CC):

&n= bsp;     Used for verifying the liveness of a connection between = two MPs.

 

   o Connectivity Verification (= CV):

      All= ows an MP to check whether it is connected to a peer MP, and to<= /p>

      verify that message= s from the peer MP are received through the

      expected path.

 

=    o Path Discovery / Fault Localization:

      An MP uses this mechanism to tr= ace the route to a peer MP, i.e.,

      to identify the nodes along the path to the peer = MP. When a

    &nbs= p; connection fails, this mechanism also allows the MP to detect the

      location of th= e failure.

 

TOM: The definition c= alls this "path discovery" but then talks about tracing routes. A= better way of describing this in the paragraph would be that there I a use= of path tracing in order to discover (or re-discover) paths that have been= changed, created or destroyed.  

<= b>[TM] We rephrased this paragraph, and hopefully it is clearer a= nd more accurate now.

 

 

   o Performance Monitoring= :

      Consis= ts of 3 main functions

&= nbsp;

        = o Loss Measurement (LM) - monitors the packet loss rate of a

=

          connecti= on.

 

        o Delay Measurement= (DM) - monitors the delay and delay

          variation between MPs.

 

        o Throughput measurement - monit= ors the throughput of a

 = ;         connection.

 

TOM: Along with the discussion above around path trace/discovery,= it is imperative that paths be discovered (one way or another) in order to= successfully d performance monitoring on those paths.

[TM] True. However this section presents a shor= t list of typical OAM functions, and we would rather stick with succinct de= scriptions in this section.

 

 

1.2. Forwarding Plane vs. M= anagement Plane

 

   While the OAM tools ma= y, and quite often do, work in conjunction with

   a control-plane or management plane, they a= re usually defined to be

&nbs= p;  independent of the control-plane.  The OAM tools communicate = with the

   managem= ent plane to raise alarms, and often the on-demand tools may

=

   be activated by the management= , e.g. to locate and localize problems.

 

  &n= bsp;The considerations of the control-plane maintenance tools or the

   functionality of the m= anagement-plane are out of scope for this

   document, which will concentrate on presenting th= e forwarding-plane

  &nb= sp;tools that are used for OAM.

 

= TOM: What about the data plane? For example, the GACH OAM type is such an e= xample. VCCV also operates within the data plane after its configuration ca= pabilities have been signaled.  It should also be mentioned that it is= imperative that when required, OAM tools are capable of testing the actual= data plane in as much accuracy as possible, but that they all should note = how accurate.   Not all OAM tools are created equal.

[TM] We rephrased this subsection, and now h= ave a much clearer definition of each plane in “2.2.4. Data Plane, Co= ntrol Plane and Management Plane”. We also added specific text about = the importance of fate-sharing (see section 1.4), which addresses the secon= d part of your comment.

 

 

   sequen= ce numbers and timestamps) along the IP path under test

   according to a schedule, and record= statistics of packet arrival.

   Multiple sessions may be simultaneously defined, each with a= session

   identif= ier, and defining the number of packets to be sent, the amount

   of padding to be added (and = thus the packet size), the start time,

   and the send schedule (which can be either a constan= t time between

   t= est packets or exponentially distributed pseudo-random). Statistics

   recorded conform to the= relevant IPPM RFCs.

&nb= sp;

   OWAMP and TWAMP t= est traffic is designed with security in mind.  Test

   packets are hard to detect becaus= e they are simply UDP streams

   between negotiated port numbers, with potentially nothing sta= tic in

   the packe= ts.  OWAMP and TWAMP also include optional authentication

   and encryption for both cont= rol and test packets.

&n= bsp;

3.6.3. OWAMP

 

   OWAMP defines the following logical roles: Session-Sen= der, Session-

   Re= ceiver, Server, Control-Client, and Fetch-Client.  The Session-

   Sender originates test= traffic that is received by the Session-

   Receiver.  The Server configures and manages= the session, as well as

&nbs= p;  returning the results.  The Control-Client initiates requests= for

   test sessio= ns, triggers their start, and may trigger their

   termination.  The Fetch-Client request= s the results of a completed

=    session.  Multiple roles may be combined in a single host= - for

   example, = one host may play the roles of Control-Client, Fetch-Client,

=

   and Session-Sender, and a seco= nd playing the roles of Server and

   Session-Receiver.

 

   I= n a typical OWAMP session the Control-Client establishes a TCP

   connection to port 861 of th= e Server, which responds with a server

   greeting message indicating supported security/integ= rity modes. The

   = Control-Client responds with the chosen communications mode and the

   Server accepts the mode= s.  The Control-Client then requests and fully

   describes a test session to which the S= erver responds with its

 = ;  acceptance and supporting information.  More than one test ses= sion

   may be requ= ested with additional messages.  The Control-Client then

   starts a test session and the= Server acknowledges.  The Session-

   Sender then sends test packets with pseudorandom = padding to the

   S= ession-Receiver until the session is complete or until the Control-

   client stops the sessio= n.  Once finished, the Fetch-Client sends a

<= p class=3DMsoNormal>   fetch request to the server, which respond= s with an acknowledgement

&nb= sp;  and immediately thereafter the result data.

<= div>

 

 

 

 

 

&nbs= p;

Mizrahi, et al.     &= nbsp;   Expires July 9, 2013            =     [Page 25]

Inte= rnet-Draft       Overview of OAM Mechanisms     &n= bsp;     January 2013

 

 

3.6.4. TWAMP

 

&nbs= p;  TWAMP defines the following logical roles: session-sender, session= -

   reflector, ser= ver, and control-client.  These are similar to the

   OWAMP roles, except that the Sessio= n-Reflector does not collect any

   packet information, and there is no need for a Fetch-Clien= t.

 

   In a typical TWAMP session the Cont= rol-Client establishes a TCP

=    connection to port 862 of the Server, and mode is negotiated a= s in

   OWAMP. &nbs= p;The Control-Client then requests sessions and starts them.

=

   The Session-Sender sends test = packets with pseudorandom padding to

   the Session-Reflector which returns them with insertio= n of

   timestamps.=

 

<= div>

3.7. Summary of OAM Functions

=

 

   Table 3 summarizes the OAM functions that are supported in= each of

   the cat= egories that were analyzed in this section.

 

  =  +-----------+-------+--------+--------+-----------+-------+--------+<= o:p>

   | Standard  = ;|Continu|Connecti|Path    |Defect     |Perform|Other &= nbsp; |

   |  =         |ity    |vity    |Discover= |Indications|ance   |Function|

   |           |Check  |Veri= fica|y       |           |Monitor|s=       |

 = ;  |           |       |tion &= nbsp;  |        |         &nbs= p; |ing    |        |

   +-----------+-------+--------+--------+= -----------+-------+--------+

   |IP Ping    |       |Echo   &nb= sp;|        |           | &nbs= p;     |        |

   + --------- + ----- + ------ + ------ + ---= ------ + ----- + ------ +

&nb= sp;  |IP         |       |   &= nbsp;    |Tracerou|           |   &= nbsp;   |        |

   |Traceroute |       |   &nb= sp;    |te      |         &nbs= p; |       |        |

   + --------- + ----- + ------ + ---= --- + --------- + ----- + ------ +

   |BFD        |BFD    |BFD &= nbsp;   |        |         &nb= sp; |       |        |

   |         &nb= sp; |Control|Echo    |        |    =       |       |        |=

   + --------- + -= ---- + ------ + ------ + --------- + ----- + ------ +

<= div>

   |MPLS OAM   |     &nbs= p; |"Ping"  |"Tracero|         &nbs= p; |       |        |

   |(LSP Ping) |      = |mode    |ute"    |         &= nbsp; |       |        |

<= /div>

   |         &= nbsp; |       |        |mode   &nbs= p;|           |       |   &nbs= p;    |

  &nbs= p;+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +=

   |MPLS-TP   &nbs= p;|CC     |CV/pro- |Route   |-Alarm     |-LM  = ;  |-Diagnos|

  &nb= sp;|OAM        |       |active  |Tr= acing | Reporting |-DM    | tic Tes|

   |           |  = ;     |or on-  |        |-Client   =  |       | t      |

=

   |          = |       |demand  |        | Failur= e   |       |-Lock   |

   |           | &nbs= p;     |        |        = | Indication|       |        |

   |       &n= bsp;   |       |        |   &n= bsp;    |-Remote    |       |   &nb= sp;    |

 = ;

 

=

 

M= izrahi, et al.         Expires July 9, 2013   &nbs= p;             [Page 26]

=

Internet-Draft       Overview of O= AM Mechanisms           January 2013

 

 

  &n= bsp;|           |       |   &n= bsp;    |        | Defect    | &nbs= p;     |        |

   |           | &nbs= p;     |        |        = | Indication|       |        |

   + --------- + ----- + ---= --- + ------ + --------- + ----- + ------ +

   |PWE3 OAM   |BFD    |-BFD  =  |LSP-Ping|           |      = |        |

   |           |      = |-ICMP   |        |         &= nbsp; |       |        |

<= /div>

   |         &= nbsp; |       | Ping   |        | &= nbsp;         |       |     &n= bsp;  |

   | &= nbsp;         |       |-LSP-   | &n= bsp;      |           |   &nbs= p;   |        |

   |           |   &nb= sp;   | Ping   |        |      = ;     |       |        |<= /o:p>

   + --------- + ----- += ------ + ------ + --------- + ----- + ------ +

   |OWAMP and  |       | &= nbsp;      |        |     &nbs= p;     |-Delay |        |

   |TWAMP      |  =     |        |        | =           | measur|        |

   |     &= nbsp;     |       |        | &= nbsp;      |           | ement | &n= bsp;      |

&n= bsp;  |           |       | &n= bsp;      |        |      = ;     |-Packet|        |

=

   |          = |       |        |      =  |           | loss  |     &n= bsp;  |

   | &= nbsp;         |       |     &n= bsp;  |        |          = ; | measur|        |

   |           |   &nb= sp;   |        |        | &nbs= p;         | ement |        |<= /o:p>

   +-----------+-------+= --------+--------+-----------+-------+--------+

                =      Table 3 Summary of OAM Functions

 

4. Security Considerations

=  

   This memo= presents an overview of existing OAM mechanisms, and

<= div>

   proposes no new OAM mechanisms. There= fore, this document introduces

   no security considerations. However, the OAM mechanism revie= wed in

   this docu= ment can and do present security issues. The reader is

=

   encouraged to review the Security Co= nsiderations section of each

=    document reference by this memo.

 

5. IA= NA Considerations

 =

   There are no new IAN= A considerations implied by this document.

 

6. Ackno= wledgments

 <= /p>

   The authors gratefully ackn= owledge Sasha Vainshtein, Carlos

   Pignataro, David Harrington, Dan Romascanu, Ron Bonica and= other

   members o= f the OPSAWG mailing list for their helpful comments.

<= div>

 

   This document was prepared using 2-Word-v2.0.template.dot.<= o:p>

 

 

 

 

 

 

&nbs= p;

Mizrahi, et al.     &= nbsp;   Expires July 9, 2013            =     [Page 27]

Inte= rnet-Draft       Overview of OAM Mechanisms     &n= bsp;     January 2013

 

 

7. References

 

7.1= . Normative References

&= nbsp;

   [LSP-Ping] &nbs= p;  Kompella, K., Swallow, G., "Detecting Multi-Protocol

          &n= bsp;      Label Switched (MPLS) Data Plane Failures", R= FC 4379,

     =            February 2006.

 

   [MPLS-OAM]    Nadeau, T., Morrow, M., Swallow,= G., Allan, D.,

   =              Matsushima, S., "Oper= ations and Management (OAM)

&= nbsp;                Requirements f= or Multi-Protocol Label Switched (MPLS)

                 = Networks", RFC 4377, February 2006.

 

  &n= bsp;[MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protoc= ol

       = ;          Label Switching (MPLS) Operations and M= anagement

     = ;            (OAM)", RFC 4378, February = 2006.

 

   [OAM-Label]   Ohta, H., &qu= ot;Assignment of the 'OAM Alert Label' for

                 = ;Multiprotocol Label Switching Architecture (MPLS)

              &nbs= p;  Operation and Maintenance (OAM) Functions", RFC 3429,

          &= nbsp;      November 2002.

 

  &n= bsp;[MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements fo= r

       =          OAM in MPLS Transport Networks", RF= C 5860, May 2010.

 =

   [G-ACh]    = ;   Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic

          &nb= sp;      Associated Channel", RFC 5586, June 2009.=

 

<= p class=3DMsoNormal>   [VCCV]        Nadeau, = T., Pignataro, C., "Pseudowire Virtual Circuit

              &nb= sp;  Connectivity Verification (VCCV): A Control Channel

            =      for Pseudowires", RFC 5085, December 2007.

 

   [PW-ACH]      Bryant, S., Swal= low, G., Martini, L., McPherson, D.,

                 "= ;Pseudowire Emulation Edge-to-Edge (PWE3) Control Word

=

              =    for Use over an MPLS PSN", RFC 4385, February 2006.<= /o:p>

 

   [ICMPv4]      Postel, J., &q= uot;Internet Control Message Protocol", STD 5,

              &nb= sp;  RFC 792, September 1981.

 

   [IC= MPv6]      Conta, A., Deering, S., and M. Gupta, "Inter= net Control

    &nb= sp;            Message Protocol (ICMPv6) for = the Internet Protocol

  =                Version 6 (IPv6) Spe= cification", RFC 4443, March 2006.

 

  &n= bsp;[MPLS-P2MP]   Yasukawa, S., Farrel, A., King, D., Nadeau, T.,=

         = ;        "Operations and Management (OAM) Requirem= ents for

     =            Point-to-Multipoint MPLS Networks= ", RFC 4687,

  &nbs= p;              September 2006.

 

 

Mizrah= i, et al.         Expires July 9, 2013     &n= bsp;           [Page 28]

=

Internet-Draft       Overview of OAM Me= chanisms           January 2013

 

 

   [IC= MP-Ext]    Bonica, R., Gan, D., Tappan, D., Pignataro, C., "= ICMP

      &nb= sp;          Extensions for Multiprotocol Label Sw= itching", RFC

  &nb= sp;              4950, August 2007.=

 

<= p class=3DMsoNormal>   [ICMP-MP]     Bonica, R., Gan, D= ., Tappan, D., Pignataro, C.,

                 "Extend= ed ICMP to Support Multi-Part Messages", RFC

=

               = ;  4884, April 2007.

 

   [ICMP-Int] &= nbsp;  Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers,

          &= nbsp;      JR., "Extending ICMP for Interface and Next-= Hop

      &nbs= p;          Identification", RFC 5837, April = 2010.

 

   [TCPIP-Tools] Kessler, G., Shepa= rd, S., "A Primer On Internet and

                 TCP= /IP Tools and Utilities", RFC 2151, June 1997.

 

   [NetTools]    Stine, R., "FYI on a Network Man= agement Tool Catalog:

  =                Tools for Monitoring= and Debugging TCP/IP Internets

                 and Interc= onnected Devices", RFC 1147, April 1990.

 

 = ;  [IPPM-FW]     Paxson, V., Almes, G., Mahdavi, J., and Mat= his, M.,

     =            "Framework for IP Performanc= e Metrics", RFC 2330, May

                 1998.<= /o:p>

 

   [IPPM-Con]    Mahdavi, J., Paxson= , V., "IPPM Metrics for Measuring

                 Con= nectivity", RFC 2678, September 1999.

 

  &= nbsp;[IPPM-1DM]    Almes, G., Kalidindi, S., Zekauskas, M., "= ;A One-way

    &nbs= p;            Delay Metric for IPPM", RF= C 2679, September 1999.

=  

   [IPPM-1LM] &nb= sp;  Almes, G., Kalidindi, S., Zekauskas, M., "A One-way

          &n= bsp;      Packet Loss Metric for IPPM", RFC 2680, Septe= mber

      &nb= sp;          1999.

 

  =  [IPPM-2DM]    Almes, G., Kalidindi, S., Zekauskas, M., &quo= t;A Round-trip

    =              Delay Metric for IPPM"= , RFC 2681, September 1999.

<= o:p> 

   [OWAMP] &n= bsp;     Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and

        &n= bsp;        Zekauskas, M., "A One-way Active Measu= rement Protocol

   =              (OWAMP)", RFC 4656, S= eptember 2006.

 

   [TWAMP]     &= nbsp; Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and

<= /div>

            &n= bsp;    Babiarz, J., "A Two-Way Active Measurement Protocol<= o:p>

        &= nbsp;        (TWAMP)", RFC 5357, October 2008.

 

=

   [BFD]         Katz, D= ., Ward, D., "Bidirectional Forwarding Detection

<= div>

              &= nbsp;  (BFD)", RFC 5880, June 2010.

 

=  

 

=

Mizrahi, et al.         Expir= es July 9, 2013                 [Pa= ge 29]

Internet-Draft   =     Overview of OAM Mechanisms          = January 2013

 

 

   [BFD-IP]      Katz, D., Ward, D= ., "Bidirectional Forwarding Detection

                &nbs= p;(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June

=

            &= nbsp;    2010.

 

   [BFD-Gen] &nb= sp;   Katz, D., Ward, D., "Generic Application of

<= /div>

            &n= bsp;    Bidirectional Forwarding Detection (BFD)", RFC 5882,=

        =          June 2010.

 

 =  [BFD-Multi]   Katz, D., Ward, D., "Bidirectional Forwardin= g Detection

    &nb= sp;            (BFD) for Multihop Paths"= , RFC 5883, June 2010.

&= nbsp;

   [BFD-LSP]  = ;   Aggarwal, R., Kompella, K., Nadeau, T., and Swallow,

            =      G., "Bidirectional Forwarding Detection (BFD) for = MPLS

      &nb= sp;          Label Switched Paths (LSPs)", RF= C 5884, June 2010.

 = ;

   [BFD-VCCV]   &= nbsp;Nadeau, T., Pignataro, C., "Bidirectional Forwarding

           =      Detection (BFD) for the Pseudowire Virtual Circuit

        &nbs= p;        Connectivity Verification (VCCV)", RFC 5= 885, June

     = ;            2010.

<= p class=3DMsoNormal> 

&n= bsp;  [TP-OAM-FW]   Busi, I., Allan, D., "Operations, Admini= stration and

    &n= bsp;            Maintenance Framework for MPL= S-based Transport

  &nbs= p;              Networks ", RFC 637= 1, September 2011.

 = ;

   [TP-CC-CV]   &= nbsp;Allan, D., Swallow, G., Drake, J., "Proactive

             =    Connectivity Verification, Continuity Check and Remote

          =        Defect indication for MPLS Transport Profile&quo= t;, RFC

      =            6428, November 2011.

 

   [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S.,= Aggarwal, R. "MPLS

&nbs= p;                On-Demand Connect= ivity Verification and Route

=                  Tracing"= , RFC 6426, November 2011.

 

   [MPLS-LM-DM= ]  Frost, D., Bryant, S., "Packet Loss and Delay

            &nb= sp;    Measurement for MPLS Networks", RFC 6374, September

        &n= bsp;        2011.

 

   = [TP-LM-DM]    Frost, D., Bryant, S., "A Packet Loss and Dela= y

       =          Measurement Profile for MPLS-Based Trans= port

      &nb= sp;          Networks", RFC 6375, September 2= 011.

 

   [TP-Fault]    Swallow, = G., Fulignoli, A., Vigoureux, M., Boutros, S.,

                &= nbsp;"MPLS Fault Management Operations, Administration, and=

          &nbs= p;      Maintenance (OAM)", RFC 6427, November 2011.

 

 

=  

 

<= /div>

 

Mizrahi, et al.         Expires July 9, 2013 &= nbsp;               [Page 30]=

Internet-Draft       Ove= rview of OAM Mechanisms           January 2013

 

=

 

&= nbsp;  [Lock-Loop]   Boutros, S., Sivabalan, S., Aggarwal, R., Vi= goureux,

     =            M., Dai, X., "MPLS Transport= Profile Lock Instruct and

&n= bsp;                Loopback Functi= ons", RFC 6435, November 2011.

 

   [I= TU-T-CT]    Betts, M., "Allocation of a Generic Associated C= hannel

      &= nbsp;          Type for ITU-T MPLS Transport Profi= le Operation,

    &= nbsp;            Maintenance, and Administrat= ion (MPLS-TP OAM)", RFC

=                  6671, Novembe= r 2012.

 

=

   [PW-Map]      M= . Aissaoui, P. Busschbach, L. Martini, M. Morrow, T.

              &n= bsp;  Nadeau, "Pseudowire (PW) Operations, Administration,

          =        and Maintenance (OAM) Message Mapping", RFC= 6310, July

    &nb= sp;            2011.

 

=    [PW-G-ACh]    Li, H., Martini, L., He, J., Huang, F.= , "Using the

  &nbs= p;              Generic Associated Chann= el Label for Pseudowire in the

                 MPLS Transp= ort Profile (MPLS-TP)", RFC 6423, November

                =  2011.

 =

7.2. Informative References<= /p>

 

   [OAM-Def]     Andersson, L., Van Helvoo= rt, H., Bonica, R., Romascanu,

                 D., Mansfie= ld, S., "Guidelines for the use of the OAM

                =  acronym in the IETF ", RFC 6291, June 2011.

=

 

   [OAM-Analys]  Sprecher, N., Fang, L., "An Overvi= ew of the OAM Tool

  &nb= sp;              Set for  MPLS base= d Transport Networks", RFC 6669,

                 July= 2012.

 

<= /div>

   [TP-Term]     Van Hel= voort, H., Andersson, L., Sprecher, N., "A

                =  Thesaurus for the Terminology used in Multiprotocol

            &nbs= p;    Label Switching Transport Profile (MPLS-TP)

<= /div>

            &n= bsp;    drafts/RFCs and ITU-T's Transport Network

<= /div>

            &n= bsp;    Recommendations", work-in-progress, draft-ietf-mpls-=

        =          tp-rosetta-stone, July 2012.

 

   [IEEE802.1ag] IEEE 802.1Q, "IEEE Standard fo= r Local and metropolitan

&nbs= p;                area networks - M= edia Access Control (MAC) Bridges and

                 Virt= ual Bridged Local Area Networks", October 2012.

 

   [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM = Functions and

    &= nbsp;            Mechanisms for Ethernet-base= d Networks", July 2011.

=  

   [ITU-T-Y1= 711] ITU-T Recommendation Y.1711, "Operation & Maintenance

          &= nbsp;      mechanism for MPLS networks", February 2004.=

 

<= div>

 

 

 

Mizrahi, et al.       &nbs= p; Expires July 9, 2013               &n= bsp; [Page 31]

Internet-Draft=       Overview of OAM Mechanisms        = ;   January 2013

&n= bsp;

 

   [IEEE802.3ah] IEEE 802.3, "IEEE S= tandard for Information technology -

                 Local= and metropolitan area networks - Carrier sense

                =  multiple access with collision detection (CSMA/CD)

             = ;    access method and physical layer specifications",<= /o:p>

         =        clause 57, December 2008.

<= div>

 

   [ITU-T-G.806] ITU-T Recommendation G.806, "Characteris= tics of

      =            transport equipment - Description = methodology and

   =              generic functionality"= ;, January 2009.

 <= /o:p>

   [ITU-G8113.2] ITU-T R= ecommendation G.8113.2/Y.1372.2, "Operations,

              &nbs= p;  administration and maintenance mechanisms for MPLS-TP

           =      networks using the tools defined for MPLS", Novem= ber

      &nbs= p;          2012.

 

  &= nbsp;[ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations= ,

       =          Administration and Maintenance mechanism= for MPLS-TP

    &n= bsp;            in Packet Transport Network (= PTN)", November 2012.

 

 

 

Authors' Addresses

 

   Tal Mizrahi<= o:p>

   Marvell

   6 Hamada St.<= /p>

   Yokneam, 20692

   Israel

<= div>

 

 

<= /div>

 

   Nurit Sprecher

   Nokia Siemens Networks

   3 Hanagar St. Neve Ne'eman B

   Hod Hasharon,   45241

   Israel

 

&n= bsp;

 

   Elisa Bellagamba

<= div>

   Ericsson

   6 Farogatan St.

   Stockholm,   164 40

   Sweden

 

 

 

Mizrahi, et al.         Expi= res July 9, 2013                 [P= age 32]

Internet-Draft  =     Overview of OAM Mechanisms          = ; January 2013

 

 

   Phone: +46 761440785

   Email: elisa.bellagamba@ericsson.com

=

 

<= o:p> 

   Yaacov Wei= ngarten

   34 Hagef= en St.

   Karnei Sh= omron,   4485500

  =  Israel

 

   Email: wyaacov@gmail.com

 

&nbs= p;

 

 

=  

 

<= /div>

 

 

 

draft-ietf-opsawg-oam-overview author= s,

Here is my feedback on this document.

1.
Is this docume= nt in line with http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?
* F= or example, the following definitions could be reused.

&=
nbsp;  Fault: The term Fault refers to an inability to perform a requi=
red
   action, e.g., an unsuccessful attempt=
 to deliver a packet.
 
&nbs=
p;  Defect: The term Defect refers to an interruption in the normal
   operation, such that over a period of time =
no packets are delivered
   successfully.
 
   Failure: The te=
rm Failure refers to the termination of the required
&=
nbsp;  function over a longer period of time. Persistence of a defect =
for a
   period of time is interpreted as a =
failure.
 
* For example, on=
 the basic abstract 
Abstract
 
   Operations, Administration, and Maint=
enance (OAM) is a general term
   that refer=
s to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms h= ave been
   defined for various layers in th=
e protocol stack, and are used with a
   var=
iety of protocols.
 
Abstrac=
t (draft-ietf-trill-oam-req-04)
 
   OAM (Operations, Administration and Maintenance) is a ge=
neral term
   used to identify functions and=
 toolsets to troubleshoot and monitor
   net=
works. This document presents, OAM Requirements applicable to
   TRILL. 
 
So, as an example: does OAM include function? 
I ad=
vice to review draft-ietf-trill-oam-req-04
 =

2. 
draft-ietf-trill-oam is not menti=
oned, while the abstract mentions:
   This d=
ocument presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IET=
F.
Search for OAM in the current draft names (https://datatracker.ietf.org/), and =
you will find many references.
Ok, I see later on:&nbs=
p;      
   This do=
cument focuses on IETF
   documents that hav=
e been published as RFCs, while other ongoing OAM-
&nb=
sp;  related work is outside the scope.
Ok, fine =
then: we don't need a reference to all the drafts. 
Ho=
wever, draft-ietf-trill-oam is closed to be a RFC, and should be mentioned.=

 
 
3.
Section 1
   The =
term OAM in this document refers to Operations, Administration
   and Maintenance [OAM-Def], focusing o=
n the forwarding plane of OAM.
What does it mean "=
;focusing on the forwarding plane of OAM"?
Do you=
 take a subset of the definition for this document?
Bt=
w, I don't see a definition in the terminology section.
In section 2.2.3
   A Maintenance Point (M=
P) is a functional entity that is defined at a
 &=
nbsp; node in the network, and either initiates or reacts to OAM messages.<=
o:p>
Which plane is MP?
 
4.
Section 1, Introduction
"Hence, management aspects are outside the scope of this docum=
ent."
I don't understand which management aspects=
 we speak about here.
5.
Clarifying=
 question regarding 1.2
If speak about OWAMP or TWAMP 'synthetic traffic=
), is that data plane, control plane, or management plane?
Note that I f=
ound later on in the draft:
   OWAMP and TWAMP=
 use two separate protocols: a Control plane protocol,
   and a Test plane protocol.
Interestingly enough, after reading the document, I reviewed htt=
p://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, an=
d saw the same feedback from Stewart Bryant:
Provide a c=
lear view of OAM functionality and its relationship
to=
 various “planes” of networking (data plane, control plane,
management plane). In particular, the importance of<=
/o:p>
fate-sharing of OAM and user traffic flows in packet networ=
ks
should be explained.
6.
I see a multiplication of "plane" te=
rms in the IETF document, and in this document in particular.
I could find: forwarding plane, management plane, control plane, da=
ta plane, user plane, and test plane.
Way too many.
Please be consistent
7.
   Table 1 summarizes the IETF OAM relate=
d RFCs discussed in this
   document.
 
   Table 2 summarizes =
the OAM standards mentioned in this document. 
&n=
bsp;
You need to change the Table 2 description. Do you wan=
t to say something along the lines of:
   Ta=
ble 2 summarizes the OAM standards specified by other Standard Development =
Organization 
   (SDO) than the IETF, a=
long with IETF references where applicable.
 =
;
 
8.
Secti=
on 2.2.1
   For a formal definition of each =
term, refer to the references at the end of
 &nbs=
p; this document.
Without a reference to a specific RF=
C, this is the type of statement which is not useful: you have 5 pages of r=
eferences.
You position this document as "An Over=
view of Operations, Administration, and Maintenance (OAM) Mechanisms",=
 but you tell the reader: "if you want to know about the terms,
just read first all references!"
<=
o:p> 
9.
You specify some terms a=
nd some OAM categories, 
   2.2.2. OAM Maintenance Entities .......................... 13
         2.2.3. OAM Maintenance Points ............................ 14
       &n=
bsp; 2.2.4. Proactive and On-demand activation ............=
.... 15
      =
   2.2.5. Connectivity Verification and Continuit=
y Checks ... 15
    &nbs=
p;    2.2.6. Failures ......................=
.................... 15
... but you don't us=
e them in the section 3
 
Ju=
st one example with section 3.2.2
-<=
/pre>
   o Demand mode: in this mode, BFD control packets are=
 sent on-demand.
      Upon n=
eed, a system initiates a series of BFD control packets to
=

      verify the liveness of the session=

Instead of liveness, you have defined Connectivity Verific=
ation and Continuity Checks in section 2.2.5
- OLD:
   Each of the end-points of the monitored pat=
h maintains its own
   session identificatio=
n
NEW:
   Each of the M=
EP maintains its own session identification
OR NEW (ac=
tually I don't know)
   Each of the MP maint=
ains its own session identification
- OLD
   A BFD echo packet is sent to a peer system=

Peer system =3D MEP, MP, or something else?
- etc... 
 
10. =

This document is composed of a list of OAM content and reference=
s, but I'm really missing the document "scope and target audience"=
;.
When we did RFC 6632, which is the companion docume=
nt, we had http:=
//tools.ietf.org/html/rfc6632#section-1.1
 
   The target audience of the document is, on=
 the one hand, IETF working
   groups, which=
 aim to select appropriate standard management protocols
   and data models to address their needs concerning network m=
anagement.
   On the other hand, the documen=
t can be used as an overview and
   guidelin=
e by non-IETF Standards Development Organizations (SDOs)
   planning to use IETF management technologies and data model=
s for the
   realization of management appli=
cations.  The document can also be
   u=
sed to initiate a discussion between the bodies with the goal to=

   gather new requirements and to detect possible gaps=
.  Finally, this
   document is directe=
d to all interested parties that seek to get an
 =
  overview of the current set of the IETF network management protocols=

   such as network administrators or newcom=
ers to the IETF.
 
You shoul=
d have something similar.
 
=
 
11.
Section 3.6.1, put the=
 paragraph 2 at the end of the section. The "alternative" in the =
following sentence would then make sense
   =
Alternative protocols for performance measurement are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM<=
/a>], [TP-LM-DM]), and in Ethernet<=
o:p>
   OAM [ITU-T-Y1731].<=
o:p>
 
 
My conclusions: this document still needs some work
=
 
Regards, Benoit
 
The IESG has received a request from the Operations and Management =
Area
Working Group WG (opsawg) to consider the followi=
ng document:
- 'An Overview of Operations, Administrat=
ion, and Maintenance (OAM)
   Mechanisms'
  <draft-ietf-opsawg-oam-overview-08.txt> as =
Informational RFC
 
The IESG=
 plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to =
the
ietf@ietf.org=
 mailing lists by 2013-01-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. =
In either case, please retain the
beginning of the Sub=
ject line to allow automated sorting.
 
Abstract
 
=
 
   Operations, Administration, and Mainten=
ance (OAM) is a general term
   that refers =
to a toolset that can be used for fault detection and
=
   isolation, and for performance measurement. OAM mechanisms hav=
e been
   defined for various layers in the =
protocol stack, and are used with a
   varie=
ty of protocols.
 
 &nb=
sp; This document presents an overview of the OAM mechanisms that have=

   been defined and are currently being defined =
by the IETF.
 
 
 
 
The =
file can be obtained via
http://datatracker.ietf.org/=
doc/draft-ietf-opsawg-oam-overview/
 
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/
 
 
=

No IPR declarations have been submitted directly on this I-D.
 
 
&=
nbsp;

 

 

 

= --_000_74470498B659FA4687F0B0018C19A89C01D43919C122ILMB01marve_-- From talmi@marvell.com Tue Jan 28 08:07:57 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F881A0269 for ; Tue, 28 Jan 2014 08:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.391 X-Spam-Level: * X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lKXHpwyF2xj for ; Tue, 28 Jan 2014 08:07:34 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5320B1A0435 for ; Tue, 28 Jan 2014 08:07:33 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s0SG7RmM020175; Tue, 28 Jan 2014 08:07:27 -0800 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1hknvxbt4s-14 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jan 2014 08:07:24 -0800 Received: from YK-HUB01.marvell.com (10.4.102.51) by SC-OWA.marvell.com (10.93.76.28) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 28 Jan 2014 08:07:19 -0800 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB01.marvell.com ([10.4.102.51]) with mapi; Tue, 28 Jan 2014 18:07:14 +0200 From: Tal Mizrahi To: Thomas Nadeau Date: Tue, 28 Jan 2014 18:07:05 +0200 Thread-Topic: Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC Thread-Index: Ac8cPvA0vwrdHLj2RSu4ZwnV4b7JtgAA/Ggg Message-ID: <74470498B659FA4687F0B0018C19A89C01D43919C2A4@IL-MB01.marvell.com> References: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> <50F437BF.8040005@cisco.com> <50F972FC.2030707@cisco.com> <6C3490D7-3727-41BA-8980-683DF84451A2@lucidvision.com> <74470498B659FA4687F0B0018C19A89C01D43919C122@IL-MB01.marvell.com> <35CAD982-D991-4BED-8F19-3CDFDADE1EB7@lucidvision.com> In-Reply-To: <35CAD982-D991-4BED-8F19-3CDFDADE1EB7@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01D43919C2A4ILMB01marve_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-28_07:2014-01-28,2014-01-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401280081 Cc: "draft-ietf-opsawg-oam-overview@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:07:57 -0000 --_000_74470498B659FA4687F0B0018C19A89C01D43919C2A4ILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks for the prompt response. We will apply this change in the next draft. Thanks, Tal. From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Tuesday, January 28, 2014 5:38 PM To: Tal Mizrahi Cc: draft-ietf-opsawg-oam-overview@tools.ietf.org; opsawg@ietf.org; opsawg-= chairs@tools.ietf.org; Benoit Claise; joel jaeggli (joelja@bogus.com); Scot= t O. Bradner (sob@harvard.edu) Subject: Re: Last Call: (An Overvie= w of Operations, Administration, and Maintenance (OAM) Mechanisms) to Infor= mational RFC The changes look ok except for one minor one: One of the changes in 4.4.2 BFD for MPLS states the following: The advantage of BFD is that it can provide faster failure detection, and scales better to a large number of LSPs That is a popular misconception. When I at a previous gig we we= re able to actually figure out how to make them both perform equally well for CV operations, but we just decided to not implement it tha= t way. I'd suggest removing that sentence altogether. They are two tools with different implementations, some more optimal than o= thers. Hi Tom, Thanks again for your comments. A link to the updated draft: http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13 We believe the current draft addresses all the comments below. We have replied to every single comment below (search for [TM]). Please let us know if you believe something is still amiss. Thanks, Tal. From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Monday, January 20, 2014 5:29 PM To: Benoit Claise Cc: draft-ietf-opsawg-oam-overview@tools.ietf.org; opsawg@ietf.org; IETF= Disgust Subject: Re: Last Call: (An Overvie= w of Operations, Administration, and Maintenance (OAM) Mechanisms) to Infor= mational RFC Reviewing the current version of the draft (12), many of the co= mments below are still not addressed. --Tom Here is Tom Nadeau's feedback, forwarded with permission: Regards, Benoit =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some general comments: 1. I did not find any discussion around use of configuration within OAM m= echanisms. This is clearly something that is happening in groups like PWE3 = and CCAMP. The motivation for this should be explained and documented to at= least guide these efforts. [TM] The current draft includes a significantly clearer explanation, up fro= nt in the abstract and introduction, that this document focuses on OAM too= ls, i.e., on the data plane of OAM. That is why, for example we do not disc= uss configuration contexts such as CCAMP. 2. There is no real discussion around the security aspects of these tools. = Should there be? [TM] We received a similar comment from other reviewers, as well as the Sec= Dir review in the previous IETF last call. After some discussion between ou= r AD at the time (Ron Bonica) and the Sec AD (Sean Turner), the current phr= asing of the "Security Considerations" section was agreed. It is mainly an = issue of where you draw the line between which content to include and which= content not to include in the draft, and security is currently out of scop= e. 3. While the document provides a nice taxonomy of various OAM tools, it doe= s not really discuss the techniques for using them. I do not expect anythin= g in detail, but it is not obvious that many of these tools can be orchestr= ated to form a "toolset" that can be used to do multi-layer OAM functions f= or services such as carrier Ethernet over VPLS over MPLS, for example. [TM] Following your comment, we added quite a bit of text to the introducti= on to explain this multi-layer orchestration. You can take full credit for = the fact that this doll IETF draft now includes an ASCII art figure (Figure= 1). :) 4. It might be useful to at least mention in the performance metrics sectio= n, a discussion around the accuracy of these tools and how it depends on sc= ale, implementation and network configurations. [TM] Following your comment we added a note about this in section 4.7.1. Se= e the paragraphs beginning with "It should be noted that while [OWAMP]...". My detailed comments inline starting with TOM: --Tom Expires: July 2013 Nokia Siemens Networks E. Bellagamba Ericsson Y. Weingarten January 9, 2013 An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms draft-ietf-opsawg-oam-overview-08.txt Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2013. Mizrahi, et al. Expires July 9, 2013 [Page 1] Internet-Draft Overview of OAM Mechanisms January 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 3 1.1. The Building Blocks of OAM .............................. 3 1.2. Forwarding Plane vs. Management Plane ................... 4 1.3. The OAM toolsets ........................................ 4 1.4. IETF OAM Documents ...................................... 6 1.5. Non-IETF OAM Documents ................................. 10 2. Basic Terminology ........................................... 12 2.1. Abbreviations .......................................... 12 2.2. Terminology used in OAM Standards ...................... 13 2.2.1. General Terms ..................................... 13 2.2.2. OAM Maintenance Entities .......................... 13 2.2.3. OAM Maintenance Points ............................ 14 2.2.4. Proactive and On-demand activation ................ 15 2.2.5. Connectivity Verification and Continuity Checks ... 15 2.2.6. Failures .......................................... 15 3. OAM Tools ................................................... 16 3.1. IP Ping and Traceroute ................................. 16 3.1.1. Ping .............................................. 16 3.1.2. Traceroute......................................... 16 3.2. Bidirectional Forwarding Detection (BFD) ............... 17 3.2.1. Overview .......................................... 17 3.2.2. BFD Control ....................................... 17 3.2.3. BFD Echo .......................................... 18 3.3. MPLS OAM ............................................... 18 3.4. MPLS-TP OAM ............................................ 19 3.4.1. Overview .......................................... 19 3.4.2. Generic Associated Channel ........................ 19 3.4.3. MPLS-TP OAM Toolset ............................... 20 3.4.3.1. Continuity Check and Connectivity Verification 20 Mizrahi, et al. Expires July 9, 2013 [Page 2] Internet-Draft Overview of OAM Mechanisms January 2013 3.4.3.2. Route Tracing ................................ 21 3.4.3.3. Lock Instruct ................................ 21 3.4.3.4. Lock Reporting ............................... 21 3.4.3.5. Alarm Reporting .............................. 21 3.4.3.6. Remote Defect Indication ..................... 22 3.4.3.7. Client Failure Indication .................... 22 3.4.3.8. Packet Loss Measurement (LM) ................. 22 3.4.3.9. Packet Delay Measurement (DM) ................ 22 3.5. PWE3 OAM ............................................... 23 3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV) ................................................... 23 3.5.2. PWE3 OAM using G-ACh .............................. 24 3.6. OWAMP and TWAMP......................................... 24 3.6.1. Overview .......................................... 24 3.6.2. Control and Test Protocols ........................ 24 3.6.3. OWAMP ............................................. 25 3.6.4. TWAMP ............................................. 26 3.7. Summary of OAM Functions ............................... 26 4. Security Considerations ..................................... 27 5. IANA Considerations ......................................... 27 6. Acknowledgments ............................................. 27 7. References .................................................. 28 7.1. Normative References ................................... 28 7.2. Informative References ................................. 31 1. Introduction OAM is a general term that refers to a toolset for detecting, isolating and reporting connection failures and performance degradation. This document summarizes the OAM tools and mechanisms defined in the IETF. The term OAM in this document refers to Operations, Administration and Maintenance [OAM-Def], focusing on the forwarding plane of OAM. Hence, management aspects are outside the scope of this document. TOM: This is a curious sentence to me since to me, OAM is management, or a = subset of it. Also, if you look at the referenced documents, there are ma= ny indirect references to MIBs, Netconf, etc... making this sentence furthe= r confusing. It might be helpful to explain more clearly that the authors h= ere intended to not cover those things explicitly rather than grouping them= arbitrarily under the definition of "management aspects" Further, to clar= ify, it might be useful to expand on what "forwarding plane" is here just t= o be clear. That is, is this "in band" or "out-of band" or both? Some of = the tools referred to here also are part of the control AND data planes. [TM] We significantly improved the distinction between the different planes= : data plane, control plane, management plane. We added a definition of eac= h of the terms, and we now explicitly explain that the draft focuses on the= data plane. We also explain in the current draft that we adopt the OAM acr= onym as recommended in RFC 6291: Operations, Administration and Maintenance= (without Management...). Please let us know if you think something is stil= l missing here. 1.1. The Building Blocks of OAM An OAM protocol is run in the context of a Maintenance Domain, consisting of two or more nodes that run the OAM protocol, referred to as Maintenance Points (MP). This subsection provides a brief summary of the common tools used by OAM protocols. An OAM protocol typically supports one or more of the tools described below. Mizrahi, et al. Expires July 9, 2013 [Page 3] Internet-Draft Overview of OAM Mechanisms January 2013 o Continuity Checking (CC): Used for verifying the liveness of a connection between two MPs. o Connectivity Verification (CV): Allows an MP to check whether it is connected to a peer MP, and to verify that messages from the peer MP are received through the expected path. o Path Discovery / Fault Localization: An MP uses this mechanism to trace the route to a peer MP, i.e., to identify the nodes along the path to the peer MP. When a connection fails, this mechanism also allows the MP to detect the location of the failure. TOM: The definition calls this "path discovery" but then talks about tracin= g routes. A better way of describing this in the paragraph would be that th= ere I a use of path tracing in order to discover (or re-discover) paths tha= t have been changed, created or destroyed. [TM] We rephrased this paragraph, and hopefully it is clearer and more accu= rate now. o Performance Monitoring: Consists of 3 main functions o Loss Measurement (LM) - monitors the packet loss rate of a connection. o Delay Measurement (DM) - monitors the delay and delay variation between MPs. o Throughput measurement - monitors the throughput of a connection. TOM: Along with the discussion above around path trace/discovery, it is imp= erative that paths be discovered (one way or another) in order to successfu= lly d performance monitoring on those paths. [TM] True. However this section presents a short list of typical OAM functi= ons, and we would rather stick with succinct descriptions in this section. 1.2. Forwarding Plane vs. Management Plane While the OAM tools may, and quite often do, work in conjunction with a control-plane or management plane, they are usually defined to be independent of the control-plane. The OAM tools communicate with the management plane to raise alarms, and often the on-demand tools may be activated by the management, e.g. to locate and localize problems. The considerations of the control-plane maintenance tools or the functionality of the management-plane are out of scope for this document, which will concentrate on presenting the forwarding-plane tools that are used for OAM. TOM: What about the data plane? For example, the GACH OAM type is such an e= xample. VCCV also operates within the data plane after its configuration ca= pabilities have been signaled. It should also be mentioned that it is impe= rative that when required, OAM tools are capable of testing the actual data= plane in as much accuracy as possible, but that they all should note how a= ccurate. Not all OAM tools are created equal. [TM] We rephrased this subsection, and now have a much clearer definition o= f each plane in "2.2.4. Data Plane, Control Plane and Management Plane". We= also added specific text about the importance of fate-sharing (see section= 1.4), which addresses the second part of your comment. 1.3. The OAM toolsets This memo provides an overview of the different sets of OAM mechanisms defined by the IETF. It is intended for those with little or no familiarity with the described mechanisms. The set of OAM mechanisms described in this memo are applicable to IP unicast, MPLS, pseudowires, and MPLS for the transport environment (MPLS-TP). While OAM mechanisms that are applicable to other technologies exist, they Mizrahi, et al. Expires July 9, 2013 [Page 4] Internet-Draft Overview of OAM Mechanisms January 2013 are beyond the scope of this memo. This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM- related work is outside the scope. The IETF has defined OAM protocols and mechanisms in several different fronts: o IP Ping and Traceroute: Ping is a very simple and common application for failure diagnosis TOM: I am not sure the term "common" is necessary. [TM] Removed. that uses ICMP Echo requests, as defined in [ICMPv4], and [ICMPv6]. Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to trace the path between an IP source and an IP destination, i.e., to identify the nodes along the path. o BFD: Bidirectional Forwarding Detection (BFD) is defined in [BFD] as a framework for a lightweight generic OAM mechanism. The intention is to define a base mechanism that can be used with various encapsulation types, network environments, and in various medium types. o MPLS OAM: MPLS LSP Ping, as defined in [MPLS-OAM], [MPLS-OAM-FW] and [LSP- Ping], is an OAM mechanism for point to point MPLS LSPs. It includes two main functions: Ping and Traceroute. o MPLS-TP OAM: MPLS-TP OAM is defined in a set of RFCs. The OAM requirements for MPLS Transport Profile (MPLS-TP) are defined in [MPLS-TP-OAM]. Each of the tools in the OAM toolset is defined in its own RFC, as specified in Section 1.4. o PWE3 OAM: The PWE3 OAM architecture defines control channels that support the use of existing IETF OAM tools to be used for a pseudowire (PW). The control channels that are defined in [VCCV] and [PW-G- ACH] may be used in conjunction with ICMP Ping, LSP Ping, and BFD to perform CC and CV functionality. In addition the channels support use of any of the MPLS-TP based OAM tools for completing their respective OAM functionality for a PW. o OWAMP and TWAMP: The One Way Active Measurement Protocol (OWAMP) and the Two Way Active Measurement Protocols (TWAMP) are two protocols defined in the IP Performance Metrics (IPPM) working group in the IETF. These protocols allow delay and packet loss measurement in IP networks. Mizrahi, et al. Expires July 9, 2013 [Page 5] Internet-Draft Overview of OAM Mechanisms January 2013 This document summarizes the OAM mechanisms defined by the IETF. We first present a comparison of the terminology used in various OAM standards, and then summarize the OAM functions that each OAM standard provides. 1.4. IETF OAM Documents Table 1 summarizes the IETF OAM related RFCs discussed in this document. The table includes a "Type" column, specifying the nature of each of the listed documents: o Tool: documents that define an OAM tool or mechanism. o Prof.: documents that define a profile or a variant for an OAM tool that is defined in other documents. o Inf.: documents that define an infrastructure that is used by OAM tools. o Misc.: other OAM related documents, e.g., OAM requirement and framework documents. +-----------+--------------------------------------+-----+----------+ | | Title |Type | RFC | +-----------+--------------------------------------+-----+----------+ |IP Ping and| Internet Control Message Protocol |Tool | RFC 792 | |Traceroute | [ICMPv4] | | | | +--------------------------------------+-----+----------+ | | Internet Control Message Protocol |Tool | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | | Version 6 (IPv6) Specification | | | | | [ICMPv6] | | | | +--------------------------------------+-----+----------+ | | A Primer On Internet and TCP/IP |Tool | RFC 2151 | | | Tools and Utilities [TCPIP-Tools] | | | | +--------------------------------------+-----+----------+ | | FYI on a Network Management Tool |Tool | RFC 1147 | | | Catalog: Tools for Monitoring and | | | | | Debugging TCP/IP Internets and | | | | | Interconnected Devices [NetTools] | | | | +--------------------------------------+-----+----------+ | | Extended ICMP to Support Multi-Part |Tool | RFC 4884 | Mizrahi, et al. Expires July 9, 2013 [Page 6] Internet-Draft Overview of OAM Mechanisms January 2013 | | Messages [ICMP-MP] | | | | +--------------------------------------+-----+----------+ | | ICMP Extensions for Multiprotocol |Tool | RFC 4950 | | | Label Switching [ICMP-Ext] | | | | +--------------------------------------+-----+----------+ | | Extending ICMP for Interface and |Tool | RFC 5837 | | | Next-Hop Identification [ICMP-Int] | | | +-----------+--------------------------------------+-----+----------+ |BFD | Bidirectional Forwarding Detection |Tool | RFC 5880 | | | [BFD] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5881 | | | (BFD) for IPv4 and IPv6 (Single Hop) | | | | | [BFD-IP] | | | | +--------------------------------------+-----+----------+ | | Generic Application of Bidirectional |Misc.| RFC 5882 | | | Forwarding Detection [BFD-Gen] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5883 | | | (BFD) for Multihop Paths [BFD-Multi] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5884 | | | for MPLS Label Switched Paths (LSPs) | | | | | [BFD-LSP] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | | Connectivity Verification (VCCV) | | | | | [BFD-VCCV] | | | +-----------+--------------------------------------+-----+----------+ |MPLS OAM | Operations and Management (OAM) |Misc.| RFC 4377 | | | Requirements for Multi-Protocol Label| | | | | Switched (MPLS) Networks [MPLS-OAM] | | | | +--------------------------------------+-----+----------+ | | A Framework for Multi-Protocol |Misc.| RFC 4378 | | | Label Switching (MPLS) Operations | | | | | and Management (OAM) [MPLS-OAM-FW] | | | | +--------------------------------------+-----+----------+ | | Detecting Multi-Protocol Label |Tool | RFC 4379 | | | Switched (MPLS) Data Plane Failures | | | | | [LSP-Ping] | | | Mizrahi, et al. Expires July 9, 2013 [Page 7] Internet-Draft Overview of OAM Mechanisms January 2013 | +--------------------------------------+-----+----------+ | | Operations and Management (OAM) |Misc.| RFC 4687 | | | Requirements for Point-to-Multipoint | | | | | MPLS Networks [MPLS-P2MP] | | | +-----------+--------------------------------------+-----+----------+ |MPLS-TP | Requirements for OAM in MPLS-TP |Misc.| RFC 5860 | |OAM | [MPLS-TP-OAM] | | | | +--------------------------------------+-----+----------+ | | MPLS Generic Associated Channel |Inf. | RFC 5586 | | | [G-ACh] | | | | +--------------------------------------+-----+----------+ | | MPLS-TP OAM Framework |Misc.| RFC 6371 | | | [TP-OAM-FW] | | | | +--------------------------------------+-----+----------+ | | Proactive Connectivity Verification, |Tool | RFC 6428 | | | Continuity Check, and Remote Defect | | | | | Indication for the MPLS Transport | | | | | Profile [TP-CC-CV] | | | | +--------------------------------------+-----+----------+ | | MPLS On-Demand Connectivity |Tool | RFC 6426 | | | Verification and Route Tracing | | | | | [OnDemand-CV] | | | | +--------------------------------------+-----+----------+ | | MPLS Fault Management Operations, |Tool | RFC 6427 | | | Administration, and Maintenance (OAM)| | | | | [TP-Fault] | | | | +--------------------------------------+-----+----------+ | | MPLS Transport Profile Lock Instruct |Tool | RFC 6435 | | | and Loopback Functions [Lock-Loop] | | | | +--------------------------------------+-----+----------+ | | Packet Loss and Delay Measurement for|Tool | RFC 6374 | | | MPLS Networks [MPLS-LM-DM] | | | | +--------------------------------------+-----+----------+ | | A Packet Loss and Delay Measurement |Prof.| RFC 6375 | | | Profile for MPLS-Based Transport | | | | | Networks [TP-LM-DM] | | | +-----------+--------------------------------------+-----+----------+ |PWE3 OAM | Pseudowire Virtual Circuit |Inf. | RFC 5085 | | | Connectivity Verification (VCCV): | | | | | A Control Channel for Pseudowires | | | | | [VCCV] | | | Mizrahi, et al. Expires July 9, 2013 [Page 8] Internet-Draft Overview of OAM Mechanisms January 2013 | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | | Connectivity Verification (VCCV) | | | | | [BFD-VCCV] | | | | +--------------------------------------+-----+----------+ | | Using the Generic Associated Channel |Inf. | RFC 6423 | | | Label for Pseudowire in the MPLS | | | | | Transport Profile (MPLS-TP) | | | | | [PW-G-ACh] | | | | +--------------------------------------+-----+----------+ | | Pseudowire (PW) Operations, |Misc.| RFC 6310 | | | Administration, and Maintenance (OAM)| | | | | Message Mapping [PW-Map] | | | +-----------+--------------------------------------+-----+----------+ |OWAMP and | A One-way Active Measurement Protocol|Tool | RFC 4656 | |TWAMP | [OWAMP] | | | | +--------------------------------------+-----+----------+ | | A Two-Way Active Measurement Protocol|Tool | RFC 5357 | | | [TWAMP] | | | | +--------------------------------------+-----+----------+ | | Framework for IP Performance Metrics |Misc.| RFC 2330 | | | [IPPM-FW] | | | | +--------------------------------------+-----+----------+ | | IPPM Metrics for Measuring |Misc.| RFC 2678 | | | Connectivity [IPPM-Con] | | | | +--------------------------------------+-----+----------+ | | A One-way Delay Metric for IPPM |Misc.| RFC 2679 | | | [IPPM-1DM] | | | | +--------------------------------------+-----+----------+ | | A One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 | | | [IPPM-1LM] | | | | +--------------------------------------+-----+----------+ | | A Round-trip Delay Metric for IPPM |Misc.| RFC 2681 | | | [IPPM-2DM] | | | +-----------+--------------------------------------+-----+----------+ Table 1 Summary of IETF OAM Related RFCs Mizrahi, et al. Expires July 9, 2013 [Page 9] Internet-Draft Overview of OAM Mechanisms January 2013 1.5. Non-IETF OAM Documents In addition to the OAM mechanisms defined by the IETF, the IEEE and ITU-T have also defined various OAM mechanisms that focus on Ethernet, and various other transport network environments. These various mechanisms, defined by the three standard organizations, are often tightly coupled, and have had a mutual effect on each other. The ITU-T and IETF have both defined OAM mechanisms for MPLS LSPs, [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to some extent linked to IETF OAM mechanisms listed above and are mentioned here only as reference material: o OAM mechanisms for Ethernet based networks have been defined by both the ITU-T in [ITU-T-Y1731], and by the IEEE in [IEEE802.1ag]. The IEEE 802.3 standard defines OAM for one-hop Ethernet links [IEEE802.3ah]. o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. Table 2 summarizes the OAM standards mentioned in this document. This document focuses on IETF OAM standards, but these non-IETF standards are referenced where relevant. +-----------+--------------------------------------+---------------+ | | Title |Standard/Draft | +-----------+--------------------------------------+---------------+ |ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 | |MPLS OAM | for MPLS networks [ITU-T-Y1711] | | | +--------------------------------------+---------------+ | | Assignment of the 'OAM Alert Label' | RFC 3429 | | | for Multiprotocol Label Switching | | | | Architecture (MPLS) Operation and | | | | Maintenance (OAM) Functions | | | | [OAM-Label] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T Y.1711. | | +-----------+--------------------------------------+---------------+ |ITU-T | Operations, administration and |ITU-T G.8113.2 | |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | | Mizrahi, et al. Expires July 9, 2013 [Page 10] Internet-Draft Overview of OAM Mechanisms January 2013 | | networks using the tools defined for | | | | MPLS [ITU-G8113.2] | | | | | | | | Note: this document describes the | | | | OAM toolset defined by the IETF for | | | | MPLS-TP, whereas ITU-T G.8113.1 | | | | describes the OAM toolset defined | | | | by the ITU-T. | | | +--------------------------------------+---------------+ | | Operations, Administration and |ITU-T G.8113.1 | | | Maintenance mechanism for MPLS-TP in | | | | Packet Transport Network (PTN) | | | +--------------------------------------+---------------+ | | Allocation of a Generic Associated | RFC 6671 | | | Channel Type for ITU-T MPLS Transport| | | | Profile Operation, Maintenance, and | | | | Administration (MPLS-TP OAM) | | | | [ITU-T-CT] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T G.8113.1. | | +-----------+--------------------------------------+---------------+ |ITU-T | OAM Functions and Mechanisms for |[ITU-T-Y1731] | |Ethernet | Ethernet-based Networks | | |OAM | | | +-----------+--------------------------------------+---------------+ |IEEE | Connectivity Fault Management | IEEE 802.1ag | |CFM | [IEEE802.1ag] | | | | | | | | Note: CFM was originally published | | | | as IEEE 802.1ag, but is now | | | | incorporated in the 802.1Q standard.| | +-----------+--------------------------------------+---------------+ |IEEE | Media Access Control Parameters, | IEEE 802.3ah | |802.3 | Physical Layers, and Management | | |link level | Parameters for Subscriber Access | | |OAM | Networks [IEEE802.3ah] | | | | | | Mizrahi, et al. Expires July 9, 2013 [Page 11] Internet-Draft Overview of OAM Mechanisms January 2013 | | Note: link level OAM was originally | | | | defined in IEEE 802.3ah, and is now | | | | incorporated in the 802.3 standard. | | +-----------+--------------------------------------+---------------+ Table 2 Non-IETF OAM Standards Mentioned in this Document 2. Basic Terminology 2.1. Abbreviations ACH Associated Channel Header AIS Alarm Indication Signal BFD Bidirectional Forwarding Detection CC Continuity Check CV Connectivity Verification DM Delay Measurement FEC Forwarding Equivalence Class GAL Generic Associated Label ICMP Internet Control Message Protocol LDP Label Distribution Protocol LM Loss Measurement LSP Label Switched Path ME Maintenance Entity MEG Maintenance Entity Group MEP MEG End Point MIP MEG Intermediate Point MP Maintenance Point MPLS Multiprotocol Label Switching Mizrahi, et al. Expires July 9, 2013 [Page 12] Internet-Draft Overview of OAM Mechanisms January 2013 MPLS-TP MPLS Transport Profile MTU Maximum Transmission Unit OAM Operations, Administration, and Maintenance PW Pseudowire PWE3 Pseudowire Emulation Edge-to-Edge RDI Remote Defect Indication TTL Time To Live VCCV Virtual Circuit Connectivity Verification TOM: Why is this section not at the top of this document, as is customary f= or RFCs? [TM] The introduction is now significantly shorter than it was when you sen= t this comment, which means that the terminology section is now much closer= to the beginning of the document. 2.2. Terminology used in OAM Standards 2.2.1. General Terms A wide variety of terms is used in various OAM standards. Each of the OAM standards listed in the reference section includes a section that defines terms relevant to that tool. A thesaurus of terminology for MPLS-TP terms is presented in [TP-Term], and provides a good summary of some of the OAM related terminology. This section presents a comparison of the terms used in various OAM standards, without fully quoting the definition of each term. For a formal definition of each term, refer to the references at the end of this document. 2.2.2. OAM Maintenance Entities OAM tools are designed to monitor and manage a Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a relationship between two points of a transport path to which maintenance and monitoring operations apply. The following related terms are also quoted from [TP-OAM-FW]: o MEP: The two points that define a maintenance entity. o MEG: The collection of one or more MEs that belongs to the same transport path and that are maintained and monitored as a group are known as a Maintenance Entity Group (MEG). Mizrahi, et al. Expires July 9, 2013 [Page 13] Internet-Draft Overview of OAM Mechanisms January 2013 o MIP: In between MEPs, there are zero or more intermediate points, called Maintenance Entity Group Intermediate Points (MIPs). A pair of MEPs engaged in an ME are connected by a communication link, which may be one of several types of connection, e.g. a single physical connection, a set of physical connections, or a virtual link such as an MPLS LSP. The term Maintenance Entity (ME) is used in ITU-T Recommendations (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology ([TP-OAM- FW]). Various terms are used to refer to an ME. For example, BFD does not explicitly use a term that is equivalent to ME, but rather uses the term "session", referring to the relationship between two nodes using a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) terminology simply uses the term "LSP" in this context. MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG) in [TP-OAM-FW], similar to the terms defined by ITU-T. A MEG allows the monitoring of a compound set of MEs, for example when monitoring a p2mp MEG that is considered to be the set of MEs between the root and each individual destination MEP. 2.2.3. OAM Maintenance Points A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages. A Maintenance End Point (MEP) is one of the end points of an ME, and can initiate OAM messages and respond to them. A Maintenance Intermediate Point (MIP) is an intermediate point between two MEPs, that does not generally initiate OAM frames (one exception to this is the use of AIS notifications), but is able to respond to OAM frames that are destined to it. A MIP in MPLS-TP identifies OAM packets destined to it by the value of the TTL field in the OAM packet. The term Maintenance Point is a general term for MEPs and MIPs. The 802.1ag defines a finer distinction between Up MPs and Down MPs. An MP is a bridge interface, that is monitored by an OAM protocol either in the direction facing the network, or in the direction facing the bridge. A Down MP is an MP that receives OAM packets from, and transmits them to the direction of the network. An Up MP receives OAM packets from, and transmits them to the direction of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the MP - either at the ingress, egress, or forwarding function of the node (Down / Up MPs). This placement is important for localization of a connection failure. Mizrahi, et al. Expires July 9, 2013 [Page 14] Internet-Draft Overview of OAM Mechanisms January 2013 2.2.4. Proactive and On-demand activation The different OAM tools may be used in one of two basic types of activation: o Proactive activation - indicates that the tool is activated on a continual basis periodically, where messages are sent between the two MEPs, and errors are detected when a certain number of expected messages are not received. o On-demand activation - indicates that the tool is activated "manually" to detect a specific anomaly. In this activation a small number of OAM messages are sent by a MEP and the reply message is received. 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. Continuity checks are used to verify the liveness of a connection or a path between two MPs, and are typically sent proactively, though they can be invoked on-demand as well. A connectivity verification function allows an MP to check whether it is connected to a peer MP or not. This function also allows the MP to verify that messages from the peer MP are received through the correct path, thereby verifying not only that the two MPs are connected, but also that they are connected through the expected path. This allows detection of unexpected topology changes. A connectivity verification (CV) protocol typically uses a CV message, followed by a CV reply that is sent back to the originator. A CV function can be applied proactively or on-demand. Connectivity verification and continuity checks are considered complementary mechanisms, and are often used in conjunction with each other. 2.2.6. Failures The terms Failure, Fault, and Defect are used interchangeably in the standards, referring to a malfunction that can be detected by a connectivity or a continuity check. In some standards, such as [IEEE802.1ag], there is no distinction between these terms, while in Mizrahi, et al. Expires July 9, 2013 [Page 15] Internet-Draft Overview of OAM Mechanisms January 2013 other standards each of these terms refers to a different type of malfunction. The terminology used in IETF MPLS-TP OAM takes after the ITU-T, which distinguishes between these terms in [ITU-T-G.806]; The term Fault refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. The term Defect refers to an interruption in the normal operation, such as a consecutive period of time where no packets are delivered successfully. The term Failure refers to the termination of the required function. While a Defect typically refers to a limited period of time, a failure refers to a long period of time. 3. OAM Tools 3.1. IP Ping and Traceroute 3.1.1. Ping Ping is a common network diagnosis application for IP networks that uses ICMP. The ICMP Echo request/reply exchange is a connectivity verification function for the Internet Protocol. The originator transmits an ICMP Echo request packet, and the receiver replies with an Echo reply. ICMP ping is defined in two variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6. 3.1.2. Traceroute Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to discover the path between an IP source and an IP destination. Traceroute sends a sequence of UDP packets to UDP port 33434 at the destination. By default, Traceroute begins by sending three packets (the number of packets is configurable in most Traceroute implementations), each with an IP Time-To-Live (TTL) value of one to the destination. These packets expire as soon as they reach the first router in the path. That router responds by sending three ICMP Time Exceeded Messages to the Traceroute application. Traceroute now sends another three UDP packets, each with the TTL value of 2. These messages cause the second router to return ICMP messages. This process continues, with ever increasing values for the TTL field, until the packets actually reach the destination. Because no application listens to port 33434 at the destination, the destination returns ICMP Destination Unreachable Messages indicating an unreachable port. This event indicates to the Traceroute application that it is finished. The Traceroute program displays the round-trip delay associated with each of the attempts. Mizrahi, et al. Expires July 9, 2013 [Page 16] Internet-Draft Overview of OAM Mechanisms January 2013 Note that IP routing may be asymmetric. While Traceroute reveals the path between a source and destination, it may not reveal the reverse path. A few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have been defined in the context of Traceroute. These extensions augment the ICMP Destination Unreachable message, and can be used by Traceroute applications. 3.2. Bidirectional Forwarding Detection (BFD) 3.2.1. Overview While multiple OAM mechanisms have been defined for various protocols in the protocol stack, Bidirectional Forwarding Detection [BFD], defined by the IETF BFD working group, is a generic OAM mechanism that can be deployed over various encapsulating protocols, and in various medium types. The IETF has defined variants of the protocol for IP ([BFD-IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for PWE3 [BFD-VCCV]. The usage of BFD in MPLS-TP is defined in [MPLS-TP-CC- CV]. BFD includes two main OAM functions, using two types of BFD packets: BFD Control packets, and BFD Echo packets. 3.2.2. BFD Control BFD supports a bidirectional continuity check, using BFD control packets, that are exchanged within a BFD session. BFD sessions operate in one of two modes: o Asynchronous mode (i.e. proactive): in this mode BFD control packets are sent periodically. When the receiver detects that no BFD control packet have been received during a predetermined period of time, a failure is detected. o Demand mode: in this mode, BFD control packets are sent on-demand. Upon need, a system initiates a series of BFD control packets to verify the liveness of the session. BFD control packets are sent independently in each direction. Each of the end-points of the monitored path maintains its own session identification, called a Discriminator, both of which are included in the BFD Control Packets that are exchanged between the end-points. At the time of session establishment, the Discriminators are exchanged between the two-end points. In addition, the transmission (and reception) rate is negotiated between the two end- Mizrahi, et al. Expires July 9, 2013 [Page 17] Internet-Draft Overview of OAM Mechanisms January 2013 points, based on information included in the control packets. These transmission rates may be renegotiated during the session. During normal operation of the session, i.e. no failures are detected, the BFD session is in the Up state. If no BFD Control packets are received during a fixed period of time, called the TOM: Fixed, pre-configured or negotiated period of time (i.e.: BFD interval= ) [TM] We rephrased this sentence. Detection Time, the session is declared to be Down. The detection time is a function of the negotiated transmission time, and a parameter called Detect Mult. Detect Mult determines the number of missing BFD Control packets that cause the session to be declared as Down. This parameter is included in the BFD Control packet. 3.2.3. BFD Echo A BFD echo packet is sent to a peer system, and is looped back to the originator. The echo function can be used proactively, or on-demand. The BFD echo function has been defined in BFD for IPv4 and IPv6 ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for MPLS-TP. 3.3. MPLS OAM The IETF MPLS working group has defined OAM for MPLS LSPs. The requirements and framework of this effort are defined in [MPLS-OAM- FW] and [MPLS-OAM], respectively. The corresponding OAM mechanism defined, in this context, is LSP Ping [LSP-Ping]. LSP Ping is based on ICMP Ping and just like its predecessor may be used in one of two modes: o "Ping" mode: In this mode LSP ping is used for end-to-end connectivity verification between two LERs. o "Traceroute" mode: This mode is used for hop-by-hop fault isolation. LSP Ping extends the basic ICMP Ping operation (of data-plane connectivity verification) with functionality to verify data-plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC) and also Maximum Transmission Unit (MTU) problems. The traceroute functionality may be used to isolate and localize the MPLS faults, using the Time-to-live (TTL) indicator to incrementally identify the sub-path of the LSP that is successfully traversed before the faulty link or node. Mizrahi, et al. Expires July 9, 2013 [Page 18] Internet-Draft Overview of OAM Mechanisms January 2013 It should be noted that LSP Ping supports unique identification of the LSP within an addressing domain. The identification is checked using the full FEC identification. LSP Ping is easily extensible to include additional information needed to support new functionality, by use of Type-Length-Value (TLV) constructs. The usage of TLVs is typically not easy to perform in hardware, and is thus typically handled by the control plane. LSP Ping supports both asynchronous, as well as, on-demand activation. 3.4. MPLS-TP OAM 3.4.1. Overview The MPLS working group is currently working on defining the OAM toolset that fulfills the requirements for MPLS-TP OAM. The full set of requirements for MPLS-TP OAM are defined in [MPLS-TP-OAM], and include both general requirements for the behavior of the OAM mechanisms and a set of operations that should be supported by the OAM toolset. The set of mechanisms required are further elaborated in [TP-OAM-FW], which describes the general architecture of the OAM system as well as giving overviews of the functionality of the OAM toolset. Some of the basic requirements for the OAM toolset for MPLS-TP are: o MPLS-TP OAM must be able to support both an IP based and non-IP based environment. If the network is IP based, i.e. IP routing and forwarding are available, then the MPLS-TP OAM toolset should rely on the IP routing and forwarding capabilities. On the other hand, in environments where IP functionality is not available, the OAM tools must still be able to operate without dependence on IP forwarding and routing. o OAM packets and the user traffic are required to be congruent (i.e. OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from user-plane ones. Inherent in this requirement is the principle that MPLS-TP OAM be independent of any existing control-plane, although it should not preclude use of the control-plane functionality. 3.4.2. Generic Associated Channel In order to address the requirement for in-band transmission of MPLS- TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based Mizrahi, et al. Expires July 9, 2013 [Page 19] Internet-Draft Overview of OAM Mechanisms January 2013 on the same concepts as the PWE3 ACH and VCCV mechanisms. However, to address the needs of LSPs as differentiated from PW, the following concepts were defined for [G-ACh]: o An Associated Channel Header (ACH), that uses a format similar to the PW Control Word, is a 4-byte header that is prepended to OAM packets. o A Generic Associated Label (GAL). The GAL is a reserved MPLS label value (13) that indicates that the packet is an ACH packet and the payload follows immediately after the label stack. 3.4.3. MPLS-TP OAM Toolset To address the functionality that is required of the OAM toolset, the MPLS WG conducted an analysis of the existing IETF and ITU-T OAM mechanisms and their ability to fulfill the required functionality. The conclusions of this analysis are documented in [OAM-Analys]. The MPLS working group currently plans to use a mixture of OAM mechanisms that are based on various existing standards, and adapt them to the requirements of [MPLS-TP-OAM]. Some of the main building blocks of this solution are based on: o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for proactive continuity check and connectivity verification. o LSP Ping as defined in [LSP-Ping] for on-demand connectivity verification. o New protocol packets, using G-ACH, to address different functionality. o Performance measurement protocols that are based on the functionality that is described in [ITU-T-Y1731]. The following sub-sections describe the OAM tools defined for MPLS-TP as described in [TP-OAM-FW]. 3.4.3.1. Continuity Check and Connectivity Verification Continuity Check and Connectivity Verification are presented in Section 2.2.5. of this document. As presented there, these tools may be used either proactively or on-demand. When using these tools proactively, they are generally used in tandem. For MPLS-TP there are two distinct tools, the proactive tool is defined in [TP-CC-CV] while the on-demand tool is defined in Mizrahi, et al. Expires July 9, 2013 [Page 20] Internet-Draft Overview of OAM Mechanisms January 2013 [OnDemand-CV].Proactively [MPLS-TP-OAM] states that the function should allow the MEPs to monitor the liveness and connectivity of a transport path. In on-demand mode, this function should support monitoring between the MEPs and, in addition, between a MEP and MIP. [TP-OAM-FW] highlights, when performing Connectivity Verification, the need for the CC-V messages to include unique identification of the MEG that is being monitored and the MEP that originated the message. The proactive tool [TP-CC-CV] is based on extensions to BFD (see Section 3.2. ) with the additional limitation that the transmission and receiving rates are based on configuration by the operator. The on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see Section 3.3. ) for the required behavior of MPLS-TP. 3.4.3.2. Route Tracing [MPLS-TP-OAM] defines that there is a need for functionality that would allow a path end-point to identify the intermediate and end- points of the path. This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP, and sections, however, unidirectional paths may be supported only if a return path exists. The tool for this is based on the LSP Ping (see Section 3.3. ) functionality and is described in [OnDemand-CV]. 3.4.3.3. Lock Instruct The Lock Instruct function [Lock-Loop] is used to notify a transport path end-point of an administrative need to disable the transport path. This functionality will generally be used in conjunction with some intrusive OAM function, e.g. Performance measurement, Diagnostic testing, to minimize the side-effect on user data traffic. 3.4.3.4. Lock Reporting Lock Reporting is a function used by an end-point of a path to report to its far-end end-point that a lock condition has been affected on the path. 3.4.3.5. Alarm Reporting Alarm Reporting is a function used by an intermediate point of a path, that becomes aware of a fault on the path, to report to the end-points of the path. [TP-OAM-FW] states that this may occur as a result of a defect condition discovered at a server sub-layer. This generates an Alarm Indication Signal (AIS) that continues until the Mizrahi, et al. Expires July 9, 2013 [Page 21] Internet-Draft Overview of OAM Mechanisms January 2013 fault is cleared. The consequent action of this function is detailed in [TP-OAM-FW]. 3.4.3.6. Remote Defect Indication Remote Defect Indication (RDI) is used proactively by a path end- point to report to its peer end-point that a defect is detected on a bidirectional connection between them. [MPLS-TP-OAM] points out that this function may be applied to a unidirectional LSP only if there a return path exists. [TP-OAM-FW] points out that this function is associated with the proactive CC-V function. 3.4.3.7. Client Failure Indication Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow the propagation information from one edge of the network to the other. The information concerns a defect to a client, in the case that the client does not support alarm notification. 3.4.3.8. Packet Loss Measurement (LM) Packet Loss Measurement is a function used to verify the quality of the service. This function indicates the ratio of packets that are not delivered out of all packets that are transmitted by the path source. There are two possible ways of determining this measurement: o Using OAM packets, it is possible to compute the statistics based on a series of OAM packets. This, however, has the disadvantage of being artificial, and may not be representative since part of the packet loss may be dependent upon packet sizes. TOM: Not just packet sizes. Things like implementation (as I mentioned abov= e with the comment about the accuracy or truthfulness of the data plane pro= cessing of OAM packets). Doing very accurate RTT as a simple example, with= just IP Pings, is a tricky thing to make work. Also, it is important to m= ention that the scale in terms of number of packets, number of tests, etc..= . can and will impact these parameters too. [TM] Following your comment we rephrased this sentence. o Sending delimiting messages for the start and end of a measurement period during which the source and sink of the path count the packets transmitted and received. After the end delimiter, the ratio would be calculated by the path OAM entity. 3.4.3.9. Packet Delay Measurement (DM) Packet Delay Measurement is a function that is used to measure one- way or two-way delay of a packet transmission between a pair of the end-points of a path (PW, LSP, or Section). Where: Mizrahi, et al. Expires July 9, 2013 [Page 22] Internet-Draft Overview of OAM Mechanisms January 2013 o One-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of that packet by the destination node. o Two-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop-backed packet by the same source node, when the loopback is performed at the packet's destination node. Similarly to the packet loss measurement this could be performed in either of the two ways outlined above. 3.5. PWE3 OAM 3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV) VCCV, as defined in [VCCV], provides a means for end-to-end fault detection and diagnostics tools to be extended for PWs (regardless of the underlying tunneling technology). The VCCV switching function provides a control channel associated with each PW (based on the PW Associated Channel Header (ACH) which is defined in [PW-ACH]), and allows transmitting the OAM packets in-band with PW data (using CC Type 1: In-band VCCV). VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of encapsulation - either IP/UDP encapsulated (with IP/UDP header) or PW-ACH encapsulated (with no IP/UDP header) and provides support to signal the AC status. The use of the VCCV control channel provides the context, based on the MPLS-PW label, required to bind and bootstrap the BFD session to a particular pseudo wire (FEC), eliminating the need to exchange Discriminator values. VCCV consists of two components: (1) signaled component to communicate VCCV capabilities as part of VC label, and (2) switching component to cause the PW payload to be treated as a control packet. VCCV is not directly dependent upon the presence of a control plane. The VCCV capability negotiation may be performed as part of the PW signaling when LDP is used. In case of manual configuration of the PW, it is the responsibility of the operator to set consistent options at both ends. TOM: Might be helpful to note that the static mode was created specifically= to handle the MPLS-TP cases where no control plane was a requirement. Howe= ver, new use cases such as pure mobile backhaul, etc... find this functiona= lity useful too. [TM] Following your comment we added some text to explain this. Mizrahi, et al. Expires July 9, 2013 [Page 23] Internet-Draft Overview of OAM Mechanisms January 2013 3.5.2. PWE3 OAM using G-ACh As mentioned above, VCCV enables OAM for PWs by using a control channel for OAM packets. When PWs are used in MPLS-TP networks, rather than the control channels defined in VCCV, the G-ACh can be used as an alternative control channel. The usage of the G-ACh for PWs is defined in [PW-G-ACh]. 3.6. OWAMP and TWAMP 3.6.1. Overview The IPPM working group in the IETF defines common criteria and metrics for measuring performance of IP traffic ([IPPM-FW]). Some of the key RFCs published by this working group have defined metrics for measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), and packet loss [IPPM-1LM]. Alternative protocols for performance measurement are defined, for example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet OAM [ITU-T-Y1731]. The IPPM working group has defined not only metrics for performance measurement, but also protocols that define how the measurement is carried out. The One-way Active Measurement Protocol [OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] define a method and protocol for measuring delay and packet loss in IP networks. OWAMP [OWAMP] enables measurement of one-way characteristics of IP networks, such as one-way packet loss and one-way delay. For its proper operation OWAMP requires accurate time of day setting at its end points. TWAMP [TWAMP] is a similar protocol that enables measurement of two- way (round trip) characteristics. TWAMP does not require accurate time of day, and, furthermore, allows the use of a simple session reflector, making it an attractive alternative to OWAMP. OWAMP and TWAMP use two separate protocols: a Control plane protocol, and a Test plane protocol. 3.6.2. Control and Test Protocols OWAMP and TWAMP control protocols run over TCP, while the test protocols run over UDP. The purpose of the control protocols is to initiate, start, and stop test sessions, and for OWAMP to fetch results. The test protocols introduce test packets (which contain Mizrahi, et al. Expires July 9, 2013 [Page 24] Internet-Draft Overview of OAM Mechanisms January 2013 sequence numbers and timestamps) along the IP path under test according to a schedule, and record statistics of packet arrival. Multiple sessions may be simultaneously defined, each with a session identifier, and defining the number of packets to be sent, the amount of padding to be added (and thus the packet size), the start time, and the send schedule (which can be either a constant time between test packets or exponentially distributed pseudo-random). Statistics recorded conform to the relevant IPPM RFCs. OWAMP and TWAMP test traffic is designed with security in mind. Test packets are hard to detect because they are simply UDP streams between negotiated port numbers, with potentially nothing static in the packets. OWAMP and TWAMP also include optional authentication and encryption for both control and test packets. 3.6.3. OWAMP OWAMP defines the following logical roles: Session-Sender, Session- Receiver, Server, Control-Client, and Fetch-Client. The Session- Sender originates test traffic that is received by the Session- Receiver. The Server configures and manages the session, as well as returning the results. The Control-Client initiates requests for test sessions, triggers their start, and may trigger their termination. The Fetch-Client requests the results of a completed session. Multiple roles may be combined in a single host - for example, one host may play the roles of Control-Client, Fetch-Client, and Session-Sender, and a second playing the roles of Server and Session-Receiver. In a typical OWAMP session the Control-Client establishes a TCP connection to port 861 of the Server, which responds with a server greeting message indicating supported security/integrity modes. The Control-Client responds with the chosen communications mode and the Server accepts the modes. The Control-Client then requests and fully describes a test session to which the Server responds with its acceptance and supporting information. More than one test session may be requested with additional messages. The Control-Client then starts a test session and the Server acknowledges. The Session- Sender then sends test packets with pseudorandom padding to the Session-Receiver until the session is complete or until the Control- client stops the session. Once finished, the Fetch-Client sends a fetch request to the server, which responds with an acknowledgement and immediately thereafter the result data. Mizrahi, et al. Expires July 9, 2013 [Page 25] Internet-Draft Overview of OAM Mechanisms January 2013 3.6.4. TWAMP TWAMP defines the following logical roles: session-sender, session- reflector, server, and control-client. These are similar to the OWAMP roles, except that the Session-Reflector does not collect any packet information, and there is no need for a Fetch-Client. In a typical TWAMP session the Control-Client establishes a TCP connection to port 862 of the Server, and mode is negotiated as in OWAMP. The Control-Client then requests sessions and starts them. The Session-Sender sends test packets with pseudorandom padding to the Session-Reflector which returns them with insertion of timestamps. 3.7. Summary of OAM Functions Table 3 summarizes the OAM functions that are supported in each of the categories that were analyzed in this section. +-----------+-------+--------+--------+-----------+-------+--------+ | Standard |Continu|Connecti|Path |Defect |Perform|Other | | |ity |vity |Discover|Indications|ance |Function| | |Check |Verifica|y | |Monitor|s | | | |tion | | |ing | | +-----------+-------+--------+--------+-----------+-------+--------+ |IP Ping | |Echo | | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |IP | | |Tracerou| | | | |Traceroute | | |te | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |BFD |BFD |BFD | | | | | | |Control|Echo | | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |MPLS OAM | |"Ping" |"Tracero| | | | |(LSP Ping) | |mode |ute" | | | | | | | |mode | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |MPLS-TP |CC |CV/pro- |Route |-Alarm |-LM |-Diagnos| |OAM | |active |Tracing | Reporting |-DM | tic Tes| | | |or on- | |-Client | | t | | | |demand | | Failure | |-Lock | | | | | | Indication| | | | | | | |-Remote | | | Mizrahi, et al. Expires July 9, 2013 [Page 26] Internet-Draft Overview of OAM Mechanisms January 2013 | | | | | Defect | | | | | | | | Indication| | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |PWE3 OAM |BFD |-BFD |LSP-Ping| | | | | | |-ICMP | | | | | | | | Ping | | | | | | | |-LSP- | | | | | | | | Ping | | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |OWAMP and | | | | |-Delay | | |TWAMP | | | | | measur| | | | | | | | ement | | | | | | | |-Packet| | | | | | | | loss | | | | | | | | measur| | | | | | | | ement | | +-----------+-------+--------+--------+-----------+-------+--------+ Table 3 Summary of OAM Functions 4. Security Considerations This memo presents an overview of existing OAM mechanisms, and proposes no new OAM mechanisms. Therefore, this document introduces no security considerations. However, the OAM mechanism reviewed in this document can and do present security issues. The reader is encouraged to review the Security Considerations section of each document reference by this memo. 5. IANA Considerations There are no new IANA considerations implied by this document. 6. Acknowledgments The authors gratefully acknowledge Sasha Vainshtein, Carlos Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other members of the OPSAWG mailing list for their helpful comments. This document was prepared using 2-Word-v2.0.template.dot. Mizrahi, et al. Expires July 9, 2013 [Page 27] Internet-Draft Overview of OAM Mechanisms January 2013 7. References 7.1. Normative References [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., Matsushima, S., "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006. [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002. [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for OAM in MPLS Transport Networks", RFC 5860, May 2010. [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic Associated Channel", RFC 5586, June 2009. [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T., "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006. Mizrahi, et al. Expires July 9, 2013 [Page 28] Internet-Draft Overview of OAM Mechanisms January 2013 [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007. [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers, JR., "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010. [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and TCP/IP Tools and Utilities", RFC 2151, June 1997. [NetTools] Stine, R., "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", RFC 1147, April 1990. [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework for IP Performance Metrics", RFC 2330, May 1998. [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [IPPM-2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and Zekauskas, M., "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and Babiarz, J., "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008. [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. Mizrahi, et al. Expires July 9, 2013 [Page 29] Internet-Draft Overview of OAM Mechanisms January 2013 [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [BFD-Gen] Katz, D., Ward, D., "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010. [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration and Maintenance Framework for MPLS-based Transport Networks ", RFC 6371, September 2011. [TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile", RFC 6428, November 2011. [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011. [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. [TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011. [TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011. Mizrahi, et al. Expires July 9, 2013 [Page 30] Internet-Draft Overview of OAM Mechanisms January 2013 [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., Dai, X., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011. [ITU-T-CT] Betts, M., "Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)", RFC 6671, November 2012. [PW-Map] M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011. [PW-G-ACh] Li, H., Martini, L., He, J., Huang, F., "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, November 2011. 7.2. Informative References [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, D., Mansfield, S., "Guidelines for the use of the OAM acronym in the IETF ", RFC 6291, June 2011. [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool Set for MPLS based Transport Networks", RFC 6669, July 2012. [TP-Term] Van Helvoort, H., Andersson, L., Sprecher, N., "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations", work-in-progress, draft-ietf-mpls- tp-rosetta-stone, July 2012. [IEEE802.1ag] IEEE 802.1Q, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", October 2012. [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and Mechanisms for Ethernet-based Networks", July 2011. [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance mechanism for MPLS networks", February 2004. Mizrahi, et al. Expires July 9, 2013 [Page 31] Internet-Draft Overview of OAM Mechanisms January 2013 [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology - Local and metropolitan area networks - Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", clause 57, December 2008. [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January 2009. [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS", November 2012. [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)", November 2012. Authors' Addresses Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com Elisa Bellagamba Ericsson 6 Farogatan St. Stockholm, 164 40 Sweden Mizrahi, et al. Expires July 9, 2013 [Page 32] Internet-Draft Overview of OAM Mechanisms January 2013 Phone: +46 761440785 Email: elisa.bellagamba@ericsson.com Yaacov Weingarten 34 Hagefen St. Karnei Shomron, 4485500 Israel Email: wyaacov@gmail.com draft-ietf-opsawg-oam-overview authors, Here is my feedback on this document. 1. Is this document in line with http://tools.ietf.org/html/draft-ietf-trill-o= am-req-04? * For example, the following definitions could be reused. Fault: The term Fault refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. Defect: The term Defect refers to an interruption in the normal operation, such that over a period of time no packets are delivered successfully. Failure: The term Failure refers to the termination of the required function over a longer period of time. Persistence of a defect for a period of time is interpreted as a failure. * For example, on the basic abstract Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. Abstract (draft-ietf-trill-oam-req-04) OAM (Operations, Administration and Maintenance) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents, OAM Requirements applicable to TRILL. So, as an example: does OAM include function? I advice to review draft-ietf-trill-oam-req-04 2. draft-ietf-trill-oam is not mentioned, while the abstract mentions: This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. Search for OAM in the current draft names (https://datatracker.ietf.org/), = and you will find many references. Ok, I see later on: This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM- related work is outside the scope. Ok, fine then: we don't need a reference to all the drafts. However, draft-ietf-trill-oam is closed to be a RFC, and should be mentione= d. 3. Section 1 The term OAM in this document refers to Operations, Administration and Maintenance [OAM-Def], focusing on the forwarding plane of OAM. What does it mean "focusing on the forwarding plane of OAM"? Do you take a subset of the definition for this document? Btw, I don't see a definition in the terminology section. In section 2.2.3 A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages. Which plane is MP? 4. Section 1, Introduction "Hence, management aspects are outside the scope of this document." I don't understand which management aspects we speak about here. 5. Clarifying question regarding 1.2 If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, cont= rol plane, or management plane? Note that I found later on in the draft: OWAMP and TWAMP use two separate protocols: a Control plane protocol, and a Test plane protocol. Interestingly enough, after reading the document, I reviewed http://datatra= cker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, and saw the same = feedback from Stewart Bryant: Provide a clear view of OAM functionality and its relationship to various "planes" of networking (data plane, control plane, management plane). In particular, the importance of fate-sharing of OAM and user traffic flows in packet networks should be explained. 6. I see a multiplication of "plane" terms in the IETF document, and in this d= ocument in particular. I could find: forwarding plane, management plane, control plane, data plane= , user plane, and test plane. Way too many. Please be consistent 7. Table 1 summarizes the IETF OAM related RFCs discussed in this document. Table 2 summarizes the OAM standards mentioned in this document. You need to change the Table 2 description. Do you want to say something al= ong the lines of: Table 2 summarizes the OAM standards specified by other Standard Develop= ment Organization (SDO) than the IETF, along with IETF references where applicable. 8. Section 2.2.1 For a formal definition of each term, refer to the references at the end= of this document. Without a reference to a specific RFC, this is the type of statement which = is not useful: you have 5 pages of references. You position this document as "An Overview of Operations, Administration, a= nd Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to = know about the terms, just read first all references!" 9. You specify some terms and some OAM categories, 2.2.2. OAM Maintenance Entities .......................... 13 2.2.3. OAM Maintenance Points ............................ 14 2.2.4. Proactive and On-demand activation ................ 15 2.2.5. Connectivity Verification and Continuity Checks ... 15 2.2.6. Failures .......................................... 15 ... but you don't use them in the section 3 Just one example with section 3.2.2 - o Demand mode: in this mode, BFD control packets are sent on-demand. Upon need, a system initiates a series of BFD control packets to verify the liveness of the session Instead of liveness, you have defined Connectivity Verification and Continu= ity Checks in section 2.2.5 - OLD: Each of the end-points of the monitored path maintains its own session identification NEW: Each of the MEP maintains its own session identification OR NEW (actually I don't know) Each of the MP maintains its own session identification - OLD A BFD echo packet is sent to a peer system Peer system =3D MEP, MP, or something else? - etc... 10. This document is composed of a list of OAM content and references, but I'm = really missing the document "scope and target audience". When we did RFC 6632, which is the companion document, we had http://tools.= ietf.org/html/rfc6632#section-1.1 The target audience of the document is, on the one hand, IETF working groups, which aim to select appropriate standard management protocols and data models to address their needs concerning network management. On the other hand, the document can be used as an overview and guideline by non-IETF Standards Development Organizations (SDOs) planning to use IETF management technologies and data models for the realization of management applications. The document can also be used to initiate a discussion between the bodies with the goal to gather new requirements and to detect possible gaps. Finally, this document is directed to all interested parties that seek to get an overview of the current set of the IETF network management protocols such as network administrators or newcomers to the IETF. You should have something similar. 11. Section 3.6.1, put the paragraph 2 at the end of the section. The "alternat= ive" in the following sentence would then make sense Alternative protocols for performance measurement are defined, for example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet OAM [ITU-T-Y1731]. My conclusions: this document still needs some work Regards, Benoit The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-25. Exceptiona= lly, comments may be sent to iesg@ietf.org instead. In either case, please= retain the beginning of the Subject line to allow automated sorting. Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ No IPR declarations have been submitted directly on this I-D. --_000_74470498B659FA4687F0B0018C19A89C01D43919C2A4ILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tom,

 

Thanks for the prompt response.

We will apply this change in the next dr= aft.

 

Thanks,

Tal.

 

From:= Tho= mas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Tuesday, Janua= ry 28, 2014 5:38 PM
To: Tal Mizrahi
Cc: draft-ietf-opsa= wg-oam-overview@tools.ietf.org; opsawg@ietf.org; opsawg-chairs@tools.ietf.o= rg; Benoit Claise; joel jaeggli (joelja@bogus.com); Scott O. Bradner (sob@h= arvard.edu)
Subject: Re: Last Call: <draft-ietf-opsawg-oam-ove= rview-08.txt> (An Overview of Operations, Administration, and Maintenanc= e (OAM) Mechanisms) to Informational RFC

<= p class=3DMsoNormal> 

 

 &= nbsp;          The chan= ges look ok except for one minor one:

 

         =    One of the changes in 4.4.2 BFD for MPLS states the fol= lowing:

 

=
<= td valign=3Dtop style=3D'background:white;padding:0in 1.5pt 0in 1.5pt'>

The advantage of BFD is that it can

   provide faster failure detection= , and scales better to a large number

   of LSPs

 

 <= /o:p>

 

    &nb= sp;       That is a popular misconcept= ion. When I at a previous gig we were able to actually figure out how to ma= ke them both perform

equally = well for CV operations, but we just decided to not implement it that way. I= 'd suggest removing that sentence altogether.

They are two tools with different implementations, some mo= re optimal than others. 

 

            =

 

=

Hi Tom,

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Thanks again = for your comments.

A link = to the updated draft:

http:/= /tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13

 

We believe the current draft addresses all the comments below= .

We have replied to ever= y single comment below (search for [TM]).

 

Ple= ase let us know if you believe something is still amiss.<= /p>

 

Thanks,

Tal= .

 =

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
= Sent: Monday, January 20, 2014 5:29 PM
To: Benoit Claise
<= b>Cc: = draft-ietf-opsawg-oam-overview@tools.ietf.org; opsawg@ietf.org; IETF Disgust
Subject: Re: Last Ca= ll: <draft-ietf-opsawg-oam-overview-08.txt> (An Overview of Operation= s, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC

 

<= div>

 

        =     Reviewing the current version of the draft (12), = many of the comments below are still not addressed.

 

        &nb= sp;   --Tom

=  

 

<= div>

 

Here is Tom Nadeau's feedback, forwarded with per= mission:

Regards, Benoit

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Some general comments:<= /o:p>

 

  1. I did not find any discussi= on around use of configuration within OAM mechanisms. This is clearly somet= hing that is happening in groups like PWE3 and CCAMP. The motivation for th= is should be explained and documented to at least guide these efforts.=

[TM] The current draft includes a signi= ficantly clearer explanation, up front  in the abstract and introducti= on, that this document focuses on OAM tools, i.e., on the data plane of OAM= . That is why, for example we do not discuss configuration contexts such as= CCAMP.

2. There is = no real discussion around the security aspects of these tools. Should there= be?

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

[TM] We received a similar comment from other reviewers, as well as the Se= cDir review in the previous IETF last call. After some discussion between o= ur AD at the time (Ron Bonica) and the Sec AD (Sean Turner), the current ph= rasing of the "Security Considerations" section was agreed. It is= mainly an issue of where you draw the line between which content to includ= e and which content not to include in the draft, and security is currently = out of scope.

 

3. While the document= provides a nice taxonomy of various OAM tools, it does not really discuss = the techniques for using them. I do not expect anything in detail, but it i= s not obvious that many of these tools can be orchestrated to form a "= toolset" that can be used to do multi-layer OAM functions for services= such as carrier Ethernet over VPLS over MPLS, for example.

<= p class=3DMsoNormal> 

[TM] Following your comment, we added quite a b= it of text to the introduction to explain this multi-layer orchestration. Y= ou can take full credit for the fact that this doll IETF draft now includes= an ASCII art figure (Figure 1). :)

 

 

4. It might be useful to at least mention in the performance metrics = section, a discussion around the accuracy of these tools and how it depends= on scale, implementation and network configurations.

[TM] Following your comment we added a note abou= t this in section 4.7.1. See the paragraphs beginning with “It should= be noted that while [OWAMP]…”.

 

 

My detailed co= mments inline starting with TOM:

 

--Tom

 

 

 

 

 

 

Expires: July 2013          =                     &nbs= p;Nokia Siemens Networks

&nbs= p;                     &n= bsp;                     =                E. Bellagamba

          =                      = ;                     &nb= sp;           Ericsson

                =                      = ;                     &nb= sp;Y. Weingarten

 <= /o:p>

         =                     &nbs= p;                     &n= bsp;    January 9, 2013

 

    &nb= sp;                     &= nbsp;   An Overview of

&= nbsp;       Operations, Administration, and Maintenance (OAM= ) Mechanisms

    &n= bsp;              draft-ietf-opsawg-oam-= overview-08.txt

 

 

Abstract

&n= bsp;

   Operations,= Administration, and Maintenance (OAM) is a general term

=

   that refers to a toolset that can be used= for fault detection and

&nbs= p;  isolation, and for performance measurement. OAM mechanisms have be= en

   defined for v= arious layers in the protocol stack, and are used with a

   variety of protocols.

 

   This document presents an overview of the OAM mec= hanisms that have

  &nbs= p;been defined and are currently being defined by the IETF.

<= /div>

 

Status of this Memo

=  

   This Inte= rnet-Draft is submitted to IETF in full conformance with the

=

   provisions of BCP 78 and BCP 7= 9.

 

   Internet-Drafts are working documen= ts of the Internet Engineering

   Task Force (IETF), its areas, and its working groups.  = Note that

   other = groups may also distribute working documents as Internet-

   Drafts.

=

 

&= nbsp;  Internet-Drafts are draft documents valid for a maximum of six = months

   and may b= e updated, replaced, or obsoleted by other documents at any

<= /div>

   time.  It is inappropriate= to use Internet-Drafts as reference

   material or to cite them other than as "work in p= rogress."

 

   The list of current Int= ernet-Drafts can be accessed at

 

  =  The list of Internet-Draft Shadow Directories can be accessed at=

 

   This Internet-Draft will expire on July 9, 2013.

 

=

 

&= nbsp;

Mizrahi, et al.   =       Expires July 9, 2013          = ;        [Page 1]

Internet-Draft       Overview of OAM Mechanisms &nb= sp;         January 2013

 

 =

Copyright Notice<= /p>

 

   Copyright (c) 2013 IETF Trust and the persons ide= ntified as the

   d= ocument authors. All rights reserved.

 

   = This document is subject to BCP 78 and the IETF Trust's Legal

   Provisions Relating to IETF D= ocuments

   (http://trustee.ietf.org/license-= info) in effect on the date of

   publication of this document. Please review these docume= nts

   carefully, a= s they describe your rights and restrictions with respect

   to this document. Code Components= extracted from this document must

   include Simplified BSD License text as described in Sect= ion 4.e of

   the T= rust Legal Provisions and are provided without warranty as

   described in the Simplified BSD = License.

 

Table of Contents

 

=  

   1. Introd= uction ................................................. 3

      1.1. The Building Blocks= of OAM .............................. 3

      1.2. Forwarding Plane vs. Management Plan= e ................... 4

 = ;     1.3. The OAM toolsets .....................................= ... 4

      1.= 4. IETF OAM Documents ...................................... 6

      1.5. Non-IETF OAM Do= cuments ................................. 10

   2. Basic Terminology .........................= .................. 12

  =     2.1. Abbreviations ..........................................= 12

      2.2.= Terminology used in OAM Standards ...................... 13

=

         2.2.1. Ge= neral Terms ..................................... 13

         2.2.2. OAM Mainte= nance Entities .......................... 13

         2.2.3. OAM Maintenance Po= ints ............................ 14

         2.2.4. Proactive and On-demand ac= tivation ................ 15

=          2.2.5. Connectivity Verification and Cont= inuity Checks ... 15

  &= nbsp;      2.2.6. Failures .................................= ......... 15

   3. = OAM Tools ................................................... 16=

      3.1. IP Ping and T= raceroute ................................. 16

         3.1.1. Ping ...........= ................................... 16

         3.1.2. Traceroute..............= ........................... 16

      3.2. Bidirectional Forwarding Detection (BFD) ......= ......... 17

    &n= bsp;    3.2.1. Overview .........................................= . 17

      &nb= sp;  3.2.2. BFD Control ....................................... 17

        &nbs= p;3.2.3. BFD Echo .......................................... 18<= /p>

      3.3. MPLS OAM .....= .......................................... 18

      3.4. MPLS-TP OAM ....................= ........................ 19

&= nbsp;        3.4.1. Overview ..........................= ................ 19

  &n= bsp;      3.4.2. Generic Associated Channel ................= ........ 19

    &nb= sp;    3.4.3. MPLS-TP OAM Toolset ...............................= 20

      &nbs= p;     3.4.3.1. Continuity Check and Connectivity Verification 20=

 

<= div>

 

Mizrahi, et al.         Expires July 9, 2013   =                [Page 2]<= /p>

Internet-Draft       Over= view of OAM Mechanisms           January 2013=

 

<= p class=3DMsoNormal> 

&n= bsp;           3.4.3.2. Route Tracing ............= .................... 21

 = ;           3.4.3.3. Lock Instruct ...............= ................. 21

  &= nbsp;         3.4.3.4. Lock Reporting .................= .............. 21

  &nbs= p;         3.4.3.5. Alarm Reporting ...................= ........... 21

    =         3.4.3.6. Remote Defect Indication .............= ........ 22

    &nb= sp;       3.4.3.7. Client Failure Indication ...............= ..... 22

     =       3.4.3.8. Packet Loss Measurement (LM) ...............= .. 22

      &n= bsp;     3.4.3.9. Packet Delay Measurement (DM) ................ = 22

      3.5. = PWE3 OAM ............................................... 23

<= /div>

         3.5.1. PWE= 3 OAM using Virtual Circuit Connectivity Verification

<= div>

         (VCCV) .........= .......................................... 23

         3.5.2. PWE3 OAM using G-= ACh .............................. 24

      3.6. OWAMP and TWAMP.........................= ................ 24

  &n= bsp;      3.6.1. Overview ..................................= ........ 24

    &nb= sp;    3.6.2. Control and Test Protocols ........................= 24

      &nbs= p;  3.6.3. OWAMP ............................................. 25=

         = ;3.6.4. TWAMP ............................................. 26

      3.7. Summary of OAM = Functions ............................... 26

   4. Security Considerations ...................= .................. 27

  =  5. IANA Considerations ......................................... 27

   6. Acknowledgment= s ............................................. 27

   7. References ..........................= ........................ 28

&= nbsp;     7.1. Normative References .............................= ...... 28

     = ; 7.2. Informative References ................................. 31

 

1. Introduction

 

   OAM is= a general term that refers to a toolset for detecting,

   isolating and reporting connection = failures and performance

&nbs= p;  degradation.

 

   This document summarize= s the OAM tools and mechanisms defined in the

   IETF.

 

   Th= e term OAM in this document refers to Operations, Administration=

   and Maintenance [OAM-Def],= focusing on the forwarding plane of OAM.

   Hence, management aspects are outside the scope o= f this document.

 

TOM: This is a curiou= s sentence to me since to me, OAM is management, or a subset of it.   = Also, if you look at the referenced documents, there are many indirect refe= rences to MIBs, Netconf, etc… making this sentence further confusing.= It might be helpful to explain more clearly that the authors here intended= to not cover those things explicitly rather than grouping them arbitrarily= under the definition of "management aspects"  Further, to c= larify, it might be useful to expand on what "forwarding plane" i= s here just to be clear.   That is, is this "in band" or &qu= ot;out-of band" or both? Some of the tools referred to here also are p= art of the control AND data planes. 

[TM] We significantly improved the distinction between the d= ifferent planes: data plane, control plane, management plane. We added a de= finition of each of the terms, and we now explicitly explain that the draft= focuses on the data plane. We also explain in the current draft that we ad= opt the OAM acronym as recommended in RFC 6291: Operations, Administration = and Maintenance (without Management...). Please let us know if you think so= mething is still missing here.

 

&n= bsp;

1.1. The Building Blocks of OAM

 

   An OAM protocol is run in the context of a Mainte= nance Domain,

   co= nsisting of two or more nodes that run the OAM protocol, referred

   to as Maintenance Points = (MP).

 

   This subsection provides a brief= summary of the common tools used by

   OAM protocols. An OAM protocol typically supports one = or more of the

   t= ools described below.

 <= o:p>

 

Mizrahi, et al.         Expires= July 9, 2013                  = ;[Page 3]

Internet-Draft &nbs= p;     Overview of OAM Mechanisms         &nb= sp; January 2013

 <= /o:p>

 

   o Continuity Checking (CC):

<= /div>

      Used for verifying the = liveness of a connection between two MPs.

 

  &n= bsp;o Connectivity Verification (CV):

      Allows an MP to check whether it is connected= to a peer MP, and to

  =     verify that messages from the peer MP are received through th= e

      expect= ed path.

 

   o Path Discovery / Fault Loca= lization:

     = ; An MP uses this mechanism to trace the route to a peer MP, i.e.,

      to identify the = nodes along the path to the peer MP. When a

      connection fails, this mechanism also a= llows the MP to detect the

&n= bsp;     location of the failure.

 

TOM: The definition calls this "path discovery" but then ta= lks about tracing routes. A better way of describing this in the paragraph = would be that there I a use of path tracing in order to discover (or re-dis= cover) paths that have been changed, created or destroyed.  

[TM] We rephrased this paragraph, an= d hopefully it is clearer and more accurate now.<= /p>

 

 <= o:p>

   o Performance Mo= nitoring:

     = ; Consists of 3 main functions

 

     =   o Loss Measurement (LM) - monitors the packet loss rate of a

          = connection.

 =

        o Delay Mea= surement (DM) - monitors the delay and delay

          variation between MPs.

 

        o Throughput measurement= - monitors the throughput of a

          connection.

 

TOM: Along with the discussion above around path trace/discove= ry, it is imperative that paths be discovered (one way or another) in order= to successfully d performance monitoring on those paths.

[TM] True. However this section presents a s= hort list of typical OAM functions, and we would rather stick with succinct= descriptions in this section.

 

&= nbsp;

1.2. Forwarding Plane vs. Management Plane<= o:p>

 

   While the OAM tools may, and quite oft= en do, work in conjunction with

   a control-plane or management plane, they are usually defin= ed to be

   indepen= dent of the control-plane.  The OAM tools communicate with the

   management plane to rai= se alarms, and often the on-demand tools may

   be activated by the management, e.g. to locate= and localize problems.

 = ;

   The considerat= ions of the control-plane maintenance tools or the

   functionality of the management-plane ar= e out of scope for this

 = ;  document, which will concentrate on presenting the forwarding-plane=

   tools that are = used for OAM.

&n= bsp;

TOM: What about the data= plane? For example, the GACH OAM type is such an example. VCCV also operat= es within the data plane after its configuration capabilities have been sig= naled.  It should also be mentioned that it is imperative that when re= quired, OAM tools are capable of testing the actual data plane in as much a= ccuracy as possible, but that they all should note how accurate.   Not= all OAM tools are created equal.

= [TM] We rephrased this subsection, and now have a much clearer defin= ition of each plane in “2.2.4. Data Plane, Control Plane and Manageme= nt Plane”. We also added specific text about the importance of fate-s= haring (see section 1.4), which addresses the second part of your comment.<= /span>

 

 

1.3= . The OAM toolsets

 

   This memo provides = an overview of the different sets of OAM

   mechanisms defined by the IETF. It is intended fo= r those with little

  &n= bsp;or no familiarity with the described mechanisms. The set of OAM

   mechanisms described in= this memo are applicable to IP unicast, MPLS,

   pseudowires, and MPLS for the transport envi= ronment (MPLS-TP). While

&nbs= p;  OAM mechanisms that are applicable to other technologies exist, th= ey

 

 

Mizrahi, et al.         Expires July 9, 2013  = ;                [Page 4]

Internet-Draft       Ov= erview of OAM Mechanisms           January 2013

 

 

=    are beyond the scope of this memo. This document focuses on IE= TF

   documents tha= t have been published as RFCs, while other ongoing OAM-

   related work is outside the scope.<= o:p>

 

   The IETF has defined OAM protocols and= mechanisms in several

 =  different fronts:

&nbs= p;

   o IP Ping and= Traceroute:

    &n= bsp; Ping is a very simple and common application for failure diagnosis

 

TOM: I am not sure the term "common&= quot; is necessary.

[TM] Re= moved.

 <= o:p>

=

      that uses ICMP Echo requests= , as defined in [ICMPv4], and

      [ICMPv6].

      Traceroute ([TCPIP-Tools], [NetTools]) is an applic= ation that

    &nbs= p; allows users to trace the path between an IP source and an IP=

      destination, i.e.,= to identify the nodes along the path.

 

   = ;o BFD:

      = Bidirectional Forwarding Detection (BFD) is defined in [BFD] as a

      framework for a l= ightweight generic OAM mechanism.  The intention

<= div>

      is to define a base mechanism= that can be used with various

      encapsulation types, network environments, and in va= rious medium

    &n= bsp; types.

 =

   o MPLS OAM:

=

      MPLS LSP Ping, as defi= ned in [MPLS-OAM], [MPLS-OAM-FW] and [LSP-

      Ping], is an OAM mechanism for point to = point MPLS LSPs. It

  &n= bsp;   includes two main functions: Ping and Traceroute.

 

   o MPLS-TP OAM:

      MPLS-TP OAM is defined in a set of RFCs. = The OAM requirements for

&nbs= p;     MPLS Transport Profile (MPLS-TP) are defined in [MPLS-TP-O= AM].

      Eac= h of the tools in the OAM toolset is defined in its own RFC, as<= /p>

      specified in Sectio= n 1.4.

 

<= /div>

   o PWE3 OAM:

      The PWE3 OAM architecture d= efines control channels that support

      the use of existing IETF OAM tools to be used = for a pseudowire

   = ;   (PW).  The control channels that are defined in [VCCV] and [P= W-G-

      ACH= ] may be used in conjunction with ICMP Ping, LSP Ping, and BFD

      to perform CC and CV= functionality.  In addition the channels

      support use of any of the MPLS-TP ba= sed OAM tools for completing

=       their respective OAM functionality for a PW.

 

   o OWAMP and TWAMP:

      The One Way Active Measurement Proto= col (OWAMP) and the Two Way

&= nbsp;     Active Measurement Protocols (TWAMP) are two protocols = defined in

    &nbs= p; the IP Performance Metrics (IPPM) working group in the IETF. These<= /o:p>

      protocols all= ow delay and packet loss measurement in IP networks.

 

 

Mizrahi, et al. &nbs= p;       Expires July 9, 2013         &n= bsp;        [Page 5]

Internet-Draft       Overview of OAM Mechanisms=           January 2013

<= p class=3DMsoNormal> 

&n= bsp;

   This docume= nt summarizes the OAM mechanisms defined by the IETF. We

   first present a comparison of the = terminology used in various OAM

   standards, and then summarize the OAM functions that each O= AM

   standard prov= ides.

 

1.4. IETF OAM Documents

<= div>

 

   Table 1 summarizes the IETF OAM related RFCs discussed in t= his

   document.

 

   The table includes a "Type" co= lumn, specifying the nature of each of

   the listed documents:

 

 =  o Tool: documents that define an OAM tool or mechanism.

 

   o Prof.: documents that define a profile or a var= iant for an OAM

   =   tool that is defined in other documents.

<= p class=3DMsoNormal> 

&n= bsp;  o Inf.: documents that define an infrastructure that is used by = OAM

      tool= s.

 

   o Misc.: other OAM related document= s, e.g., OAM requirement and

=       framework documents.

 

  &n= bsp;+-----------+--------------------------------------+-----+----------+

   |     &= nbsp;     | Title              = ;                  |Type | RFC=      |

 =  +-----------+--------------------------------------+-----+----------= +

   |IP Ping and| = Internet Control Message Protocol    |Tool | RFC 792  |=

   |Traceroute | [ICMPv= 4]                     &n= bsp;       |     |         &nb= sp;|

   |   &n= bsp;       +--------------------------------------+-----+---= -------+

   |  = ;         | Internet Control Message Protocol   &n= bsp;|Tool | RFC 4443 |

 =  |           | (ICMPv6) for the Internet Pro= tocol   |     |          |

   |       &= nbsp;   | Version 6 (IPv6) Specification       |  =   |          |

   |           | [ICMPv= 6]                     &n= bsp;       |     |         &nb= sp;|

   |   &n= bsp;       +--------------------------------------+-----+---= -------+

   |  = ;         | A Primer On Internet and TCP/IP   &nbs= p;  |Tool | RFC 2151 |

&= nbsp;  |           | Tools and Utilities [TCP= IP-Tools]    |     |          = |

   |    = ;       +--------------------------------------+-----+------= ----+

   |   &= nbsp;       | FYI on a Network Management Tool    = |Tool | RFC 1147 |

  &n= bsp;|           | Catalog: Tools for Monitoring an= d    |     |          |

   |      =     | Debugging TCP/IP Internets and       | &nbs= p;   |          |

   |           | Inte= rconnected Devices [NetTools]    |     |     =      |

  =  |           +-------------------------------= -------+-----+----------+

&nb= sp;  |           | Extended ICMP to Support M= ulti-Part  |Tool | RFC 4884 |

 

 

Mizrahi, et al.       &= nbsp; Expires July 9, 2013              =    [Page 6]

Intern= et-Draft       Overview of OAM Mechanisms     &nbs= p;     January 2013

 

 

=

   |         =   | Messages [ICMP-MP]              = ;     |     |          |<= /o:p>

   |      = ;     +--------------------------------------+-----+----------+

   |     &= nbsp;     | ICMP Extensions for Multiprotocol    |Tool = | RFC 4950 |

   | &= nbsp;         | Label Switching [ICMP-Ext]    = ;       |     |          = |

   |    = ;       +--------------------------------------+-----+------= ----+

   |   &= nbsp;       | Extending ICMP for Interface and    = |Tool | RFC 5837 |

  &n= bsp;|           | Next-Hop Identification [ICMP-In= t]   |     |          |<= /p>

   +-----------+--------------= ------------------------+-----+----------+

   |BFD        | Bidirectional = Forwarding Detection   |Tool | RFC 5880 |

   |           | [BFD]=                     &nbs= p;          |     |      =    |

   = |           +-------------------------------------= -+-----+----------+

  &n= bsp;|           | Bidirectional Forwarding Detecti= on   |Prof.| RFC 5881 |

=    |           | (BFD) for IPv4 and IPv6= (Single Hop) |     |          |

   |       =     | [BFD-IP]               &= nbsp;             |     |   &n= bsp;      |

&n= bsp;  |           +--------------------------= ------------+-----+----------+

   |           | Generic Application o= f Bidirectional |Misc.| RFC 5882 |

   |           | Forwarding Detect= ion [BFD-Gen]       |     |       &= nbsp;  |

   | =           +--------------------------------------+= -----+----------+

  &nbs= p;|           | Bidirectional Forwarding Detection=   |Prof.| RFC 5883 |

&n= bsp;  |           | (BFD) for Multihop Paths = [BFD-Multi] |     |          |

   |       &n= bsp;   +--------------------------------------+-----+----------+<= /o:p>

   |      = ;     | Bidirectional Forwarding Detection   |Prof.| RFC 588= 4 |

   |   &nb= sp;       | for MPLS Label Switched Paths (LSPs) |   &n= bsp; |          |

   |           | [BFD-LSP]=                     &nbs= p;      |     |          = |

   |    = ;       +--------------------------------------+-----+------= ----+

   |   &= nbsp;       | Bidirectional Forwarding Detection   |Pro= f.| RFC 5885 |

   |=           | for the Pseudowire Virtual Circuit &n= bsp; |     |          |

   |         &n= bsp; | Connectivity Verification (VCCV)     |     | &nb= sp;        |

   |           | [BFD-VCCV]   &= nbsp;                    =   |     |          |

   +-----------+----------------= ----------------------+-----+----------+

   |MPLS OAM   | Operations and Management (OAM= )      |Misc.| RFC 4377 |

   |           | Requiremen= ts for Multi-Protocol Label|     |         &n= bsp;|

   |   &= nbsp;       | Switched (MPLS) Networks [MPLS-OAM]  | &n= bsp;   |          |

=

   |           +---= -----------------------------------+-----+----------+

<= div>

   |           = | A Framework for Multi-Protocol       |Misc.| RFC 4378 |

   |     &n= bsp;     | Label Switching (MPLS) Operations    |  = ;   |          |

   |           | and M= anagement (OAM) [MPLS-OAM-FW]   |     |      =    |

   = |           +-------------------------------------= -+-----+----------+

  &n= bsp;|           | Detecting Multi-Protocol Label &= nbsp;     |Tool | RFC 4379 |

   |           | Switched (MPL= S) Data Plane Failures  |     |         =  |

   |  =         | [LSP-Ping]          = ;                 |     |=          |

 

 

Mizrahi, et al.      =   Expires July 9, 2013             &nbs= p;    [Page 7]

Inte= rnet-Draft       Overview of OAM Mechanisms     &n= bsp;     January 2013

 

 

   |        = ;   +--------------------------------------+-----+----------+

   |       &= nbsp;   | Operations and Management (OAM)      |Misc.| = RFC 4687 |

   | &nb= sp;         | Requirements for Point-to-Multipoint | &n= bsp;   |          |

=

   |           | MP= LS Networks [MPLS-P2MP]            |   &= nbsp; |          |

   +-----------+----------------------------------= ----+-----+----------+

 =  |MPLS-TP    | Requirements for OAM in MPLS-TP    = ;  |Misc.| RFC 5860 |

&n= bsp;  |OAM        | [MPLS-TP-OAM]     &n= bsp;                  |  =   |          |

   |           +-------= -------------------------------+-----+----------+

=

   |           | MP= LS Generic Associated Channel      |Inf. | RFC 5586 |

   |      =     | [G-ACh]               &= nbsp;              |     | &nb= sp;        |

   |           +--------------------= ------------------+-----+----------+

   |           | MPLS-TP OAM Fra= mework                |Misc.| RFC 6= 371 |

   |   &= nbsp;       | [TP-OAM-FW]          =                |     | &= nbsp;        |

   |           +------------------= --------------------+-----+----------+

   |           | Proactive Con= nectivity Verification, |Tool | RFC 6428 |

   |           | Continuit= y Check, and Remote Defect  |     |       &nb= sp;  |

   | &n= bsp;         | Indication for the MPLS Transport  =  |     |          |

=

   |         =   | Profile [TP-CC-CV]              = ;     |     |          |<= /o:p>

   |      = ;     +--------------------------------------+-----+----------+

   |     &= nbsp;     | MPLS On-Demand Connectivity       &nbs= p;  |Tool | RFC 6426 |

&= nbsp;  |           | Verification and Route T= racing       |     |         &= nbsp;|

   |   =         | [OnDemand-CV]         &nb= sp;              |     |  = ;        |

   |           +----------------------= ----------------+-----+----------+

   |           | MPLS Fault Manage= ment Operations,    |Tool | RFC 6427 |

<= p class=3DMsoNormal>   |           | Adm= inistration, and Maintenance (OAM)|     |       &n= bsp;  |

   | &= nbsp;         | [TP-Fault]         =                   |   &nb= sp; |          |

   |           +-----------= ---------------------------+-----+----------+

   |           | MPLS T= ransport Profile Lock Instruct |Tool | RFC 6435 |

=

   |           | an= d Loopback Functions [Lock-Loop]   |     |     &nb= sp;    |

  &nb= sp;|           +----------------------------------= ----+-----+----------+

 =  |           | Packet Loss and Delay Measure= ment for|Tool | RFC 6374 |

&n= bsp;  |           | MPLS Networks [MPLS-LM-DM= ]           |     |      =    |

   = |           +-------------------------------------= -+-----+----------+

  &n= bsp;|           | A Packet Loss and Delay Measurem= ent  |Prof.| RFC 6375 |

=    |           | Profile for MPLS-Based = Transport     |     |          = ;|

   |   &nbs= p;       | Networks [TP-LM-DM]         &= nbsp;        |     |       &nb= sp;  |

   +---= --------+--------------------------------------+-----+----------+

   |PWE3 OAM   | Pseudo= wire Virtual Circuit           |Inf. | RFC 5085 |<= o:p>

   |     =       | Connectivity Verification (VCCV):    | &nb= sp;   |          |

<= p class=3DMsoNormal>   |           | A C= ontrol Channel for Pseudowires    |     |    =      |

 =  |           | [VCCV]       &= nbsp;                    =   |     |          |

 

 

Mizrahi, = et al.         Expires July 9, 2013      = ;            [Page 8]

Internet-Draft       Overview of OAM = Mechanisms           January 2013

 

 

   |=           +--------------------------------------= +-----+----------+

  &nb= sp;|           | Bidirectional Forwarding Detectio= n   |Prof.| RFC 5885 |

&= nbsp;  |           | for the Pseudowire Virtu= al Circuit   |     |          |

   |     &nb= sp;     | Connectivity Verification (VCCV)     |  =   |          |

   |           | [BFD-V= CCV]                     =       |     |          |<= o:p>

   |     =       +--------------------------------------+-----+--------= --+

   |   &nb= sp;       | Using the Generic Associated Channel |Inf. | RFC= 6423 |

   |  =         | Label for Pseudowire in the MPLS   &nbs= p; |     |          |

   |         &nbs= p; | Transport Profile (MPLS-TP)          |  =   |          |

   |           | [PW-G-= ACh]                     =       |     |          |<= o:p>

   |     =       +--------------------------------------+-----+--------= --+

   |   &nb= sp;       | Pseudowire (PW) Operations,      =    |Misc.| RFC 6310 |

   |           | Administration, and= Maintenance (OAM)|     |          |

   |     &nb= sp;     | Message Mapping [PW-Map]         &n= bsp;   |     |          |

   +-----------+------------= --------------------------+-----+----------+

   |OWAMP and  | A One-way Active Measuremen= t Protocol|Tool | RFC 4656 |

=    |TWAMP      | [OWAMP]       &nbs= p;                     &n= bsp;|     |          |

   |         &nb= sp; +--------------------------------------+-----+----------+

   |        =   | A Two-Way Active Measurement Protocol|Tool | RFC 5357 |

   |       &n= bsp;   | [TWAMP]               &nbs= p;              |     |  =        |

   |           +-----------------------= ---------------+-----+----------+

   |           | Framework for IP P= erformance Metrics |Misc.| RFC 2330 |

   |           | [IPPM-FW] &nbs= p;                     &n= bsp;    |     |          |

   |     &nb= sp;     +--------------------------------------+-----+----------+=

   |    =       | IPPM Metrics for Measuring       &nb= sp;   |Misc.| RFC 2678 |

   |           | Connectivity [IPPM-Con= ]              |     |   =        |

=    |           +------------------------= --------------+-----+----------+

   |           | A One-way Delay Met= ric for IPPM      |Misc.| RFC 2679 |

   |           | = [IPPM-1DM]                   &= nbsp;       |     |         &n= bsp;|

   |   &= nbsp;       +--------------------------------------+-----+--= --------+

   | &nbs= p;         | A One-way Packet Loss Metric for IPPM|Misc= .| RFC 2680 |

   | =           | [IPPM-1LM]        =                   |   &n= bsp; |          |

   |           +----------= ----------------------------+-----+----------+

   |           | A Rou= nd-trip Delay Metric for IPPM   |Misc.| RFC 2681 |

   |          = ; | [IPPM-2DM]                 &nbs= p;         |     |        = ;  |

   +-----= ------+--------------------------------------+-----+----------+<= /p>

           = ;      Table 1 Summary of IETF OAM Related RFCs

 

 

 

 

 

=  

 

<= /div>

Mizrahi, et al.         = Expires July 9, 2013                = ;  [Page 9]

Internet-Dra= ft       Overview of OAM Mechanisms       &nb= sp;   January 2013

 = ;

 

=

1.5. Non-IETF OAM Documents

<= div>

 

   In addition to the OAM mechanisms defined by the IETF, the = IEEE and

   ITU-T h= ave also defined various OAM mechanisms that focus on

<= div>

   Ethernet, and various other transport= network environments. These

=    various mechanisms, defined by the three standard organization= s, are

   often tig= htly coupled, and have had a mutual effect on each other.

   The ITU-T and IETF have both defi= ned OAM mechanisms for MPLS LSPs,

   [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards= by the IEEE

   and= ITU-T are to some extent linked to IETF OAM mechanisms listed

   above and are mentioned here= only as reference material:

=  

   o OAM mec= hanisms for Ethernet based networks have been defined by

      both the ITU-T in [ITU-T-Y= 1731], and by the IEEE in [IEEE802.1ag].

      The IEEE 802.3 standard defines OAM for o= ne-hop Ethernet links

  =     [IEEE802.3ah].

=  

   o The ITU= -T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and

=

      MPLS-TP OAM in [ITU-G8113.1]= and [ITU-G8113.2].

 

   Table 2 summarizes= the OAM standards mentioned in this document. This

   document focuses on IETF OAM standards,= but these non-IETF standards

   are referenced where relevant.

 

 =  +-----------+--------------------------------------+---------------+=

   |    =       | Title             &nb= sp;                  |Standard= /Draft |

   +------= -----+--------------------------------------+---------------+

   |ITU-T      | = Operation & Maintenance mechanism    | ITU-T Y.1711  |

   |MPLS OAM   = | for MPLS networks [ITU-T-Y1711]      |      = ;         |

   |           +---------------------= -----------------+---------------+

   |           | Assignment of the= 'OAM Alert Label'  | RFC 3429      |

   |         &nb= sp; | for Multiprotocol Label Switching    |      =         |

   |           | Architecture (MPLS) O= peration and    |              = ; |

   |   &nb= sp;       | Maintenance (OAM) Functions      =    |               |

   |       &= nbsp;   | [OAM-Label]              =            |         &nb= sp;     |

  &n= bsp;|           |         &nbs= p;                     &n= bsp;      |              = |

   |   &nbs= p;       |  Note: although this is an IETF    = ;  |               |

=

   |         =   |  document, it is listed as one of the|       &= nbsp;       |

=    |           |  non-IETF OAM stan= dards, since it    |             &n= bsp; |

   |   =         |  was defined as a complementary part | &= nbsp;             |

=

   |           | &n= bsp;of ITU-T Y.1711.                = ;    |               |

   +-----------+----------= ----------------------------+---------------+

   |ITU-T      | Operations, admi= nistration and       |ITU-T G.8113.2 |

<= div>

   |MPLS-TP OAM| Maintenance mechanisms = for MPLS-TP   |               |

 

=

 

M= izrahi, et al.         Expires July 9, 2013   &nbs= p;             [Page 10]

=

Internet-Draft       Overview of O= AM Mechanisms           January 2013

 

 

  &n= bsp;|           | networks using the tools defined= for |               |

   |         &nb= sp; | MPLS [ITU-G8113.2]               &= nbsp;   |               |

   |       &n= bsp;   |                  = ;                    | &n= bsp;             |

<= p class=3DMsoNormal>   |           | &nb= sp;Note: this document describes the   |         &= nbsp;     |

  =  |           |  OAM toolset defined by t= he IETF for |               |=

   |       &nb= sp;   |  MPLS-TP, whereas ITU-T G.8113.1     |   &= nbsp;           |

   |           |  des= cribes the OAM toolset defined   |           =     |

   = |           |  by the ITU-T.     &n= bsp;                 |    = ;           |

   |           +--------------= ------------------------+---------------+

   |           | Operations= , Administration and       |ITU-T G.8113.1 |

<= /div>

   |         &= nbsp; | Maintenance mechanism for MPLS-TP in |         =       |

 =  |           | Packet Transport Network (PTN= )       |               |=

   |    =       +--------------------------------------+-------------= --+

   |   &nb= sp;       | Allocation of a Generic Associated   | RFC = 6671      |

&n= bsp;  |           | Channel Type for ITU-T MP= LS Transport|               |=

   |       &nb= sp;   | Profile Operation, Maintenance, and  |     &nbs= p;         |

   |           | Administration (MPL= S-TP OAM)         |           =     |

   = |           | [ITU-T-CT]       &nbs= p;                   |   =             |

   |           |   &= nbsp;                    =              |       &nb= sp;       |

&n= bsp;  |           |  Note: although this= is an IETF      |            =   |

   | &nbs= p;         |  document, it is listed as one of the= |               |

   |           |=  non-IETF OAM standards, since it    |      =         |

   |           |  was defined as = a complementary part |               |

   |     &= nbsp;     |  of ITU-T G.8113.1.         =          |           &nbs= p;   |

   +---= --------+--------------------------------------+---------------+=

   |ITU-T      = ;| OAM Functions and Mechanisms for     |[ITU-T-Y1731]  |

   |Ethernet   |= Ethernet-based Networks              | =               |

   |OAM        |  =                     &nbs= p;              |       &= nbsp;       |

=    +-----------+--------------------------------------+----------= -----+

   |IEEE &nb= sp;     | Connectivity Fault Management       &nbs= p;| IEEE 802.1ag  |

&nbs= p;  |CFM        | [IEEE802.1ag]     &nbs= p;                  |   &= nbsp;           |

   |           |   &n= bsp;                     =              |       &nbs= p;       |

&nb= sp;  |           |  Note: CFM was origin= ally published  |               |

   |     &= nbsp;     |  as IEEE 802.1ag, but is now      = ;   |               |

   |        =   |  incorporated in the 802.1Q standard.|       =         |

   +-----------+--------------------------------------+---------= ------+

   |IEEE &n= bsp;     | Media Access Control Parameters,     | IEEE = 802.3ah  |

   = |802.3      | Physical Layers, and Management     =  |               |

   |link level | Parameters for Sub= scriber Access     |             &n= bsp; |

   |OAM &nbs= p;      | Networks [IEEE802.3ah]        =       |               |<= o:p>

   |     =       |               &nb= sp;                     &= nbsp;|               |

 

 

Mizrahi, et al.=         Expires July 9, 2013       &nbs= p;         [Page 11]

Internet-Draft       Overview of OAM Mechanisms=           January 2013

<= p class=3DMsoNormal> 

&n= bsp;

   |   &n= bsp;       |  Note: link level OAM was originally | &nb= sp;             |

   |           | &nbs= p;defined in IEEE 802.3ah, and is now |           =     |

   = |           |  incorporated in the 802.3 stan= dard. |               |

   +-----------+-------------------= -------------------+---------------+

         Table 2 Non-IETF OAM Standards Me= ntioned in this Document

&nbs= p;

2. Basic Terminology<= /o:p>

 

2.1. Abbreviations

 

   = ACH    Associated Channel Header

 

  &= nbsp;AIS    Alarm Indication Signal

 

 = ;  BFD    Bidirectional Forwarding Detection

<= /div>

 

   CC     Continuity Check

 

   CV     Connectivity Verification

=

 

   DM     Delay Measurement

 

   FEC    Forwarding Equivalence Class

 

   GAL    Generic Associated Label<= /o:p>

 

   ICMP   Internet Control Message Protoc= ol

 

   LDP    Label Distribution= Protocol

 

   LM     Loss Measur= ement

 

   LSP    Label Switched = Path

 

   ME     Maintenance Enti= ty

 

   MEG    Maintenance Entity= Group

 

<= /div>

   MEP    MEG End Point<= o:p>

 

   MIP    MEG Intermediate Poin= t

 

=

   MP     Maintenance Point

 

   MPLS   Multiprotocol Label Switchi= ng

 

 

 

Mizrahi, et al. &= nbsp;       Expires July 9, 2013        =         [Page 12]

Internet-Draft       Overview of OAM Mechanisms &n= bsp;         January 2013

 

 = ;

   MPLS-TP MPLS T= ransport Profile

 <= /o:p>

   MTU    Maxi= mum Transmission Unit

 <= o:p>

   OAM    = ;Operations, Administration, and Maintenance

 

 =  PW     Pseudowire

 

   PWE= 3   Pseudowire Emulation Edge-to-Edge

 

  &= nbsp;RDI    Remote Defect Indication

 

&nbs= p;  TTL    Time To Live

 

   = ;VCCV   Virtual Circuit Connectivity Verification

=

 

 

TOM: = Why is this section not at the top of this document, as is customary for RF= Cs?  

[TM] The introdu= ction is now significantly shorter than it was when you sent this comment, = which means that the terminology section is now much closer to the beginnin= g of the document.

 

 

2.2. Terminology used in OAM Standards

=

 

2.2.1. General Terms

&nbs= p;

   A wide variet= y of terms is used in various OAM standards. Each of the

   OAM standards listed in the refere= nce section includes a section that

   defines terms relevant to that tool. A thesaurus of ter= minology for

   MPL= S-TP terms is presented in [TP-Term], and provides a good summary

   of some of the OAM relate= d terminology.

 

   This section presents a= comparison of the terms used in various OAM

   standards, without fully quoting the definitio= n of each term. For a

  =  formal definition of each term, refer to the references at the end of=

   this document.<= o:p>

 

2.2.2. OAM Maintenance Entities

 

   OAM tools are designed to monitor and manage a Maintenanc= e Entity

   (ME). &= nbsp;An ME, as defined in [TP-OAM-FW], defines a relationship

   between two points of a trans= port path to which maintenance and

   monitoring operations apply.

 

&nb= sp;  The following related terms are also quoted from [TP-OAM-FW]:

 

=

   o MEP: The two points that define a maint= enance entity.

 

   o MEG: The collection o= f one or more MEs that belongs to the same

      transport path and that are maintained a= nd monitored as a group

 = ;     are known as a Maintenance Entity Group (MEG).

 

 

 

 

Mizrahi, et al.         Expires J= uly 9, 2013                 [Page 1= 3]

Internet-Draft   &nbs= p;   Overview of OAM Mechanisms           Jan= uary 2013

 

 

   o MIP: In between MEPs, there are zero or more in= termediate points,

  &nb= sp;   called Maintenance Entity Group Intermediate Points (MIPs).=

 

<= p class=3DMsoNormal>   A pair of MEPs engaged in an ME are connec= ted by a communication

 =  link, which may be one of several types of connection, e.g. a single=

   physical connec= tion, a set of physical connections, or a virtual link

=

   such as an MPLS LSP.

<= /div>

 

   The term Maintenance Entity (ME) is used in ITU-T Rec= ommendations

   (e.= g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology ([TP-OAM-

   FW]). Various terms are = used to refer to an ME. For example, BFD does

   not explicitly use a term that is equivalent = to ME, but rather uses

 =  the term "session", referring to the relationship between = two nodes

   using = a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) terminology

   simply uses the term "LSP&q= uot; in this context.

 <= o:p>

   MPLS-TP has defi= ned the terms ME and Maintenance Entity Group (MEG)

   in [TP-OAM-FW], similar to the terms de= fined by ITU-T.  A MEG allows

   the monitoring of a compound set of MEs, for example whe= n monitoring

   a p= 2mp MEG that is considered to be the set of MEs between the root=

   and each individual destin= ation MEP.

 <= /p>

2.2.3. OAM Maintenance Points=

 

   A Maintenance Point (MP) is a functional entity = that is defined at a

  &= nbsp;node in the network, and either initiates or reacts to OAM messages.

   A Maintenance End= Point (MEP) is one of the end points of an ME, and

   can initiate OAM messages and respond t= o them. A Maintenance

  =  Intermediate Point (MIP) is an intermediate point between two MEPs,

   that does not gen= erally initiate OAM frames (one exception to this is

   the use of AIS notifications), but is = able to respond to OAM frames

   that are destined to it. A MIP in MPLS-TP identifies OAM pack= ets

   destined to = it by the value of the TTL field in the OAM packet. The

   term Maintenance Point is a general= term for MEPs and MIPs.

&nbs= p;

   The 802.1ag d= efines a finer distinction between Up MPs and Down MPs.

   An MP is a bridge interface, that i= s monitored by an OAM protocol

   either in the direction facing the network, or in the direct= ion

   facing the b= ridge. A Down MP is an MP that receives OAM packets from,

   and transmits them to the directi= on of the network. An Up MP receives

   OAM packets from, and transmits them to the direction = of the bridging

   = entity.

 

=

   MPLS-TP ([TP-OAM-FW]) uses a s= imilar distinction on the placement of

   the MP - either at the ingress, egress, or forwardin= g function of the

  &nbs= p;node (Down / Up MPs).  This placement is important for localization<= o:p>

   of a connection = failure.

 

 

Mizrahi, et al.         Expires July 9, 20= 13                 [Page 14]

Internet-Draft      = Overview of OAM Mechanisms           January 2013=

 

<= div>

 

2.2.4. Proactive and On-demand activation

 

 =  The different OAM tools may be used in one of two basic types of

   activation:

 

   o Proactive activation - indicates that the t= ool is activated on a

  =     continual basis periodically, where messages are sent between= the

      two= MEPs, and errors are detected when a certain number of

      expected messages are not r= eceived.

 

   o On-demand activation - indi= cates that the tool is activated

      "manually" to detect a specific anomaly.=  In this activation a

&= nbsp;     small number of OAM messages are sent by a MEP and the = reply

      me= ssage is received.

 

2.2.5. Connectivity Verification= and Continuity Checks

 =

   Two distinct cl= asses of failure management functions are used in OAM

<= div>

   protocols, connectivity verification = and continuity checks. The

&n= bsp;  distinction between these terms is defined in [MPLS-TP-OAM], and= is

   used similar= ly in this document.

 

   Continuity checks= are used to verify the liveness of a connection or

   a path between two MPs, and are typical= ly sent proactively, though

&= nbsp;  they can be invoked on-demand as well.

 

=    A connectivity verification function allows an MP to check whe= ther it

   is conne= cted to a peer MP or not. This function also allows the MP to

   verify that messages from the= peer MP are received through the

   correct path, thereby verifying not only that the two MPs= are

   connected, = but also that they are connected through the expected

<= div>

   path. This allows detection of unexpe= cted topology changes. A

&nbs= p;  connectivity verification (CV) protocol typically uses a CV messag= e,

   followed by a= CV reply that is sent back to the originator. A CV

   function can be applied proactively or = on-demand.

 <= /p>

   Connectivity verification a= nd continuity checks are considered

   complementary mechanisms, and are often used in conjunc= tion with each

   o= ther.

 

2.2.6. Failures

 

 = ;  The terms Failure, Fault, and Defect are used interchangeably in th= e

   standards, ref= erring to a malfunction that can be detected by a

=

   connectivity or a continuity check. In so= me standards, such as

  =  [IEEE802.1ag], there is no distinction between these terms, while in<= o:p>

 

 

 

Mizrahi, et al. &nbs= p;       Expires July 9, 2013         &n= bsp;       [Page 15]

Internet-Draft       Overview of OAM Mechanisms  = ;         January 2013

 

 

   other standards e= ach of these terms refers to a different type of

<= p class=3DMsoNormal>   malfunction.

 

 = ;  The terminology used in IETF MPLS-TP OAM takes after the ITU-T, whi= ch

   distinguishes= between these terms in [ITU-T-G.806]; The term Fault

<= div>

   refers to an inability to perform a r= equired action, e.g., an

&nbs= p;  unsuccessful attempt to deliver a packet. The term Defect refers t= o

   an interruptio= n in the normal operation, such as a consecutive period

   of time where no packets are delive= red successfully. The term Failure

   refers to the termination of the required function. Whil= e a Defect

   typic= ally refers to a limited period of time, a failure refers to a

   long period of time.

 

3. OAM Tools

 

3.1. IP Ping and Trac= eroute

 

<= /div>

3.1.1. Ping

 

  &= nbsp;Ping is a common network diagnosis application for IP networks that

   uses ICMP. The ICM= P Echo request/reply exchange is a connectivity

   verification function for the Internet Prot= ocol. The originator

  &= nbsp;transmits an ICMP Echo request packet, and the receiver replies with

   an Echo reply. IC= MP ping is defined in two variants, [ICMPv4] is used

   for IPv4, and [ICMPv6] is used for IPv= 6.

 

3.1.2. Traceroute

 

 =  Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows=

   users to discov= er the path between an IP source and an IP

   destination. Traceroute sends a sequence of UDP = packets to UDP port

  &n= bsp;33434 at the destination. By default, Traceroute begins by sending=

   three packets (the n= umber of packets is configurable in most

   Traceroute implementations), each with an IP Time= -To-Live (TTL) value

  &= nbsp;of one to the destination. These packets expire as soon as they reach<= o:p>

   the first router= in the path. That router responds by sending three

   ICMP Time Exceeded Messages to the Trac= eroute application. Traceroute

   now sends another three UDP packets, each with the TTL value= of 2.

   These mes= sages cause the second router to return ICMP messages. This

<= /div>

   process continues, with ever in= creasing values for the TTL field,

   until the packets actually reach the destination. Becaus= e no

   application= listens to port 33434 at the destination, the destination

   returns ICMP Destination Unreach= able Messages indicating an

&= nbsp;  unreachable port. This event indicates to the Traceroute applic= ation

   that it is= finished.  The Traceroute program displays the round-trip<= /p>

   delay associated with each = of the attempts.

 <= /o:p>

 

 

Miz= rahi, et al.         Expires July 9, 2013    =             [Page 16]

Internet-Draft       Overview of OAM= Mechanisms           January 2013

<= /div>

 

 

   = Note that IP routing may be asymmetric. While Traceroute reveals the

   path between a source = and destination, it may not reveal the reverse

   path.

 

   A= few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have been

   defined in the context o= f Traceroute. These extensions augment the

   ICMP Destination Unreachable message, and can be= used by Traceroute

  &n= bsp;applications.

 =

3.2. Bidirectional Forwarding Det= ection (BFD)

 

3.2.1. Overview

 

   While multiple OAM mechanisms have been defined for various = protocols

   in the= protocol stack, Bidirectional Forwarding Detection [BFD],

   defined by the IETF BFD working = group, is a generic OAM mechanism

   that can be deployed over various encapsulating protocols= , and in

   various= medium types. The IETF has defined variants of the protocol

=

   for IP ([BFD-IP], [BFD-Multi])= , for MPLS LSPs [BFD-LSP], and for PWE3

   [BFD-VCCV]. The usage of BFD in MPLS-TP is define= d in [MPLS-TP-CC-

  &nbs= p;CV].

 

<= /div>

   BFD includes two main OAM funct= ions, using two types of BFD packets:

   BFD Control packets, and BFD Echo packets.=

 

3.2.2. BFD Control

 

   BFD s= upports a bidirectional continuity check, using BFD control

<= /div>

   packets, that are exchanged wit= hin a BFD session. BFD sessions

   operate in one of two modes:

 

 =  o Asynchronous mode (i.e. proactive): in this mode BFD control<= /o:p>

      packets are s= ent periodically. When the receiver detects that no

      BFD control packet have been re= ceived during a predetermined

      period of time, a failure is detected.

=

 

   o Demand mode: in this mode, BFD control packets are= sent on-demand.

   = ;   Upon need, a system initiates a series of BFD control packets to

      verify th= e liveness of the session. BFD control packets are sent

      independently in each direc= tion.

 

   Each of the end-points of the mo= nitored path maintains its own

   session identification, called a Discriminator, both of whic= h are

   included i= n the BFD Control Packets that are exchanged between the

   end-points.  At the time of s= ession establishment, the Discriminators

   are exchanged between the two-end points.  I= n addition, the

   = transmission (and reception) rate is negotiated between the two end-

 

 

Mizr= ahi, et al.         Expires July 9, 2013     =             [Page 17]

Internet-Draft       Overview of OAM = Mechanisms           January 2013

 

 

   p= oints, based on information included in the control packets.  These

   transmission rates= may be renegotiated during the session.

 

  &n= bsp;During normal operation of the session, i.e. no failures are=

   detected, the BFD session = is in the Up state.  If no BFD Control

   packets are received during a fixed period of t= ime, called the

=  

TOM: Fixed, pre-config= ured or negotiated period of time (i.e.: BFD interval)

=

[TM] We rephrased this sentence.

 

<= blockquote style=3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0in= 0in 0in 0in;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bo= ttom:5.0pt' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">

   Detection Time, the session is declared to be Down. The d= etection

   time is= a function of the negotiated transmission time, and a

=

   parameter called Detect Mult. Detect= Mult determines the number of

   missing BFD Control packets that cause the session to be dec= lared as

   Down. T= his parameter is included in the BFD Control packet.

 

3.2.3. BFD Echo

 =

   A BFD echo packet is= sent to a peer system, and is looped back to the

=

   originator. The echo function can be used= proactively, or on-demand.

&= nbsp;

   The BFD ec= ho function has been defined in BFD for IPv4 and IPv6

<= div>

   ([BFD-IP]), but is not used in BFD fo= r MPLS LSPs, PWs, or in BFD for

   MPLS-TP.

&nbs= p;

3.3. MPLS OAM

 

   The IETF MPLS working group has defined OAM for M= PLS LSPs. The

   re= quirements and framework of this effort are defined in [MPLS-OAM-

   FW] and [MPLS-OAM], respe= ctively. The corresponding OAM mechanism

   defined, in this context, is LSP Ping [LSP-Ping].=

 

<= div>

   LSP Ping is based on ICMP Ping and ju= st like its predecessor may be

   used in one of two modes:

 

  &n= bsp;o "Ping" mode: In this mode LSP ping is used for end-to-end

      connectiv= ity verification between two LERs.

 

   o &= quot;Traceroute" mode: This mode is used for hop-by-hop fault

      isolation.<= /o:p>

 

   LSP Ping extends the basic ICMP Ping operat= ion (of data-plane

  &nb= sp;connectivity verification) with functionality to verify data-plane<= /o:p>

   vs. control-plane con= sistency for a Forwarding Equivalence Class

   (FEC) and also Maximum Transmission Unit (MTU) = problems. The

   tr= aceroute functionality may be used to isolate and localize the MPLS

   faults, using the Time-= to-live (TTL) indicator to incrementally

   identify the sub-path of the LSP that is successf= ully traversed

   b= efore the faulty link or node.

 

 

 

 

Mizrahi, = et al.         Expires July 9, 2013      = ;           [Page 18]

Internet-Draft       Overview of OAM Mecha= nisms           January 2013

<= div>

 

 

   It sho= uld be noted that LSP Ping supports unique identification of

=

   the LSP within an addressing d= omain. The identification is checked

   using the full FEC identification. LSP Ping is easily = extensible to

   in= clude additional information needed to support new functionality,

   by use of Type-Length-Val= ue (TLV) constructs. The usage of TLVs is

   typically not easy to perform in hardware, and is= thus typically

   = handled by the control plane.

 

   LSP Ping= supports both asynchronous, as well as, on-demand

   activation.

 

3.4.= MPLS-TP OAM

 

3.4.1. Overview

 

   The MPLS working group is currently working on defining the = OAM

   toolset that= fulfills the requirements for MPLS-TP OAM. The full set

   of requirements for MPLS-TP OAM ar= e defined in [MPLS-TP-OAM], and

   include both general requirements for the behavior of the O= AM

   mechanisms an= d a set of operations that should be supported by the

<= div>

   OAM toolset.  The set of mechani= sms required are further elaborated

   in [TP-OAM-FW], which describes the general architectur= e of the OAM

   sys= tem as well as giving overviews of the functionality of the OAM<= /p>

   toolset.

 

   Some of the basic requirements for the OAM toolset for M= PLS-TP are:

 =

   o MPLS-TP OAM must be able= to support both an IP based and non-IP

      based environment. If the network is IP b= ased, i.e. IP routing and

&nb= sp;     forwarding are available, then the MPLS-TP OAM toolset sh= ould rely

     = ; on the IP routing and forwarding capabilities. On the other hand,

      in environments= where IP functionality is not available, the OAM

=

      tools must still be able to opera= te without dependence on IP

&= nbsp;     forwarding and routing.

 

  =  o OAM packets and the user traffic are required to be congruent<= /o:p>

      (i.e. OAM pac= kets are transmitted in-band) and there is a need to

      differentiate OAM packets from= user-plane ones. Inherent in this

      requirement is the principle that MPLS-TP OAM be= independent of

   =   any existing control-plane, although it should not preclude use of<= o:p>

      the cont= rol-plane functionality.

&nbs= p;

3.4.2. Generic Associated = Channel

 

=

   In order to address the requir= ement for in-band transmission of MPLS-

   TP OAM traffic, MPLS-TP uses a Generic Associated= Channel (G-ACh),

  &nbs= p;defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based

 

=

 

M= izrahi, et al.         Expires July 9, 2013   &nbs= p;             [Page 19]

=

Internet-Draft       Overview of O= AM Mechanisms           January 2013

 

 

  &n= bsp;on the same concepts as the PWE3 ACH and VCCV mechanisms.  However= ,

   to address the= needs of LSPs as differentiated from PW, the following

   concepts were defined for [G-ACh]:<= o:p>

 

   o An Associated Channel Header (ACH), = that uses a format similar to

      the PW Control Word, is a 4-byte header that is prepe= nded to OAM

    &nb= sp; packets.

 

   o A Generic Associated La= bel (GAL). The GAL is a reserved MPLS label

      value (13) that indicates that the pack= et is an ACH packet and the

&= nbsp;     payload follows immediately after the label stack.=

 

<= p class=3DMsoNormal>3.4.3. MPLS-TP OAM Toolset

 

&nbs= p;  To address the functionality that is required of the OAM toolset, = the

   MPLS WG cond= ucted an analysis of the existing IETF and ITU-T OAM

   mechanisms and their ability to fulfil= l the required functionality.

   The conclusions of this analysis are documented in [OAM-Analy= s]. The

   MPLS wor= king group currently plans to use a mixture of OAM mechanisms

   that are based on various exi= sting standards, and adapt them to the

   requirements of [MPLS-TP-OAM]. Some of the main buil= ding blocks of

   t= his solution are based on:

&n= bsp;

   o Bidirecti= onal Forwarding Detection ([BFD], [BFD-LSP]) for

<= p class=3DMsoNormal>      proactive continuity check and con= nectivity verification.

 = ;

   o LSP Ping as = defined in [LSP-Ping] for on-demand connectivity

<= p class=3DMsoNormal>      verification.

=

 

   o New protocol packets, using G-ACH, to address different<= o:p>

      function= ality.

 

<= /div>

   o Performance measurement proto= cols that are based on the

&n= bsp;     functionality that is described in [ITU-T-Y1731].

 

   The following sub-sections describe the OAM = tools defined for MPLS-TP

&nb= sp;  as described in [TP-OAM-FW].

 

3.4.3.1. Con= tinuity Check and Connectivity Verification

 

  =  Continuity Check and Connectivity Verification are presented in<= /o:p>

   Section 2.2.5. of thi= s document.  As presented there, these tools may

<= div>

   be used either proactively or on-dema= nd.  When using these tools

   proactively, they are generally used in tandem.=

 

   For MPLS-TP there are two distinct tools, the pr= oactive tool is

   = defined in [TP-CC-CV] while the on-demand tool is defined in

=

 

 

Mizrahi, et = al.         Expires July 9, 2013       &= nbsp;         [Page 20]

Internet-Draft       Overview of OAM Mechanis= ms           January 2013

 

=  

   [OnDemand= -CV].Proactively [MPLS-TP-OAM] states that the function

   should allow the MEPs to monitor th= e liveness and connectivity of a

   transport path. In on-demand mode, this function should su= pport

   monitoring= between the MEPs and, in addition, between a MEP and MIP.

   [TP-OAM-FW] highlights,  wh= en performing Connectivity Verification,

   the need for the CC-V messages to include unique = identification of

  &nbs= p;the MEG that is being monitored and the MEP that originated the

   message.

 

   The proactive tool [TP-CC-CV] is based on extensions t= o BFD (see

   Secti= on 3.2. ) with the additional limitation that the transmission

   and receiving rates are base= d on configuration by the operator.  The

   on-demand tool [OnDemand-CV] is an adaptation= of LSP Ping (see

  &nbs= p;Section 3.3. ) for the required behavior of MPLS-TP.

=

 

3.4.3.2. Route Tracing

&n= bsp;

   [MPLS-TP-OA= M] defines that there is a need for functionality that

=

   would allow a path end-point to iden= tify the intermediate and end-

   points of the path. This function would be used in on-demand= mode.

   Normally,= this path will be used for bidirectional PW, LSP, and

=

   sections, however, unidirectional pa= ths may be supported only if a

   return path exists.  The tool for this is based on the = LSP Ping (see

   Se= ction 3.3. ) functionality and is described in [OnDemand-CV].

 

3.4.3.3. Lock Instruct

 

   Th= e Lock Instruct function [Lock-Loop] is used to notify a transport

   path end-point of an adm= inistrative need to disable the transport

   path.  This functionality will generally be = used in conjunction with

&nbs= p;  some intrusive OAM function, e.g. Performance measurement, Diagnos= tic

   testing, to = minimize the side-effect on user data traffic.

 

3.4.= 3.4. Lock Reporting

 

   Lock Reporting is = a function used by an end-point of a path to report

   to its far-end end-point that a lock co= ndition has been affected on

=    the path.

 =

3.4.3.5. Alarm Reporting

 

=

   Alarm Reporting is a function used by an = intermediate point of a

 = ;  path, that becomes aware of a fault on the path, to report to the

   end-points of the= path. [TP-OAM-FW] states that this may occur as a

   result of a defect condition discovered = at a server sub-layer. This

&= nbsp;  generates an Alarm Indication Signal (AIS) that continues until= the

 

 

 

Mizrahi, et al.=         Expires July 9, 2013       &nbs= p;         [Page 21]

Internet-Draft       Overview of OAM Mechanisms=           January 2013

<= p class=3DMsoNormal> 

&n= bsp;

   fault is cl= eared. The consequent action of this function is detailed

   in [TP-OAM-FW].

 

3.4.3.6. Remote Defect Indication

 

  &n= bsp;Remote Defect Indication (RDI) is used proactively by a path end-<= /o:p>

   point to report to it= s peer end-point that a defect is detected on a

   bidirectional connection between them. [MPL= S-TP-OAM] points out that

&nb= sp;  this function may be applied to a unidirectional LSP only if ther= e a

   return path = exists.  [TP-OAM-FW] points out that this function is

   associated with the proactive CC= -V function.

 

3.4.3.7. Client Failure Indication

 

=

   Client Failure Indication (CFI) is define= d in [MPLS-TP-OAM] to allow

&= nbsp;  the propagation information from one edge of the network to the=

   other. The info= rmation concerns a defect to a client, in the case

   that the client does not support alarm n= otification.

 

3.4.3.8. Packet Loss Measurement (LM)<= o:p>

 

   Packet Loss Measurement is a function = used to verify the quality of

   the service. This function indicates the ratio of packets tha= t are

   not delive= red out of all packets that are transmitted by the path

   source.

 

&nb= sp;  There are two possible ways of determining this measurement:=

 

<= p class=3DMsoNormal>   o Using OAM packets, it is possible to com= pute the statistics based

&nb= sp;     on a series of OAM packets. This, however, has the disadv= antage of

     = ; being artificial, and may not be representative since part of the

      packet loss may= be dependent upon packet sizes.

 

TOM: = Not just packet sizes. Things like implementation (as I mentioned above wit= h the comment about the accuracy or truthfulness of the data plane processi= ng of OAM packets).  Doing very accurate RTT as a simple example, with= just IP Pings, is a tricky thing to make work.  Also, it is important= to mention that the scale in terms of number of packets, number of tests, = etc… can and will impact these parameters too.

[TM] Following your comment we rephrased this sen= tence.

 <= /p>

 

 <= o:p>

   o Sending delimi= ting messages for the start and end of a measurement

      period during which the source= and sink of the path count the

      packets transmitted and received. After the end del= imiter, the

    &nb= sp; ratio would be calculated by the path OAM entity.

<= div>

 

3.4.3.9. Packet Delay Measurement (DM)

 

  &n= bsp;Packet Delay Measurement is a function that is used to measure one-

   way or two-way dela= y of a packet transmission between a pair of the

<= p class=3DMsoNormal>   end-points of a path (PW, LSP, or Section)= . Where:

 

 

 

 

 

 

= Mizrahi, et al.         Expires July 9, 2013   &nb= sp;             [Page 22]

Internet-Draft       Overview of = OAM Mechanisms           January 2013

 

 

  &n= bsp;o One-way packet delay is the time elapsed from the start of=

      transmission of th= e first bit of the packet by a source node until

<= p class=3DMsoNormal>      the reception of the last bit of t= hat packet by the destination

      node.

&= nbsp;

   o Two-way = packet delay is the time elapsed from the start of

      transmission of the first bit of= the packet by a source node until

      the reception of the last bit of the loop-backed= packet by the

    =   same source node, when the loopback is performed at the packet's

      destination= node.

 

<= /div>

   Similarly to the packet loss me= asurement this could be performed in

   either of the two ways outlined above.

<= /div>

 

3.5. PWE3 OAM

 =

3.5.1. PWE3 OAM using Virtua= l Circuit Connectivity Verification (VCCV)

 

  &= nbsp;VCCV, as defined in [VCCV], provides a means for end-to-end fault=

   detection and diagno= stics tools to be extended for PWs (regardless of

=

   the underlying tunneling technology). The= VCCV switching function

&nbs= p;  provides a control channel associated with each PW (based on the P= W

   Associated Cha= nnel Header (ACH) which is defined in [PW-ACH]), and

   allows transmitting the OAM packets in= -band with PW data (using CC

=    Type 1: In-band VCCV).

 

   VC= CV currently supports the following OAM mechanisms: ICMP Ping, LSP

   Ping, and BFD. ICMP and = LSP Ping are IP encapsulated before being

   sent over the PW ACH. BFD for VCCV [BFD-VCCV] sup= ports two modes of

  &nb= sp;encapsulation - either IP/UDP encapsulated (with IP/UDP header) or<= /o:p>

   PW-ACH encapsulated (= with no IP/UDP header) and provides support to

   signal the AC status. The use of the VCCV co= ntrol channel provides

 =  the context, based on the MPLS-PW label, required to bind and

   bootstrap the BFD sess= ion to a particular pseudo wire (FEC),

   eliminating the need to exchange Discriminator value= s.

 

   VCCV consists of two components: (1= ) signaled component to

 = ;  communicate VCCV capabilities as part of VC label, and (2) switchin= g

   component to c= ause the PW payload to be treated as a control packet.

=

 

   VCCV is not directly dependent upon the presence of a cont= rol plane.

   The V= CCV capability negotiation may be performed as part of the PW

   signaling when LDP is used. I= n case of manual configuration of the

   PW, it is the responsibility of the operator to set c= onsistent

   option= s at both ends.

=  

TOM: Might be helpful = to note that the static mode was created specifically to handle the MPLS-TP= cases where no control plane was a requirement. However, new use cases suc= h as pure mobile backhaul, etc… find this functionality useful too.

[TM] Following your comment = we added some text to explain this.

 

 

 

 

 

 

Mizrahi, et al.         Expires July 9, 20= 13                 [Page 23]

Internet-Draft      = Overview of OAM Mechanisms           January 2013=

 

<= div>

 

3.5.2. PWE3 OAM using G-ACh

 

   As ment= ioned above, VCCV enables OAM for PWs by using a control

   channel for OAM packets. When PWs = are used in MPLS-TP networks,

   rather than the control channels defined in VCCV, the G-ACh c= an be

   used as an= alternative control channel. The usage of the G-ACh for

   PWs is defined in [PW-G-ACh].=

 

<= p class=3DMsoNormal>3.6. OWAMP and TWAMP

 

3.6.1. Ov= erview

 

<= /div>

   The IPPM working group in the I= ETF defines common criteria and

   metrics for measuring performance of IP traffic ([IPPM-FW])= . Some of

   the ke= y RFCs published by this working group have defined metrics for<= /p>

   measuring connectivity [IPP= M-Con], delay ([IPPM-1DM], [IPPM-2DM]),

   and packet loss [IPPM-1LM].

<= div>

 

   Alternative protocols for performance measurement are defin= ed, for

   example,= in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet

<= /div>

   OAM [ITU-T-Y1731].

 

   The IPPM working group has defined not only metri= cs for performance

  &nb= sp;measurement, but also protocols that define how the measurement is<= /o:p>

   carried out. The One-= way Active Measurement Protocol [OWAMP] and the

   Two-Way Active Measurement Protocol [TWAMP]= define a method and

  &= nbsp;protocol for measuring delay and packet loss in IP networks.

 

   OWAMP [OWAMP] enables measurement of one-way ch= aracteristics of IP

  &n= bsp;networks, such as one-way packet loss and one-way delay.  For its<= o:p>

   proper operation= OWAMP requires accurate time of day setting at its

   end points.

 

&nb= sp;  TWAMP [TWAMP] is a similar protocol that enables measurement of t= wo-

   way (round t= rip) characteristics.  TWAMP does not require accurate

<= /div>

   time of day, and, furthermore, = allows the use of a simple session

   reflector, making it an attractive alternative to OWAMP.=

 

<= div>

   OWAMP and TWAMP use two separate prot= ocols: a Control plane protocol,

   and a Test plane protocol.

 

3.6.2. = Control and Test Protocols

&n= bsp;

   OWAMP and T= WAMP control protocols run over TCP, while the test

   protocols run over UDP.  The purpo= se of the control protocols is to

   initiate, start, and stop test sessions, and for OWAMP to= fetch

   results. =  The test protocols introduce test packets (which contain

 

 

Mizrahi, = et al.         Expires July 9, 2013      = ;           [Page 24]

Internet-Draft       Overview of OAM Mecha= nisms           January 2013

<= div>

 

 

   sequen= ce numbers and timestamps) along the IP path under test

   according to a schedule, and record= statistics of packet arrival.

   Multiple sessions may be simultaneously defined, each with a= session

   identif= ier, and defining the number of packets to be sent, the amount

   of padding to be added (and = thus the packet size), the start time,

   and the send schedule (which can be either a constan= t time between

   t= est packets or exponentially distributed pseudo-random). Statistics

   recorded conform to the= relevant IPPM RFCs.

 

   OWAMP and TWAMP t= est traffic is designed with security in mind.  Test

   packets are hard to detect becaus= e they are simply UDP streams

   between negotiated port numbers, with potentially nothing sta= tic in

   the packe= ts.  OWAMP and TWAMP also include optional authentication

   and encryption for both cont= rol and test packets.

 <= o:p>

3.6.3. OWAMP

 

   OWAMP defines the following logical roles: Session-Sen= der, Session-

   Re= ceiver, Server, Control-Client, and Fetch-Client.  The Session-

   Sender originates test= traffic that is received by the Session-

   Receiver.  The Server configures and manages= the session, as well as

&nbs= p;  returning the results.  The Control-Client initiates requests= for

   test sessio= ns, triggers their start, and may trigger their

   termination.  The Fetch-Client request= s the results of a completed

=    session.  Multiple roles may be combined in a single host= - for

   example, = one host may play the roles of Control-Client, Fetch-Client,

=

   and Session-Sender, and a seco= nd playing the roles of Server and

   Session-Receiver.

 

   I= n a typical OWAMP session the Control-Client establishes a TCP

   connection to port 861 of th= e Server, which responds with a server

   greeting message indicating supported security/integ= rity modes. The

   = Control-Client responds with the chosen communications mode and the

   Server accepts the mode= s.  The Control-Client then requests and fully

   describes a test session to which the S= erver responds with its

 = ;  acceptance and supporting information.  More than one test ses= sion

   may be requ= ested with additional messages.  The Control-Client then

   starts a test session and the= Server acknowledges.  The Session-

   Sender then sends test packets with pseudorandom = padding to the

   S= ession-Receiver until the session is complete or until the Control-

   client stops the sessio= n.  Once finished, the Fetch-Client sends a

<= p class=3DMsoNormal>   fetch request to the server, which respond= s with an acknowledgement

&nb= sp;  and immediately thereafter the result data.

<= div>

 

 

 

 

 

 

Mizrahi, et al.     &= nbsp;   Expires July 9, 2013            =     [Page 25]

Inte= rnet-Draft       Overview of OAM Mechanisms     &n= bsp;     January 2013

 

 

3.6.4. TWAMP

 

&nbs= p;  TWAMP defines the following logical roles: session-sender, session= -

   reflector, ser= ver, and control-client.  These are similar to the

   OWAMP roles, except that the Sessio= n-Reflector does not collect any

   packet information, and there is no need for a Fetch-Clien= t.

 

   In a typical TWAMP session the Cont= rol-Client establishes a TCP

=    connection to port 862 of the Server, and mode is negotiated a= s in

   OWAMP. &nbs= p;The Control-Client then requests sessions and starts them.

=

   The Session-Sender sends test = packets with pseudorandom padding to

   the Session-Reflector which returns them with insertio= n of

   timestamps.=

 

<= div>

3.7. Summary of OAM Functions

=

 

   Table 3 summarizes the OAM functions that are supported in= each of

   the cat= egories that were analyzed in this section.

 

  =  +-----------+-------+--------+--------+-----------+-------+--------+<= o:p>

   | Standard  = ;|Continu|Connecti|Path    |Defect     |Perform|Other &= nbsp; |

   |  =         |ity    |vity    |Discover= |Indications|ance   |Function|

   |           |Check  |Veri= fica|y       |           |Monitor|s=       |

 = ;  |           |       |tion &= nbsp;  |        |         &nbs= p; |ing    |        |

   +-----------+-------+--------+--------+= -----------+-------+--------+

   |IP Ping    |       |Echo   &nb= sp;|        |           | &nbs= p;     |        |

   + --------- + ----- + ------ + ------ + ---= ------ + ----- + ------ +

&nb= sp;  |IP         |       |   &= nbsp;    |Tracerou|           |   &= nbsp;   |        |

   |Traceroute |       |   &nb= sp;    |te      |         &nbs= p; |       |        |

   + --------- + ----- + ------ + ---= --- + --------- + ----- + ------ +

   |BFD        |BFD    |BFD &= nbsp;   |        |         &nb= sp; |       |        |

   |         &nb= sp; |Control|Echo    |        |    =       |       |        |=

   + --------- + -= ---- + ------ + ------ + --------- + ----- + ------ +

<= div>

   |MPLS OAM   |     &nbs= p; |"Ping"  |"Tracero|         &nbs= p; |       |        |

   |(LSP Ping) |      = |mode    |ute"    |         &= nbsp; |       |        |

<= /div>

   |         &= nbsp; |       |        |mode   &nbs= p;|           |       |   &nbs= p;    |

  &nbs= p;+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +=

   |MPLS-TP   &nbs= p;|CC     |CV/pro- |Route   |-Alarm     |-LM  = ;  |-Diagnos|

  &nb= sp;|OAM        |       |active  |Tr= acing | Reporting |-DM    | tic Tes|

   |           |  = ;     |or on-  |        |-Client   =  |       | t      |

=

   |          = |       |demand  |        | Failur= e   |       |-Lock   |

   |           | &nbs= p;     |        |        = | Indication|       |        |

   |       &n= bsp;   |       |        |   &n= bsp;    |-Remote    |       |   &nb= sp;    |

 

 

=

 

M= izrahi, et al.         Expires July 9, 2013   &nbs= p;             [Page 26]

=

Internet-Draft       Overview of O= AM Mechanisms           January 2013

 

 

  &n= bsp;|           |       |   &n= bsp;    |        | Defect    | &nbs= p;     |        |

   |           | &nbs= p;     |        |        = | Indication|       |        |

   + --------- + ----- + ---= --- + ------ + --------- + ----- + ------ +

   |PWE3 OAM   |BFD    |-BFD  =  |LSP-Ping|           |      = |        |

   |           |      = |-ICMP   |        |         &= nbsp; |       |        |

<= /div>

   |         &= nbsp; |       | Ping   |        | &= nbsp;         |       |     &n= bsp;  |

   | &= nbsp;         |       |-LSP-   | &n= bsp;      |           |   &nbs= p;   |        |

   |           |   &nb= sp;   | Ping   |        |      = ;     |       |        |<= /o:p>

   + --------- + ----- += ------ + ------ + --------- + ----- + ------ +

   |OWAMP and  |       | &= nbsp;      |        |     &nbs= p;     |-Delay |        |

   |TWAMP      |  =     |        |        | =           | measur|        |

   |     &= nbsp;     |       |        | &= nbsp;      |           | ement | &n= bsp;      |

&n= bsp;  |           |       | &n= bsp;      |        |      = ;     |-Packet|        |

=

   |          = |       |        |      =  |           | loss  |     &n= bsp;  |

   | &= nbsp;         |       |     &n= bsp;  |        |          = ; | measur|        |

   |           |   &nb= sp;   |        |        | &nbs= p;         | ement |        |<= /o:p>

   +-----------+-------+= --------+--------+-----------+-------+--------+

                =      Table 3 Summary of OAM Functions

 

4. Security Considerations

=  

   This memo= presents an overview of existing OAM mechanisms, and

<= div>

   proposes no new OAM mechanisms. There= fore, this document introduces

   no security considerations. However, the OAM mechanism revie= wed in

   this docu= ment can and do present security issues. The reader is

=

   encouraged to review the Security Co= nsiderations section of each

=    document reference by this memo.

 

5. IA= NA Considerations

 =

   There are no new IAN= A considerations implied by this document.

 

6. Ackno= wledgments

 <= /p>

   The authors gratefully ackn= owledge Sasha Vainshtein, Carlos

   Pignataro, David Harrington, Dan Romascanu, Ron Bonica and= other

   members o= f the OPSAWG mailing list for their helpful comments.

<= div>

 

   This document was prepared using 2-Word-v2.0.template.dot.<= o:p>

 

 

 

 

 

 

 

Mizrahi, et al.     &= nbsp;   Expires July 9, 2013            =     [Page 27]

Inte= rnet-Draft       Overview of OAM Mechanisms     &n= bsp;     January 2013

 

 

7. References

 

7.1= . Normative References

 =

   [LSP-Ping] &nbs= p;  Kompella, K., Swallow, G., "Detecting Multi-Protocol

          &n= bsp;      Label Switched (MPLS) Data Plane Failures", R= FC 4379,

     =            February 2006.

 

   [MPLS-OAM]    Nadeau, T., Morrow, M., Swallow,= G., Allan, D.,

   =              Matsushima, S., "Oper= ations and Management (OAM)

&= nbsp;                Requirements f= or Multi-Protocol Label Switched (MPLS)

                 = Networks", RFC 4377, February 2006.

 

  &n= bsp;[MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protoc= ol

       = ;          Label Switching (MPLS) Operations and M= anagement

     = ;            (OAM)", RFC 4378, February = 2006.

 

   [OAM-Label]   Ohta, H., &qu= ot;Assignment of the 'OAM Alert Label' for

                 = ;Multiprotocol Label Switching Architecture (MPLS)

              &nbs= p;  Operation and Maintenance (OAM) Functions", RFC 3429,

          &= nbsp;      November 2002.

 

  &n= bsp;[MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements fo= r

       =          OAM in MPLS Transport Networks", RF= C 5860, May 2010.

 =

   [G-ACh]    = ;   Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic

          &nb= sp;      Associated Channel", RFC 5586, June 2009.=

 

<= p class=3DMsoNormal>   [VCCV]        Nadeau, = T., Pignataro, C., "Pseudowire Virtual Circuit

              &nb= sp;  Connectivity Verification (VCCV): A Control Channel

            =      for Pseudowires", RFC 5085, December 2007.

 

   [PW-ACH]      Bryant, S., Swal= low, G., Martini, L., McPherson, D.,

                 "= ;Pseudowire Emulation Edge-to-Edge (PWE3) Control Word

=

              =    for Use over an MPLS PSN", RFC 4385, February 2006.<= /o:p>

 

   [ICMPv4]      Postel, J., &q= uot;Internet Control Message Protocol", STD 5,

              &nb= sp;  RFC 792, September 1981.

 

   [IC= MPv6]      Conta, A., Deering, S., and M. Gupta, "Inter= net Control

    &nb= sp;            Message Protocol (ICMPv6) for = the Internet Protocol

  =                Version 6 (IPv6) Spe= cification", RFC 4443, March 2006.

 

  &n= bsp;[MPLS-P2MP]   Yasukawa, S., Farrel, A., King, D., Nadeau, T.,=

         = ;        "Operations and Management (OAM) Requirem= ents for

     =            Point-to-Multipoint MPLS Networks= ", RFC 4687,

  &nbs= p;              September 2006.

 

 

Mizrah= i, et al.         Expires July 9, 2013     &n= bsp;           [Page 28]

=

Internet-Draft       Overview of OAM Me= chanisms           January 2013

 

 

   [IC= MP-Ext]    Bonica, R., Gan, D., Tappan, D., Pignataro, C., "= ICMP

      &nb= sp;          Extensions for Multiprotocol Label Sw= itching", RFC

  &nb= sp;              4950, August 2007.=

 

<= p class=3DMsoNormal>   [ICMP-MP]     Bonica, R., Gan, D= ., Tappan, D., Pignataro, C.,

                 "Extend= ed ICMP to Support Multi-Part Messages", RFC

=

               = ;  4884, April 2007.

&nb= sp;

   [ICMP-Int] &= nbsp;  Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers,

          &= nbsp;      JR., "Extending ICMP for Interface and Next-= Hop

      &nbs= p;          Identification", RFC 5837, April = 2010.

 

   [TCPIP-Tools] Kessler, G., Shepa= rd, S., "A Primer On Internet and

                 TCP= /IP Tools and Utilities", RFC 2151, June 1997.

 

   [NetTools]    Stine, R., "FYI on a Network Man= agement Tool Catalog:

  =                Tools for Monitoring= and Debugging TCP/IP Internets

                 and Interc= onnected Devices", RFC 1147, April 1990.

 

 = ;  [IPPM-FW]     Paxson, V., Almes, G., Mahdavi, J., and Mat= his, M.,

     =            "Framework for IP Performanc= e Metrics", RFC 2330, May

                 1998.<= /o:p>

 

   [IPPM-Con]    Mahdavi, J., Paxson= , V., "IPPM Metrics for Measuring

                 Con= nectivity", RFC 2678, September 1999.

 

  &= nbsp;[IPPM-1DM]    Almes, G., Kalidindi, S., Zekauskas, M., "= ;A One-way

    &nbs= p;            Delay Metric for IPPM", RF= C 2679, September 1999.

 = ;

   [IPPM-1LM] &nb= sp;  Almes, G., Kalidindi, S., Zekauskas, M., "A One-way

          &n= bsp;      Packet Loss Metric for IPPM", RFC 2680, Septe= mber

      &nb= sp;          1999.

 

  =  [IPPM-2DM]    Almes, G., Kalidindi, S., Zekauskas, M., &quo= t;A Round-trip

    =              Delay Metric for IPPM"= , RFC 2681, September 1999.

&= nbsp;

   [OWAMP] &n= bsp;     Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and

        &n= bsp;        Zekauskas, M., "A One-way Active Measu= rement Protocol

   =              (OWAMP)", RFC 4656, S= eptember 2006.

 

   [TWAMP]     &= nbsp; Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and

<= /div>

            &n= bsp;    Babiarz, J., "A Two-Way Active Measurement Protocol<= o:p>

        &= nbsp;        (TWAMP)", RFC 5357, October 2008.

 

=

   [BFD]         Katz, D= ., Ward, D., "Bidirectional Forwarding Detection

<= div>

              &= nbsp;  (BFD)", RFC 5880, June 2010.

 

 = ;

 

=

Mizrahi, et al.         Expir= es July 9, 2013                 [Pa= ge 29]

Internet-Draft   =     Overview of OAM Mechanisms          = January 2013

 

 

   [BFD-IP]      Katz, D., Ward, D= ., "Bidirectional Forwarding Detection

                &nbs= p;(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June

=

            &= nbsp;    2010.

&nbs= p;

   [BFD-Gen] &nb= sp;   Katz, D., Ward, D., "Generic Application of

<= /div>

            &n= bsp;    Bidirectional Forwarding Detection (BFD)", RFC 5882,=

        =          June 2010.

 

 =  [BFD-Multi]   Katz, D., Ward, D., "Bidirectional Forwardin= g Detection

    &nb= sp;            (BFD) for Multihop Paths"= , RFC 5883, June 2010.

 =

   [BFD-LSP]  = ;   Aggarwal, R., Kompella, K., Nadeau, T., and Swallow,

            =      G., "Bidirectional Forwarding Detection (BFD) for = MPLS

      &nb= sp;          Label Switched Paths (LSPs)", RF= C 5884, June 2010.

 

   [BFD-VCCV]   &= nbsp;Nadeau, T., Pignataro, C., "Bidirectional Forwarding

           =      Detection (BFD) for the Pseudowire Virtual Circuit

        &nbs= p;        Connectivity Verification (VCCV)", RFC 5= 885, June

     = ;            2010.

<= p class=3DMsoNormal> 

&n= bsp;  [TP-OAM-FW]   Busi, I., Allan, D., "Operations, Admini= stration and

    &n= bsp;            Maintenance Framework for MPL= S-based Transport

  &nbs= p;              Networks ", RFC 637= 1, September 2011.

 

   [TP-CC-CV]   &= nbsp;Allan, D., Swallow, G., Drake, J., "Proactive

             =    Connectivity Verification, Continuity Check and Remote

          =        Defect indication for MPLS Transport Profile&quo= t;, RFC

      =            6428, November 2011.

 

   [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S.,= Aggarwal, R. "MPLS

&nbs= p;                On-Demand Connect= ivity Verification and Route

=                  Tracing"= , RFC 6426, November 2011.

&n= bsp;

   [MPLS-LM-DM= ]  Frost, D., Bryant, S., "Packet Loss and Delay

            &nb= sp;    Measurement for MPLS Networks", RFC 6374, September

        &n= bsp;        2011.

 

   = [TP-LM-DM]    Frost, D., Bryant, S., "A Packet Loss and Dela= y

       =          Measurement Profile for MPLS-Based Trans= port

      &nb= sp;          Networks", RFC 6375, September 2= 011.

 

   [TP-Fault]    Swallow, = G., Fulignoli, A., Vigoureux, M., Boutros, S.,

                &= nbsp;"MPLS Fault Management Operations, Administration, and=

          &nbs= p;      Maintenance (OAM)", RFC 6427, November 2011.

 

 

=  

 

<= /div>

 

Mizrahi, et al.         Expires July 9, 2013 &= nbsp;               [Page 30]=

Internet-Draft       Ove= rview of OAM Mechanisms           January 2013

 

=

 

&= nbsp;  [Lock-Loop]   Boutros, S., Sivabalan, S., Aggarwal, R., Vi= goureux,

     =            M., Dai, X., "MPLS Transport= Profile Lock Instruct and

&n= bsp;                Loopback Functi= ons", RFC 6435, November 2011.

 

   [I= TU-T-CT]    Betts, M., "Allocation of a Generic Associated C= hannel

      &= nbsp;          Type for ITU-T MPLS Transport Profi= le Operation,

    &= nbsp;            Maintenance, and Administrat= ion (MPLS-TP OAM)", RFC

=                  6671, Novembe= r 2012.

 

=

   [PW-Map]      M= . Aissaoui, P. Busschbach, L. Martini, M. Morrow, T.

              &n= bsp;  Nadeau, "Pseudowire (PW) Operations, Administration,

          =        and Maintenance (OAM) Message Mapping", RFC= 6310, July

    &nb= sp;            2011.

 

=    [PW-G-ACh]    Li, H., Martini, L., He, J., Huang, F.= , "Using the

  &nbs= p;              Generic Associated Chann= el Label for Pseudowire in the

                 MPLS Transp= ort Profile (MPLS-TP)", RFC 6423, November

                =  2011.

 =

7.2. Informative References<= /p>

 

   [OAM-Def]     Andersson, L., Van Helvoo= rt, H., Bonica, R., Romascanu,

                 D., Mansfie= ld, S., "Guidelines for the use of the OAM

                =  acronym in the IETF ", RFC 6291, June 2011.

=

 

   [OAM-Analys]  Sprecher, N., Fang, L., "An Overvi= ew of the OAM Tool

  &nb= sp;              Set for  MPLS base= d Transport Networks", RFC 6669,

                 July= 2012.

 

<= /div>

   [TP-Term]     Van Hel= voort, H., Andersson, L., Sprecher, N., "A

                =  Thesaurus for the Terminology used in Multiprotocol

            &nbs= p;    Label Switching Transport Profile (MPLS-TP)

<= /div>

            &n= bsp;    drafts/RFCs and ITU-T's Transport Network

<= /div>

            &n= bsp;    Recommendations", work-in-progress, draft-ietf-mpls-=

        =          tp-rosetta-stone, July 2012.

 

   [IEEE802.1ag] IEEE 802.1Q, "IEEE Standard fo= r Local and metropolitan

&nbs= p;                area networks - M= edia Access Control (MAC) Bridges and

                 Virt= ual Bridged Local Area Networks", October 2012.

 

   [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM = Functions and

    &= nbsp;            Mechanisms for Ethernet-base= d Networks", July 2011.

=  

   [ITU-T-Y1= 711] ITU-T Recommendation Y.1711, "Operation & Maintenance

          &= nbsp;      mechanism for MPLS networks", February 2004.=

 

<= div>

 

 

 

Mizrahi, et al.       &nbs= p; Expires July 9, 2013               &n= bsp; [Page 31]

Internet-Draft=       Overview of OAM Mechanisms        = ;   January 2013

 <= o:p>

 

   [IEEE802.3ah] IEEE 802.3, "IEEE S= tandard for Information technology -

                 Local= and metropolitan area networks - Carrier sense

                =  multiple access with collision detection (CSMA/CD)

             = ;    access method and physical layer specifications",<= /o:p>

         =        clause 57, December 2008.

<= div>

 

   [ITU-T-G.806] ITU-T Recommendation G.806, "Characteris= tics of

      =            transport equipment - Description = methodology and

   =              generic functionality"= ;, January 2009.

 <= /o:p>

   [ITU-G8113.2] ITU-T R= ecommendation G.8113.2/Y.1372.2, "Operations,

              &nbs= p;  administration and maintenance mechanisms for MPLS-TP

           =      networks using the tools defined for MPLS", Novem= ber

      &nbs= p;          2012.

 

  &= nbsp;[ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations= ,

       =          Administration and Maintenance mechanism= for MPLS-TP

    &n= bsp;            in Packet Transport Network (= PTN)", November 2012.

&n= bsp;

 

 

Authors' Addresses

&nb= sp;

   Tal Mizrahi<= o:p>

   Marvell

   6 Hamada St.<= /p>

   Yokneam, 20692

   Israel

<= div>

 

 

<= /div>

 

   Nurit Sprecher

   Nokia Siemens Networks

   3 Hanagar St. Neve Ne'eman B

   Hod Hasharon,   45241

   Israel

 

 <= o:p>

 

   Elisa Bellagamba

<= div>

   Ericsson

   6 Farogatan St.

   Stockholm,   164 40

   Sweden

 

&nbs= p;

 

Mizrahi, et al.         Expi= res July 9, 2013                 [P= age 32]

Internet-Draft  =     Overview of OAM Mechanisms          = ; January 2013

 

 

   Phone: +46 761440785

   Email: elisa.bellagamba@ericsson.com

=

 

&= nbsp;

   Yaacov Wei= ngarten

   34 Hagef= en St.

   Karnei Sh= omron,   4485500

  =  Israel

 

   Email: wyaacov@gmail.com

 

 

 

 

=  

 

<= /div>

 

 

 = ;

draft-ietf-opsawg-oam-overview authors,
=
Here is my feedback on this document.

1.
Is this document in = line with http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?
* For exa= mple, the following definitions could be reused.

 &=
nbsp; Fault: The term Fault refers to an inability to perform a required
   action, e.g., an unsuccessful attempt to de=
liver a packet.
 
 &nbs=
p; Defect: The term Defect refers to an interruption in the normal
   operation, such that over a period of time no pac=
kets are delivered
   successfully.
 
   Failure: The term Fai=
lure refers to the termination of the required
 &=
nbsp; function over a longer period of time. Persistence of a defect for a<=
o:p>
   period of time is interpreted as a failur=
e.
 
* For example, on the b=
asic abstract 
Abstract
 
   Operations, Administration, and Maintenance=
 (OAM) is a general term
   that refers to a=
 toolset that can be used for fault detection and
&nbs=
p;  isolation, and for performance measurement. OAM mechanisms have be=
en
   defined for various layers in the prot=
ocol stack, and are used with a
   variety o=
f protocols.
 
Abstract (dra=
ft-ietf-trill-oam-req-04)
 
=
   OAM (Operations, Administration and Maintenance) is a general =
term
   used to identify functions and tools=
ets to troubleshoot and monitor
   networks.=
 This document presents, OAM Requirements applicable to
   TRILL. 
 
So,=
 as an example: does OAM include function? 
I advice t=
o review draft-ietf-trill-oam-req-04
 =

2. 
draft-ietf-trill-oam is not mentioned, =
while the abstract mentions:
   This documen=
t presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.
Search for OAM in the current draft names (https://datatracker.ietf.org/), and you wil=
l find many references.
Ok, I see later on:  =
;     
   This document =
focuses on IETF
   documents that have been =
published as RFCs, while other ongoing OAM-
 &nbs=
p; related work is outside the scope.
Ok, fine then: w=
e don't need a reference to all the drafts. 
However, =
draft-ietf-trill-oam is closed to be a RFC, and should be mentioned.
 
 
3.
Section 1
   The term OA=
M in this document refers to Operations, Administration
   and Maintenance [OAM-Def], focusing on the f= orwarding plane of OAM.
What does it mean "focusi=
ng on the forwarding plane of OAM"?
Do you take a=
 subset of the definition for this document?
Btw, I do=
n't see a definition in the terminology section.
In se=
ction 2.2.3
   A Maintenance Point (MP) is a=
 functional entity that is defined at a
   n=
ode in the network, and either initiates or reacts to OAM messages.
Which plane is MP?
 
4.
Section 1, Introduction
"Hence, management aspects are outside the scope of this document.&qu=
ot;
I don't understand which management aspects we spe=
ak about here.

5.
Clarifying questi= on regarding 1.2
If speak about OWAMP or TWAMP 'synthetic traffic), is t= hat data plane, control plane, or management plane?
Note that I found la= ter on in the draft:

   OWAMP and TWAMP use tw=
o separate protocols: a Control plane protocol,
 =
  and a Test plane protocol.

Inte= restingly enough, after reading the document, I reviewed http://dat= atracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, and saw t= he same feedback from Stewart Bryant:

Provide a clear vi=
ew of OAM functionality and its relationship
to variou=
s “planes” of networking (data plane, control plane,=

management plane). In particular, the importance of
fate-sharing of OAM and user traffic flows in packet networks=

should be explained.
=
6.
I see a multiplication of "plane" terms in =
the IETF document, and in this document in particular.
I could find: forwarding plane, management plane, control plane, data plan=
e, user plane, and test plane.
Way too many.
Please be consistent

7.

   Table 1 summarizes the IETF OAM related RFCs =
discussed in this
   document.
 
   Table 2 summarizes the OAM=
 standards mentioned in this document. 
 
You need to change the Table 2 description. Do you want to sa=
y something along the lines of:
   Table 2 s=
ummarizes the OAM standards specified by other Standard Development Organiz=
ation 
   (SDO) than the IETF, along wi=
th IETF references where applicable.
 =

 
8.
Section 2.2.=
1
   For a formal definition of each term, r=
efer to the references at the end of
   this=
 document.
Without a reference to a specific RFC, this=
 is the type of statement which is not useful: you have 5 pages of referenc=
es.
You position this document as "An Overview of=
 Operations, Administration, and Maintenance (OAM) Mechanisms", but yo=
u tell the reader: "if you want to know about the terms,
just read first all references!"
 
9.
You specify some terms and some=
 OAM categories, 
   2.2.2<=
/a>. OAM Maintenance Entities .......................... 13<=
/o:p>
         14
         2.2.4. Proactive and On-demand activation ................ 15
       &=
nbsp; 2.2.5. Connectivity Verification and Continuity Check=
s ... 15
      =
;   2.2.6. Failures .............................=
............. 15
... but you don't use them =
in the section 3
 
Just o=
ne example with section 3.2.2
-
   o Demand mode: in this mode, BFD control packets are sent o=
n-demand.
      Upon need, a =
system initiates a series of BFD control packets to
&n=
bsp;     verify the liveness of the session<=
/pre>
Instead of liveness, you have defined Connectivity Verification a=
nd Continuity Checks in section 2.2.5
- OLD:
   Each of the end-points of the monitored path maint=
ains its own
   session identification<=
/o:p>
NEW:
   Each of the MEP main=
tains its own session identification
OR NEW (actually =
I don't know)
   Each of the MP maintains it=
s own session identification
- OLD
   A BFD echo packet is sent to a peer system
<=
pre>Peer system =3D MEP, MP, or something else?
- etc.=
.. 
 
10.
<= pre>This document is composed of a list of OAM content and references, but = I'm really missing the document "scope and target audience".= 
When we did RFC 6632, which is the companion document, we =
had http://tools=
.ietf.org/html/rfc6632#section-1.1
 
   The target audience of the document is, on the on=
e hand, IETF working
   groups, which aim to=
 select appropriate standard management protocols
&nbs=
p;  and data models to address their needs concerning network manageme=
nt.
   On the other hand, the document can b=
e used as an overview and
   guideline by no=
n-IETF Standards Development Organizations (SDOs)
&nbs=
p;  planning to use IETF management technologies and data models for t=
he
   realization of management applications=
.  The document can also be
   used to =
initiate a discussion between the bodies with the goal to
<= pre>   gather new requirements and to detect possible gaps. = Finally, this
   document is directed to al=
l interested parties that seek to get an
   =
overview of the current set of the IETF network management protocols
   such as network administrators or newcomers to =
the IETF.
 
You should have =
something similar.
 
 <=
o:p>
11.
Section 3.6.1, put the paragr=
aph 2 at the end of the section. The "alternative" in the followi=
ng sentence would then make sense
   Alterna=
tive protocols for performance measurement are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [=
TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].
 
 
My co=
nclusions: this document still needs some work
 <=
o:p>
Regards, Benoit
 =
The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following docu=
ment:
- 'An Overview of Operations, Administration, an=
d Maintenance (OAM)
   Mechanisms'
  <draft-ietf-opsawg-oam-overview-08.txt> as Informa=
tional RFC
 
The IESG plans =
to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailin=
g lists by 2013-01-25. Exceptionally, comments may be
=
sent to iesg@ietf.org instead. In eith=
er case, please retain the
beginning of the Subject li=
ne to allow automated sorting.
 
= 
Abstract
 
 <=
/o:p>
   Operations, Administration, and Maintenance (O=
AM) is a general term
   that refers to a to=
olset that can be used for fault detection and
 &=
nbsp; isolation, and for performance measurement. OAM mechanisms have been<=
o:p>
   defined for various layers in the protoco=
l stack, and are used with a
   variety of p=
rotocols.
 
   Thi=
s document presents an overview of the OAM mechanisms that have<=
/pre>
   been defined and are currently being defined by the =
IETF.
 
 
 
 
The file ca=
n be obtained via
http://datatracker.ietf.org/doc/dra=
ft-ietf-opsawg-oam-overview/
 
IESG discussion can be tracked via
http=
://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/=

 
 
No=
 IPR declarations have been submitted directly on this I-D.
 
 
 

 

 

 

 

= --_000_74470498B659FA4687F0B0018C19A89C01D43919C2A4ILMB01marve_-- From tnadeau@lucidvision.com Tue Jan 28 07:38:07 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A8D1A042D for ; Tue, 28 Jan 2014 07:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.523 X-Spam-Level: X-Spam-Status: No, score=0.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4xySkSpCh5B for ; Tue, 28 Jan 2014 07:37:54 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 88A1C1A03B6 for ; Tue, 28 Jan 2014 07:37:53 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 6E67A26CDDA5; Tue, 28 Jan 2014 10:37:50 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_FFD6B328-041F-4033-8DCE-C5818D85FA75"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <74470498B659FA4687F0B0018C19A89C01D43919C122@IL-MB01.marvell.com> Date: Tue, 28 Jan 2014 10:37:50 -0500 Message-Id: <35CAD982-D991-4BED-8F19-3CDFDADE1EB7@lucidvision.com> References: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> <50F437BF.8040005@cisco.com> <50F972FC.2030707@cisco.com> <6C3490D7-3727-41BA-8980-683DF84451A2@lucidvision.com> <74470498B659FA4687F0B0018C19A89C01D43919C122@IL-MB01.marvell.com> To: Tal Mizrahi X-Mailer: Apple Mail (2.1827) X-Mailman-Approved-At: Tue, 28 Jan 2014 09:05:45 -0800 Cc: "draft-ietf-opsawg-oam-overview@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 15:38:08 -0000 --Apple-Mail=_FFD6B328-041F-4033-8DCE-C5818D85FA75 Content-Type: multipart/alternative; boundary="Apple-Mail=_DCB4A4FF-5CD7-4373-98F2-EE12D7699596" --Apple-Mail=_DCB4A4FF-5CD7-4373-98F2-EE12D7699596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The changes look ok except for one minor one: One of the changes in 4.4.2 BFD for MPLS states the following: The advantage of BFD is that it can=09 provide faster failure detection, and scales better to a = large number=09 of LSPs That is a popular misconception. When I at a previous gig we = were able to actually figure out how to make them both perform equally well for CV operations, but we just decided to not implement it = that way. I'd suggest removing that sentence altogether. They are two tools with different implementations, some more optimal = than others.=20 =09 > Hi Tom, > =20 > Thanks again for your comments. > A link to the updated draft: > http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13 > =20 > We believe the current draft addresses all the comments below. > We have replied to every single comment below (search for [TM]). > =20 > Please let us know if you believe something is still amiss. > =20 > Thanks, > Tal. > =20 > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 > Sent: Monday, January 20, 2014 5:29 PM > To: Benoit Claise > Cc: draft-ietf-opsawg-oam-overview@tools.ietf.org; opsawg@ietf.org; = IETF Disgust > Subject: Re: Last Call: (An = Overview of Operations, Administration, and Maintenance (OAM) = Mechanisms) to Informational RFC > =20 > =20 > Reviewing the current version of the draft (12), many of = the comments below are still not addressed. > =20 > --Tom > =20 > =20 > =20 > Here is Tom Nadeau's feedback, forwarded with permission: >=20 > Regards, Benoit >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Some general comments: > =20 > I did not find any discussion around use of configuration within OAM = mechanisms. This is clearly something that is happening in groups like = PWE3 and CCAMP. The motivation for this should be explained and = documented to at least guide these efforts. > [TM] The current draft includes a significantly clearer explanation, = up front in the abstract and introduction, that this document focuses = on OAM tools, i.e., on the data plane of OAM. That is why, for example = we do not discuss configuration contexts such as CCAMP. > 2. There is no real discussion around the security aspects of these = tools. Should there be? > =20 > [TM] We received a similar comment from other reviewers, as well as = the SecDir review in the previous IETF last call. After some discussion = between our AD at the time (Ron Bonica) and the Sec AD (Sean Turner), = the current phrasing of the "Security Considerations" section was = agreed. It is mainly an issue of where you draw the line between which = content to include and which content not to include in the draft, and = security is currently out of scope. > =20 > 3. While the document provides a nice taxonomy of various OAM tools, = it does not really discuss the techniques for using them. I do not = expect anything in detail, but it is not obvious that many of these = tools can be orchestrated to form a "toolset" that can be used to do = multi-layer OAM functions for services such as carrier Ethernet over = VPLS over MPLS, for example. > =20 > [TM] Following your comment, we added quite a bit of text to the = introduction to explain this multi-layer orchestration. You can take = full credit for the fact that this doll IETF draft now includes an ASCII = art figure (Figure 1). :) > =20 > =20 > 4. It might be useful to at least mention in the performance metrics = section, a discussion around the accuracy of these tools and how it = depends on scale, implementation and network configurations. > [TM] Following your comment we added a note about this in section = 4.7.1. See the paragraphs beginning with =93It should be noted that = while [OWAMP]=85=94. > =20 > =20 > My detailed comments inline starting with TOM: > =20 > --Tom > =20 > =20 > =20 > =20 > =20 > =20 > Expires: July 2013 Nokia Siemens = Networks > E. = Bellagamba > = Ericsson > Y. = Weingarten > =20 > January 9, = 2013 > =20 > An Overview of > Operations, Administration, and Maintenance (OAM) Mechanisms > draft-ietf-opsawg-oam-overview-08.txt > =20 > =20 > Abstract > =20 > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset that can be used for fault detection and > isolation, and for performance measurement. OAM mechanisms have = been > defined for various layers in the protocol stack, and are used with = a > variety of protocols. > =20 > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF. > =20 > Status of this Memo > =20 > This Internet-Draft is submitted to IETF in full conformance with = the > provisions of BCP 78 and BCP 79. > =20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > =20 > Internet-Drafts are draft documents valid for a maximum of six = months > and may be updated, replaced, or obsoleted by other documents at = any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > =20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > =20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > =20 > This Internet-Draft will expire on July 9, 2013. > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 1] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > Copyright Notice > =20 > Copyright (c) 2013 IETF Trust and the persons identified as the > document authors. All rights reserved. > =20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with = respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > =20 > Table of Contents > =20 > =20 > 1. Introduction ................................................. 3 > 1.1. The Building Blocks of OAM .............................. 3 > 1.2. Forwarding Plane vs. Management Plane ................... 4 > 1.3. The OAM toolsets ........................................ 4 > 1.4. IETF OAM Documents ...................................... 6 > 1.5. Non-IETF OAM Documents ................................. 10 > 2. Basic Terminology ........................................... 12 > 2.1. Abbreviations .......................................... 12 > 2.2. Terminology used in OAM Standards ...................... 13 > 2.2.1. General Terms ..................................... 13 > 2.2.2. OAM Maintenance Entities .......................... 13 > 2.2.3. OAM Maintenance Points ............................ 14 > 2.2.4. Proactive and On-demand activation ................ 15 > 2.2.5. Connectivity Verification and Continuity Checks ... 15 > 2.2.6. Failures .......................................... 15 > 3. OAM Tools ................................................... 16 > 3.1. IP Ping and Traceroute ................................. 16 > 3.1.1. Ping .............................................. 16 > 3.1.2. Traceroute......................................... 16 > 3.2. Bidirectional Forwarding Detection (BFD) ............... 17 > 3.2.1. Overview .......................................... 17 > 3.2.2. BFD Control ....................................... 17 > 3.2.3. BFD Echo .......................................... 18 > 3.3. MPLS OAM ............................................... 18 > 3.4. MPLS-TP OAM ............................................ 19 > 3.4.1. Overview .......................................... 19 > 3.4.2. Generic Associated Channel ........................ 19 > 3.4.3. MPLS-TP OAM Toolset ............................... 20 > 3.4.3.1. Continuity Check and Connectivity Verification 20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 2] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > 3.4.3.2. Route Tracing ................................ 21 > 3.4.3.3. Lock Instruct ................................ 21 > 3.4.3.4. Lock Reporting ............................... 21 > 3.4.3.5. Alarm Reporting .............................. 21 > 3.4.3.6. Remote Defect Indication ..................... 22 > 3.4.3.7. Client Failure Indication .................... 22 > 3.4.3.8. Packet Loss Measurement (LM) ................. 22 > 3.4.3.9. Packet Delay Measurement (DM) ................ 22 > 3.5. PWE3 OAM ............................................... 23 > 3.5.1. PWE3 OAM using Virtual Circuit Connectivity = Verification > (VCCV) ................................................... 23 > 3.5.2. PWE3 OAM using G-ACh .............................. 24 > 3.6. OWAMP and TWAMP......................................... 24 > 3.6.1. Overview .......................................... 24 > 3.6.2. Control and Test Protocols ........................ 24 > 3.6.3. OWAMP ............................................. 25 > 3.6.4. TWAMP ............................................. 26 > 3.7. Summary of OAM Functions ............................... 26 > 4. Security Considerations ..................................... 27 > 5. IANA Considerations ......................................... 27 > 6. Acknowledgments ............................................. 27 > 7. References .................................................. 28 > 7.1. Normative References ................................... 28 > 7.2. Informative References ................................. 31 > =20 > 1. Introduction > =20 > OAM is a general term that refers to a toolset for detecting, > isolating and reporting connection failures and performance > degradation. > =20 > This document summarizes the OAM tools and mechanisms defined in = the > IETF. > =20 > The term OAM in this document refers to Operations, Administration > and Maintenance [OAM-Def], focusing on the forwarding plane of OAM. > Hence, management aspects are outside the scope of this document. > =20 > TOM: This is a curious sentence to me since to me, OAM is management, = or a subset of it. Also, if you look at the referenced documents, = there are many indirect references to MIBs, Netconf, etc=85 making this = sentence further confusing. It might be helpful to explain more clearly = that the authors here intended to not cover those things explicitly = rather than grouping them arbitrarily under the definition of = "management aspects" Further, to clarify, it might be useful to expand = on what "forwarding plane" is here just to be clear. That is, is this = "in band" or "out-of band" or both? Some of the tools referred to here = also are part of the control AND data planes.=20 > [TM] We significantly improved the distinction between the different = planes: data plane, control plane, management plane. We added a = definition of each of the terms, and we now explicitly explain that the = draft focuses on the data plane. We also explain in the current draft = that we adopt the OAM acronym as recommended in RFC 6291: Operations, = Administration and Maintenance (without Management...). Please let us = know if you think something is still missing here. > =20 > =20 > 1.1. The Building Blocks of OAM > =20 > An OAM protocol is run in the context of a Maintenance Domain, > consisting of two or more nodes that run the OAM protocol, referred > to as Maintenance Points (MP). > =20 > This subsection provides a brief summary of the common tools used = by > OAM protocols. An OAM protocol typically supports one or more of = the > tools described below. > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 3] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > o Continuity Checking (CC): > Used for verifying the liveness of a connection between two MPs. > =20 > o Connectivity Verification (CV): > Allows an MP to check whether it is connected to a peer MP, and = to > verify that messages from the peer MP are received through the > expected path. > =20 > o Path Discovery / Fault Localization: > An MP uses this mechanism to trace the route to a peer MP, i.e., > to identify the nodes along the path to the peer MP. When a > connection fails, this mechanism also allows the MP to detect = the > location of the failure. > =20 > TOM: The definition calls this "path discovery" but then talks about = tracing routes. A better way of describing this in the paragraph would = be that there I a use of path tracing in order to discover (or = re-discover) paths that have been changed, created or destroyed. =20 > [TM] We rephrased this paragraph, and hopefully it is clearer and more = accurate now. > =20 > =20 > o Performance Monitoring: > Consists of 3 main functions > =20 > o Loss Measurement (LM) - monitors the packet loss rate of a > connection. > =20 > o Delay Measurement (DM) - monitors the delay and delay > variation between MPs. > =20 > o Throughput measurement - monitors the throughput of a > connection. > =20 > TOM: Along with the discussion above around path trace/discovery, it = is imperative that paths be discovered (one way or another) in order to = successfully d performance monitoring on those paths. > [TM] True. However this section presents a short list of typical OAM = functions, and we would rather stick with succinct descriptions in this = section. > =20 > =20 > 1.2. Forwarding Plane vs. Management Plane > =20 > While the OAM tools may, and quite often do, work in conjunction = with > a control-plane or management plane, they are usually defined to be > independent of the control-plane. The OAM tools communicate with = the > management plane to raise alarms, and often the on-demand tools may > be activated by the management, e.g. to locate and localize = problems. > =20 > The considerations of the control-plane maintenance tools or the > functionality of the management-plane are out of scope for this > document, which will concentrate on presenting the forwarding-plane > tools that are used for OAM. > =20 > TOM: What about the data plane? For example, the GACH OAM type is such = an example. VCCV also operates within the data plane after its = configuration capabilities have been signaled. It should also be = mentioned that it is imperative that when required, OAM tools are = capable of testing the actual data plane in as much accuracy as = possible, but that they all should note how accurate. Not all OAM = tools are created equal. > [TM] We rephrased this subsection, and now have a much clearer = definition of each plane in =932.2.4. Data Plane, Control Plane and = Management Plane=94. We also added specific text about the importance of = fate-sharing (see section 1.4), which addresses the second part of your = comment. > =20 > =20 > 1.3. The OAM toolsets > =20 > This memo provides an overview of the different sets of OAM > mechanisms defined by the IETF. It is intended for those with = little > or no familiarity with the described mechanisms. The set of OAM > mechanisms described in this memo are applicable to IP unicast, = MPLS, > pseudowires, and MPLS for the transport environment (MPLS-TP). = While > OAM mechanisms that are applicable to other technologies exist, = they > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 4] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > are beyond the scope of this memo. This document focuses on IETF > documents that have been published as RFCs, while other ongoing = OAM- > related work is outside the scope. > =20 > The IETF has defined OAM protocols and mechanisms in several > different fronts: > =20 > o IP Ping and Traceroute: > Ping is a very simple and common application for failure = diagnosis > =20 > TOM: I am not sure the term "common" is necessary. > [TM] Removed. > =20 > that uses ICMP Echo requests, as defined in [ICMPv4], and > [ICMPv6]. > Traceroute ([TCPIP-Tools], [NetTools]) is an application that > allows users to trace the path between an IP source and an IP > destination, i.e., to identify the nodes along the path. > =20 > o BFD: > Bidirectional Forwarding Detection (BFD) is defined in [BFD] as = a > framework for a lightweight generic OAM mechanism. The = intention > is to define a base mechanism that can be used with various > encapsulation types, network environments, and in various medium > types. > =20 > o MPLS OAM: > MPLS LSP Ping, as defined in [MPLS-OAM], [MPLS-OAM-FW] and [LSP- > Ping], is an OAM mechanism for point to point MPLS LSPs. It > includes two main functions: Ping and Traceroute. > =20 > o MPLS-TP OAM: > MPLS-TP OAM is defined in a set of RFCs. The OAM requirements = for > MPLS Transport Profile (MPLS-TP) are defined in [MPLS-TP-OAM]. > Each of the tools in the OAM toolset is defined in its own RFC, = as > specified in Section 1.4. > =20 > o PWE3 OAM: > The PWE3 OAM architecture defines control channels that support > the use of existing IETF OAM tools to be used for a pseudowire > (PW). The control channels that are defined in [VCCV] and = [PW-G- > ACH] may be used in conjunction with ICMP Ping, LSP Ping, and = BFD > to perform CC and CV functionality. In addition the channels > support use of any of the MPLS-TP based OAM tools for completing > their respective OAM functionality for a PW. > =20 > o OWAMP and TWAMP: > The One Way Active Measurement Protocol (OWAMP) and the Two Way > Active Measurement Protocols (TWAMP) are two protocols defined = in > the IP Performance Metrics (IPPM) working group in the IETF. = These > protocols allow delay and packet loss measurement in IP = networks. > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 5] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > This document summarizes the OAM mechanisms defined by the IETF. We > first present a comparison of the terminology used in various OAM > standards, and then summarize the OAM functions that each OAM > standard provides. > =20 > 1.4. IETF OAM Documents > =20 > Table 1 summarizes the IETF OAM related RFCs discussed in this > document. > =20 > The table includes a "Type" column, specifying the nature of each = of > the listed documents: > =20 > o Tool: documents that define an OAM tool or mechanism. > =20 > o Prof.: documents that define a profile or a variant for an OAM > tool that is defined in other documents. > =20 > o Inf.: documents that define an infrastructure that is used by OAM > tools. > =20 > o Misc.: other OAM related documents, e.g., OAM requirement and > framework documents. > =20 > = +-----------+--------------------------------------+-----+----------+ > | | Title |Type | RFC = | > = +-----------+--------------------------------------+-----+----------+ > |IP Ping and| Internet Control Message Protocol |Tool | RFC 792 = | > |Traceroute | [ICMPv4] | | = | > | = +--------------------------------------+-----+----------+ > | | Internet Control Message Protocol |Tool | RFC 4443 = | > | | (ICMPv6) for the Internet Protocol | | = | > | | Version 6 (IPv6) Specification | | = | > | | [ICMPv6] | | = | > | = +--------------------------------------+-----+----------+ > | | A Primer On Internet and TCP/IP |Tool | RFC 2151 = | > | | Tools and Utilities [TCPIP-Tools] | | = | > | = +--------------------------------------+-----+----------+ > | | FYI on a Network Management Tool |Tool | RFC 1147 = | > | | Catalog: Tools for Monitoring and | | = | > | | Debugging TCP/IP Internets and | | = | > | | Interconnected Devices [NetTools] | | = | > | = +--------------------------------------+-----+----------+ > | | Extended ICMP to Support Multi-Part |Tool | RFC 4884 = | > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 6] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > | | Messages [ICMP-MP] | | = | > | = +--------------------------------------+-----+----------+ > | | ICMP Extensions for Multiprotocol |Tool | RFC 4950 = | > | | Label Switching [ICMP-Ext] | | = | > | = +--------------------------------------+-----+----------+ > | | Extending ICMP for Interface and |Tool | RFC 5837 = | > | | Next-Hop Identification [ICMP-Int] | | = | > = +-----------+--------------------------------------+-----+----------+ > |BFD | Bidirectional Forwarding Detection |Tool | RFC 5880 = | > | | [BFD] | | = | > | = +--------------------------------------+-----+----------+ > | | Bidirectional Forwarding Detection |Prof.| RFC 5881 = | > | | (BFD) for IPv4 and IPv6 (Single Hop) | | = | > | | [BFD-IP] | | = | > | = +--------------------------------------+-----+----------+ > | | Generic Application of Bidirectional |Misc.| RFC 5882 = | > | | Forwarding Detection [BFD-Gen] | | = | > | = +--------------------------------------+-----+----------+ > | | Bidirectional Forwarding Detection |Prof.| RFC 5883 = | > | | (BFD) for Multihop Paths [BFD-Multi] | | = | > | = +--------------------------------------+-----+----------+ > | | Bidirectional Forwarding Detection |Prof.| RFC 5884 = | > | | for MPLS Label Switched Paths (LSPs) | | = | > | | [BFD-LSP] | | = | > | = +--------------------------------------+-----+----------+ > | | Bidirectional Forwarding Detection |Prof.| RFC 5885 = | > | | for the Pseudowire Virtual Circuit | | = | > | | Connectivity Verification (VCCV) | | = | > | | [BFD-VCCV] | | = | > = +-----------+--------------------------------------+-----+----------+ > |MPLS OAM | Operations and Management (OAM) |Misc.| RFC 4377 = | > | | Requirements for Multi-Protocol Label| | = | > | | Switched (MPLS) Networks [MPLS-OAM] | | = | > | = +--------------------------------------+-----+----------+ > | | A Framework for Multi-Protocol |Misc.| RFC 4378 = | > | | Label Switching (MPLS) Operations | | = | > | | and Management (OAM) [MPLS-OAM-FW] | | = | > | = +--------------------------------------+-----+----------+ > | | Detecting Multi-Protocol Label |Tool | RFC 4379 = | > | | Switched (MPLS) Data Plane Failures | | = | > | | [LSP-Ping] | | = | > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 7] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > | = +--------------------------------------+-----+----------+ > | | Operations and Management (OAM) |Misc.| RFC 4687 = | > | | Requirements for Point-to-Multipoint | | = | > | | MPLS Networks [MPLS-P2MP] | | = | > = +-----------+--------------------------------------+-----+----------+ > |MPLS-TP | Requirements for OAM in MPLS-TP |Misc.| RFC 5860 = | > |OAM | [MPLS-TP-OAM] | | = | > | = +--------------------------------------+-----+----------+ > | | MPLS Generic Associated Channel |Inf. | RFC 5586 = | > | | [G-ACh] | | = | > | = +--------------------------------------+-----+----------+ > | | MPLS-TP OAM Framework |Misc.| RFC 6371 = | > | | [TP-OAM-FW] | | = | > | = +--------------------------------------+-----+----------+ > | | Proactive Connectivity Verification, |Tool | RFC 6428 = | > | | Continuity Check, and Remote Defect | | = | > | | Indication for the MPLS Transport | | = | > | | Profile [TP-CC-CV] | | = | > | = +--------------------------------------+-----+----------+ > | | MPLS On-Demand Connectivity |Tool | RFC 6426 = | > | | Verification and Route Tracing | | = | > | | [OnDemand-CV] | | = | > | = +--------------------------------------+-----+----------+ > | | MPLS Fault Management Operations, |Tool | RFC 6427 = | > | | Administration, and Maintenance (OAM)| | = | > | | [TP-Fault] | | = | > | = +--------------------------------------+-----+----------+ > | | MPLS Transport Profile Lock Instruct |Tool | RFC 6435 = | > | | and Loopback Functions [Lock-Loop] | | = | > | = +--------------------------------------+-----+----------+ > | | Packet Loss and Delay Measurement for|Tool | RFC 6374 = | > | | MPLS Networks [MPLS-LM-DM] | | = | > | = +--------------------------------------+-----+----------+ > | | A Packet Loss and Delay Measurement |Prof.| RFC 6375 = | > | | Profile for MPLS-Based Transport | | = | > | | Networks [TP-LM-DM] | | = | > = +-----------+--------------------------------------+-----+----------+ > |PWE3 OAM | Pseudowire Virtual Circuit |Inf. | RFC 5085 = | > | | Connectivity Verification (VCCV): | | = | > | | A Control Channel for Pseudowires | | = | > | | [VCCV] | | = | > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 8] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > | = +--------------------------------------+-----+----------+ > | | Bidirectional Forwarding Detection |Prof.| RFC 5885 = | > | | for the Pseudowire Virtual Circuit | | = | > | | Connectivity Verification (VCCV) | | = | > | | [BFD-VCCV] | | = | > | = +--------------------------------------+-----+----------+ > | | Using the Generic Associated Channel |Inf. | RFC 6423 = | > | | Label for Pseudowire in the MPLS | | = | > | | Transport Profile (MPLS-TP) | | = | > | | [PW-G-ACh] | | = | > | = +--------------------------------------+-----+----------+ > | | Pseudowire (PW) Operations, |Misc.| RFC 6310 = | > | | Administration, and Maintenance (OAM)| | = | > | | Message Mapping [PW-Map] | | = | > = +-----------+--------------------------------------+-----+----------+ > |OWAMP and | A One-way Active Measurement Protocol|Tool | RFC 4656 = | > |TWAMP | [OWAMP] | | = | > | = +--------------------------------------+-----+----------+ > | | A Two-Way Active Measurement Protocol|Tool | RFC 5357 = | > | | [TWAMP] | | = | > | = +--------------------------------------+-----+----------+ > | | Framework for IP Performance Metrics |Misc.| RFC 2330 = | > | | [IPPM-FW] | | = | > | = +--------------------------------------+-----+----------+ > | | IPPM Metrics for Measuring |Misc.| RFC 2678 = | > | | Connectivity [IPPM-Con] | | = | > | = +--------------------------------------+-----+----------+ > | | A One-way Delay Metric for IPPM |Misc.| RFC 2679 = | > | | [IPPM-1DM] | | = | > | = +--------------------------------------+-----+----------+ > | | A One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 = | > | | [IPPM-1LM] | | = | > | = +--------------------------------------+-----+----------+ > | | A Round-trip Delay Metric for IPPM |Misc.| RFC 2681 = | > | | [IPPM-2DM] | | = | > = +-----------+--------------------------------------+-----+----------+ > Table 1 Summary of IETF OAM Related RFCs > =20 > =20 > =20 > =20 > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 9] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > 1.5. Non-IETF OAM Documents > =20 > In addition to the OAM mechanisms defined by the IETF, the IEEE and > ITU-T have also defined various OAM mechanisms that focus on > Ethernet, and various other transport network environments. These > various mechanisms, defined by the three standard organizations, = are > often tightly coupled, and have had a mutual effect on each other. > The ITU-T and IETF have both defined OAM mechanisms for MPLS LSPs, > [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards by the = IEEE > and ITU-T are to some extent linked to IETF OAM mechanisms listed > above and are mentioned here only as reference material: > =20 > o OAM mechanisms for Ethernet based networks have been defined by > both the ITU-T in [ITU-T-Y1731], and by the IEEE in = [IEEE802.1ag]. > The IEEE 802.3 standard defines OAM for one-hop Ethernet links > [IEEE802.3ah]. > =20 > o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and > MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. > =20 > Table 2 summarizes the OAM standards mentioned in this document. = This > document focuses on IETF OAM standards, but these non-IETF = standards > are referenced where relevant. > =20 > = +-----------+--------------------------------------+---------------+ > | | Title |Standard/Draft = | > = +-----------+--------------------------------------+---------------+ > |ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 = | > |MPLS OAM | for MPLS networks [ITU-T-Y1711] | = | > | = +--------------------------------------+---------------+ > | | Assignment of the 'OAM Alert Label' | RFC 3429 = | > | | for Multiprotocol Label Switching | = | > | | Architecture (MPLS) Operation and | = | > | | Maintenance (OAM) Functions | = | > | | [OAM-Label] | = | > | | | = | > | | Note: although this is an IETF | = | > | | document, it is listed as one of the| = | > | | non-IETF OAM standards, since it | = | > | | was defined as a complementary part | = | > | | of ITU-T Y.1711. | = | > = +-----------+--------------------------------------+---------------+ > |ITU-T | Operations, administration and |ITU-T G.8113.2 = | > |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | = | > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 10] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > | | networks using the tools defined for | = | > | | MPLS [ITU-G8113.2] | = | > | | | = | > | | Note: this document describes the | = | > | | OAM toolset defined by the IETF for | = | > | | MPLS-TP, whereas ITU-T G.8113.1 | = | > | | describes the OAM toolset defined | = | > | | by the ITU-T. | = | > | = +--------------------------------------+---------------+ > | | Operations, Administration and |ITU-T G.8113.1 = | > | | Maintenance mechanism for MPLS-TP in | = | > | | Packet Transport Network (PTN) | = | > | = +--------------------------------------+---------------+ > | | Allocation of a Generic Associated | RFC 6671 = | > | | Channel Type for ITU-T MPLS Transport| = | > | | Profile Operation, Maintenance, and | = | > | | Administration (MPLS-TP OAM) | = | > | | [ITU-T-CT] | = | > | | | = | > | | Note: although this is an IETF | = | > | | document, it is listed as one of the| = | > | | non-IETF OAM standards, since it | = | > | | was defined as a complementary part | = | > | | of ITU-T G.8113.1. | = | > = +-----------+--------------------------------------+---------------+ > |ITU-T | OAM Functions and Mechanisms for |[ITU-T-Y1731] = | > |Ethernet | Ethernet-based Networks | = | > |OAM | | = | > = +-----------+--------------------------------------+---------------+ > |IEEE | Connectivity Fault Management | IEEE 802.1ag = | > |CFM | [IEEE802.1ag] | = | > | | | = | > | | Note: CFM was originally published | = | > | | as IEEE 802.1ag, but is now | = | > | | incorporated in the 802.1Q standard.| = | > = +-----------+--------------------------------------+---------------+ > |IEEE | Media Access Control Parameters, | IEEE 802.3ah = | > |802.3 | Physical Layers, and Management | = | > |link level | Parameters for Subscriber Access | = | > |OAM | Networks [IEEE802.3ah] | = | > | | | = | > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 11] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > | | Note: link level OAM was originally | = | > | | defined in IEEE 802.3ah, and is now | = | > | | incorporated in the 802.3 standard. | = | > = +-----------+--------------------------------------+---------------+ > Table 2 Non-IETF OAM Standards Mentioned in this Document > =20 > 2. Basic Terminology > =20 > 2.1. Abbreviations > =20 > ACH Associated Channel Header > =20 > AIS Alarm Indication Signal > =20 > BFD Bidirectional Forwarding Detection > =20 > CC Continuity Check > =20 > CV Connectivity Verification > =20 > DM Delay Measurement > =20 > FEC Forwarding Equivalence Class > =20 > GAL Generic Associated Label > =20 > ICMP Internet Control Message Protocol > =20 > LDP Label Distribution Protocol > =20 > LM Loss Measurement > =20 > LSP Label Switched Path > =20 > ME Maintenance Entity > =20 > MEG Maintenance Entity Group > =20 > MEP MEG End Point > =20 > MIP MEG Intermediate Point > =20 > MP Maintenance Point > =20 > MPLS Multiprotocol Label Switching > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 12] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > MPLS-TP MPLS Transport Profile > =20 > MTU Maximum Transmission Unit > =20 > OAM Operations, Administration, and Maintenance > =20 > PW Pseudowire > =20 > PWE3 Pseudowire Emulation Edge-to-Edge > =20 > RDI Remote Defect Indication > =20 > TTL Time To Live > =20 > VCCV Virtual Circuit Connectivity Verification > =20 > =20 > TOM: Why is this section not at the top of this document, as is = customary for RFCs? =20 > [TM] The introduction is now significantly shorter than it was when = you sent this comment, which means that the terminology section is now = much closer to the beginning of the document. > =20 > =20 > 2.2. Terminology used in OAM Standards > =20 > 2.2.1. General Terms > =20 > A wide variety of terms is used in various OAM standards. Each of = the > OAM standards listed in the reference section includes a section = that > defines terms relevant to that tool. A thesaurus of terminology for > MPLS-TP terms is presented in [TP-Term], and provides a good = summary > of some of the OAM related terminology. > =20 > This section presents a comparison of the terms used in various OAM > standards, without fully quoting the definition of each term. For a > formal definition of each term, refer to the references at the end = of > this document. > =20 > 2.2.2. OAM Maintenance Entities > =20 > OAM tools are designed to monitor and manage a Maintenance Entity > (ME). An ME, as defined in [TP-OAM-FW], defines a relationship > between two points of a transport path to which maintenance and > monitoring operations apply. > =20 > The following related terms are also quoted from [TP-OAM-FW]: > =20 > o MEP: The two points that define a maintenance entity. > =20 > o MEG: The collection of one or more MEs that belongs to the same > transport path and that are maintained and monitored as a group > are known as a Maintenance Entity Group (MEG). > =20 > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 13] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > o MIP: In between MEPs, there are zero or more intermediate points, > called Maintenance Entity Group Intermediate Points (MIPs). > =20 > A pair of MEPs engaged in an ME are connected by a communication > link, which may be one of several types of connection, e.g. a = single > physical connection, a set of physical connections, or a virtual = link > such as an MPLS LSP. > =20 > The term Maintenance Entity (ME) is used in ITU-T Recommendations > (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology = ([TP-OAM- > FW]). Various terms are used to refer to an ME. For example, BFD = does > not explicitly use a term that is equivalent to ME, but rather uses > the term "session", referring to the relationship between two nodes > using a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) terminology > simply uses the term "LSP" in this context. > =20 > MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG) > in [TP-OAM-FW], similar to the terms defined by ITU-T. A MEG = allows > the monitoring of a compound set of MEs, for example when = monitoring > a p2mp MEG that is considered to be the set of MEs between the root > and each individual destination MEP. > =20 > 2.2.3. OAM Maintenance Points > =20 > A Maintenance Point (MP) is a functional entity that is defined at = a > node in the network, and either initiates or reacts to OAM = messages. > A Maintenance End Point (MEP) is one of the end points of an ME, = and > can initiate OAM messages and respond to them. A Maintenance > Intermediate Point (MIP) is an intermediate point between two MEPs, > that does not generally initiate OAM frames (one exception to this = is > the use of AIS notifications), but is able to respond to OAM frames > that are destined to it. A MIP in MPLS-TP identifies OAM packets > destined to it by the value of the TTL field in the OAM packet. The > term Maintenance Point is a general term for MEPs and MIPs. > =20 > The 802.1ag defines a finer distinction between Up MPs and Down = MPs. > An MP is a bridge interface, that is monitored by an OAM protocol > either in the direction facing the network, or in the direction > facing the bridge. A Down MP is an MP that receives OAM packets = from, > and transmits them to the direction of the network. An Up MP = receives > OAM packets from, and transmits them to the direction of the = bridging > entity. > =20 > MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement = of > the MP - either at the ingress, egress, or forwarding function of = the > node (Down / Up MPs). This placement is important for localization > of a connection failure. > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 14] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > 2.2.4. Proactive and On-demand activation > =20 > The different OAM tools may be used in one of two basic types of > activation: > =20 > o Proactive activation - indicates that the tool is activated on a > continual basis periodically, where messages are sent between = the > two MEPs, and errors are detected when a certain number of > expected messages are not received. > =20 > o On-demand activation - indicates that the tool is activated > "manually" to detect a specific anomaly. In this activation a > small number of OAM messages are sent by a MEP and the reply > message is received. > =20 > 2.2.5. Connectivity Verification and Continuity Checks > =20 > 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 > Continuity checks are used to verify the liveness of a connection = or > a path between two MPs, and are typically sent proactively, though > they can be invoked on-demand as well. > =20 > A connectivity verification function allows an MP to check whether = it > is connected to a peer MP or not. This function also allows the MP = to > verify that messages from the peer MP are received through the > correct path, thereby verifying not only that the two MPs are > connected, but also that they are connected through the expected > path. This allows detection of unexpected topology changes. A > connectivity verification (CV) protocol typically uses a CV = message, > followed by a CV reply that is sent back to the originator. A CV > function can be applied proactively or on-demand. > =20 > Connectivity verification and continuity checks are considered > complementary mechanisms, and are often used in conjunction with = each > other. > =20 > 2.2.6. Failures > =20 > The terms Failure, Fault, and Defect are used interchangeably in = the > standards, referring to a malfunction that can be detected by a > connectivity or a continuity check. In some standards, such as > [IEEE802.1ag], there is no distinction between these terms, while = in > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 15] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > other standards each of these terms refers to a different type of > malfunction. > =20 > The terminology used in IETF MPLS-TP OAM takes after the ITU-T, = which > distinguishes between these terms in [ITU-T-G.806]; The term Fault > refers to an inability to perform a required action, e.g., an > unsuccessful attempt to deliver a packet. The term Defect refers to > an interruption in the normal operation, such as a consecutive = period > of time where no packets are delivered successfully. The term = Failure > refers to the termination of the required function. While a Defect > typically refers to a limited period of time, a failure refers to a > long period of time. > =20 > 3. OAM Tools > =20 > 3.1. IP Ping and Traceroute > =20 > 3.1.1. Ping > =20 > Ping is a common network diagnosis application for IP networks that > uses ICMP. The ICMP Echo request/reply exchange is a connectivity > verification function for the Internet Protocol. The originator > transmits an ICMP Echo request packet, and the receiver replies = with > an Echo reply. ICMP ping is defined in two variants, [ICMPv4] is = used > for IPv4, and [ICMPv6] is used for IPv6. > =20 > 3.1.2. Traceroute > =20 > Traceroute ([TCPIP-Tools], [NetTools]) is an application that = allows > users to discover the path between an IP source and an IP > destination. Traceroute sends a sequence of UDP packets to UDP port > 33434 at the destination. By default, Traceroute begins by sending > three packets (the number of packets is configurable in most > Traceroute implementations), each with an IP Time-To-Live (TTL) = value > of one to the destination. These packets expire as soon as they = reach > the first router in the path. That router responds by sending three > ICMP Time Exceeded Messages to the Traceroute application. = Traceroute > now sends another three UDP packets, each with the TTL value of 2. > These messages cause the second router to return ICMP messages. = This > process continues, with ever increasing values for the TTL field, > until the packets actually reach the destination. Because no > application listens to port 33434 at the destination, the = destination > returns ICMP Destination Unreachable Messages indicating an > unreachable port. This event indicates to the Traceroute = application > that it is finished. The Traceroute program displays the = round-trip > delay associated with each of the attempts. > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 16] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > Note that IP routing may be asymmetric. While Traceroute reveals = the > path between a source and destination, it may not reveal the = reverse > path. > =20 > A few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have been > defined in the context of Traceroute. These extensions augment the > ICMP Destination Unreachable message, and can be used by Traceroute > applications. > =20 > 3.2. Bidirectional Forwarding Detection (BFD) > =20 > 3.2.1. Overview > =20 > While multiple OAM mechanisms have been defined for various = protocols > in the protocol stack, Bidirectional Forwarding Detection [BFD], > defined by the IETF BFD working group, is a generic OAM mechanism > that can be deployed over various encapsulating protocols, and in > various medium types. The IETF has defined variants of the protocol > for IP ([BFD-IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for = PWE3 > [BFD-VCCV]. The usage of BFD in MPLS-TP is defined in [MPLS-TP-CC- > CV]. > =20 > BFD includes two main OAM functions, using two types of BFD = packets: > BFD Control packets, and BFD Echo packets. > =20 > 3.2.2. BFD Control > =20 > BFD supports a bidirectional continuity check, using BFD control > packets, that are exchanged within a BFD session. BFD sessions > operate in one of two modes: > =20 > o Asynchronous mode (i.e. proactive): in this mode BFD control > packets are sent periodically. When the receiver detects that no > BFD control packet have been received during a predetermined > period of time, a failure is detected. > =20 > o Demand mode: in this mode, BFD control packets are sent = on-demand. > Upon need, a system initiates a series of BFD control packets to > verify the liveness of the session. BFD control packets are sent > independently in each direction. > =20 > Each of the end-points of the monitored path maintains its own > session identification, called a Discriminator, both of which are > included in the BFD Control Packets that are exchanged between the > end-points. At the time of session establishment, the = Discriminators > are exchanged between the two-end points. In addition, the > transmission (and reception) rate is negotiated between the two = end- > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 17] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > points, based on information included in the control packets. = These > transmission rates may be renegotiated during the session. > =20 > During normal operation of the session, i.e. no failures are > detected, the BFD session is in the Up state. If no BFD Control > packets are received during a fixed period of time, called the > =20 > TOM: Fixed, pre-configured or negotiated period of time (i.e.: BFD = interval) > [TM] We rephrased this sentence. > =20 > Detection Time, the session is declared to be Down. The detection > time is a function of the negotiated transmission time, and a > parameter called Detect Mult. Detect Mult determines the number of > missing BFD Control packets that cause the session to be declared = as > Down. This parameter is included in the BFD Control packet. > =20 > 3.2.3. BFD Echo > =20 > A BFD echo packet is sent to a peer system, and is looped back to = the > originator. The echo function can be used proactively, or = on-demand. > =20 > The BFD echo function has been defined in BFD for IPv4 and IPv6 > ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD = for > MPLS-TP. > =20 > 3.3. MPLS OAM > =20 > The IETF MPLS working group has defined OAM for MPLS LSPs. The > requirements and framework of this effort are defined in [MPLS-OAM- > FW] and [MPLS-OAM], respectively. The corresponding OAM mechanism > defined, in this context, is LSP Ping [LSP-Ping]. > =20 > LSP Ping is based on ICMP Ping and just like its predecessor may be > used in one of two modes: > =20 > o "Ping" mode: In this mode LSP ping is used for end-to-end > connectivity verification between two LERs. > =20 > o "Traceroute" mode: This mode is used for hop-by-hop fault > isolation. > =20 > LSP Ping extends the basic ICMP Ping operation (of data-plane > connectivity verification) with functionality to verify data-plane > vs. control-plane consistency for a Forwarding Equivalence Class > (FEC) and also Maximum Transmission Unit (MTU) problems. The > traceroute functionality may be used to isolate and localize the = MPLS > faults, using the Time-to-live (TTL) indicator to incrementally > identify the sub-path of the LSP that is successfully traversed > before the faulty link or node. > =20 > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 18] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > It should be noted that LSP Ping supports unique identification of > the LSP within an addressing domain. The identification is checked > using the full FEC identification. LSP Ping is easily extensible to > include additional information needed to support new functionality, > by use of Type-Length-Value (TLV) constructs. The usage of TLVs is > typically not easy to perform in hardware, and is thus typically > handled by the control plane. > =20 > LSP Ping supports both asynchronous, as well as, on-demand > activation. > =20 > 3.4. MPLS-TP OAM > =20 > 3.4.1. Overview > =20 > The MPLS working group is currently working on defining the OAM > toolset that fulfills the requirements for MPLS-TP OAM. The full = set > of requirements for MPLS-TP OAM are defined in [MPLS-TP-OAM], and > include both general requirements for the behavior of the OAM > mechanisms and a set of operations that should be supported by the > OAM toolset. The set of mechanisms required are further elaborated > in [TP-OAM-FW], which describes the general architecture of the OAM > system as well as giving overviews of the functionality of the OAM > toolset. > =20 > Some of the basic requirements for the OAM toolset for MPLS-TP are: > =20 > o MPLS-TP OAM must be able to support both an IP based and non-IP > based environment. If the network is IP based, i.e. IP routing = and > forwarding are available, then the MPLS-TP OAM toolset should = rely > on the IP routing and forwarding capabilities. On the other = hand, > in environments where IP functionality is not available, the OAM > tools must still be able to operate without dependence on IP > forwarding and routing. > =20 > o OAM packets and the user traffic are required to be congruent > (i.e. OAM packets are transmitted in-band) and there is a need = to > differentiate OAM packets from user-plane ones. Inherent in this > requirement is the principle that MPLS-TP OAM be independent of > any existing control-plane, although it should not preclude use = of > the control-plane functionality. > =20 > 3.4.2. Generic Associated Channel > =20 > In order to address the requirement for in-band transmission of = MPLS- > TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), > defined in [G-ACh] for LSP-based OAM traffic. This mechanism is = based > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 19] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > on the same concepts as the PWE3 ACH and VCCV mechanisms. However, > to address the needs of LSPs as differentiated from PW, the = following > concepts were defined for [G-ACh]: > =20 > o An Associated Channel Header (ACH), that uses a format similar to > the PW Control Word, is a 4-byte header that is prepended to OAM > packets. > =20 > o A Generic Associated Label (GAL). The GAL is a reserved MPLS = label > value (13) that indicates that the packet is an ACH packet and = the > payload follows immediately after the label stack. > =20 > 3.4.3. MPLS-TP OAM Toolset > =20 > To address the functionality that is required of the OAM toolset, = the > MPLS WG conducted an analysis of the existing IETF and ITU-T OAM > mechanisms and their ability to fulfill the required functionality. > The conclusions of this analysis are documented in [OAM-Analys]. = The > MPLS working group currently plans to use a mixture of OAM = mechanisms > that are based on various existing standards, and adapt them to the > requirements of [MPLS-TP-OAM]. Some of the main building blocks of > this solution are based on: > =20 > o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for > proactive continuity check and connectivity verification. > =20 > o LSP Ping as defined in [LSP-Ping] for on-demand connectivity > verification. > =20 > o New protocol packets, using G-ACH, to address different > functionality. > =20 > o Performance measurement protocols that are based on the > functionality that is described in [ITU-T-Y1731]. > =20 > The following sub-sections describe the OAM tools defined for = MPLS-TP > as described in [TP-OAM-FW]. > =20 > 3.4.3.1. Continuity Check and Connectivity Verification > =20 > Continuity Check and Connectivity Verification are presented in > Section 2.2.5. of this document. As presented there, these tools = may > be used either proactively or on-demand. When using these tools > proactively, they are generally used in tandem. > =20 > For MPLS-TP there are two distinct tools, the proactive tool is > defined in [TP-CC-CV] while the on-demand tool is defined in > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 20] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > [OnDemand-CV].Proactively [MPLS-TP-OAM] states that the function > should allow the MEPs to monitor the liveness and connectivity of a > transport path. In on-demand mode, this function should support > monitoring between the MEPs and, in addition, between a MEP and = MIP. > [TP-OAM-FW] highlights, when performing Connectivity Verification, > the need for the CC-V messages to include unique identification of > the MEG that is being monitored and the MEP that originated the > message. > =20 > The proactive tool [TP-CC-CV] is based on extensions to BFD (see > Section 3.2. ) with the additional limitation that the transmission > and receiving rates are based on configuration by the operator. = The > on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see > Section 3.3. ) for the required behavior of MPLS-TP. > =20 > 3.4.3.2. Route Tracing > =20 > [MPLS-TP-OAM] defines that there is a need for functionality that > would allow a path end-point to identify the intermediate and end- > points of the path. This function would be used in on-demand mode. > Normally, this path will be used for bidirectional PW, LSP, and > sections, however, unidirectional paths may be supported only if a > return path exists. The tool for this is based on the LSP Ping = (see > Section 3.3. ) functionality and is described in [OnDemand-CV]. > =20 > 3.4.3.3. Lock Instruct > =20 > The Lock Instruct function [Lock-Loop] is used to notify a = transport > path end-point of an administrative need to disable the transport > path. This functionality will generally be used in conjunction = with > some intrusive OAM function, e.g. Performance measurement, = Diagnostic > testing, to minimize the side-effect on user data traffic. > =20 > 3.4.3.4. Lock Reporting > =20 > Lock Reporting is a function used by an end-point of a path to = report > to its far-end end-point that a lock condition has been affected on > the path. > =20 > 3.4.3.5. Alarm Reporting > =20 > Alarm Reporting is a function used by an intermediate point of a > path, that becomes aware of a fault on the path, to report to the > end-points of the path. [TP-OAM-FW] states that this may occur as a > result of a defect condition discovered at a server sub-layer. This > generates an Alarm Indication Signal (AIS) that continues until the > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 21] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > fault is cleared. The consequent action of this function is = detailed > in [TP-OAM-FW]. > =20 > 3.4.3.6. Remote Defect Indication > =20 > Remote Defect Indication (RDI) is used proactively by a path end- > point to report to its peer end-point that a defect is detected on = a > bidirectional connection between them. [MPLS-TP-OAM] points out = that > this function may be applied to a unidirectional LSP only if there = a > return path exists. [TP-OAM-FW] points out that this function is > associated with the proactive CC-V function. > =20 > 3.4.3.7. Client Failure Indication > =20 > Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to = allow > the propagation information from one edge of the network to the > other. The information concerns a defect to a client, in the case > that the client does not support alarm notification. > =20 > 3.4.3.8. Packet Loss Measurement (LM) > =20 > Packet Loss Measurement is a function used to verify the quality of > the service. This function indicates the ratio of packets that are > not delivered out of all packets that are transmitted by the path > source. > =20 > There are two possible ways of determining this measurement: > =20 > o Using OAM packets, it is possible to compute the statistics based > on a series of OAM packets. This, however, has the disadvantage = of > being artificial, and may not be representative since part of = the > packet loss may be dependent upon packet sizes. > =20 > TOM: Not just packet sizes. Things like implementation (as I mentioned = above with the comment about the accuracy or truthfulness of the data = plane processing of OAM packets). Doing very accurate RTT as a simple = example, with just IP Pings, is a tricky thing to make work. Also, it = is important to mention that the scale in terms of number of packets, = number of tests, etc=85 can and will impact these parameters too. > [TM] Following your comment we rephrased this sentence. > =20 > =20 > =20 > o Sending delimiting messages for the start and end of a = measurement > period during which the source and sink of the path count the > packets transmitted and received. After the end delimiter, the > ratio would be calculated by the path OAM entity. > =20 > 3.4.3.9. Packet Delay Measurement (DM) > =20 > Packet Delay Measurement is a function that is used to measure one- > way or two-way delay of a packet transmission between a pair of the > end-points of a path (PW, LSP, or Section). Where: > =20 > =20 > =20 > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 22] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > o One-way packet delay is the time elapsed from the start of > transmission of the first bit of the packet by a source node = until > the reception of the last bit of that packet by the destination > node. > =20 > o Two-way packet delay is the time elapsed from the start of > transmission of the first bit of the packet by a source node = until > the reception of the last bit of the loop-backed packet by the > same source node, when the loopback is performed at the packet's > destination node. > =20 > Similarly to the packet loss measurement this could be performed in > either of the two ways outlined above. > =20 > 3.5. PWE3 OAM > =20 > 3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV) > =20 > VCCV, as defined in [VCCV], provides a means for end-to-end fault > detection and diagnostics tools to be extended for PWs (regardless = of > the underlying tunneling technology). The VCCV switching function > provides a control channel associated with each PW (based on the PW > Associated Channel Header (ACH) which is defined in [PW-ACH]), and > allows transmitting the OAM packets in-band with PW data (using CC > Type 1: In-band VCCV). > =20 > VCCV currently supports the following OAM mechanisms: ICMP Ping, = LSP > Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being > sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of > encapsulation - either IP/UDP encapsulated (with IP/UDP header) or > PW-ACH encapsulated (with no IP/UDP header) and provides support to > signal the AC status. The use of the VCCV control channel provides > the context, based on the MPLS-PW label, required to bind and > bootstrap the BFD session to a particular pseudo wire (FEC), > eliminating the need to exchange Discriminator values. > =20 > VCCV consists of two components: (1) signaled component to > communicate VCCV capabilities as part of VC label, and (2) = switching > component to cause the PW payload to be treated as a control = packet. > =20 > VCCV is not directly dependent upon the presence of a control = plane. > The VCCV capability negotiation may be performed as part of the PW > signaling when LDP is used. In case of manual configuration of the > PW, it is the responsibility of the operator to set consistent > options at both ends. > =20 > TOM: Might be helpful to note that the static mode was created = specifically to handle the MPLS-TP cases where no control plane was a = requirement. However, new use cases such as pure mobile backhaul, etc=85 = find this functionality useful too. > [TM] Following your comment we added some text to explain this. > =20 > =20 > =20 > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 23] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > 3.5.2. PWE3 OAM using G-ACh > =20 > As mentioned above, VCCV enables OAM for PWs by using a control > channel for OAM packets. When PWs are used in MPLS-TP networks, > rather than the control channels defined in VCCV, the G-ACh can be > used as an alternative control channel. The usage of the G-ACh for > PWs is defined in [PW-G-ACh]. > =20 > 3.6. OWAMP and TWAMP > =20 > 3.6.1. Overview > =20 > The IPPM working group in the IETF defines common criteria and > metrics for measuring performance of IP traffic ([IPPM-FW]). Some = of > the key RFCs published by this working group have defined metrics = for > measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), > and packet loss [IPPM-1LM]. > =20 > Alternative protocols for performance measurement are defined, for > example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet > OAM [ITU-T-Y1731]. > =20 > The IPPM working group has defined not only metrics for performance > measurement, but also protocols that define how the measurement is > carried out. The One-way Active Measurement Protocol [OWAMP] and = the > Two-Way Active Measurement Protocol [TWAMP] define a method and > protocol for measuring delay and packet loss in IP networks. > =20 > OWAMP [OWAMP] enables measurement of one-way characteristics of IP > networks, such as one-way packet loss and one-way delay. For its > proper operation OWAMP requires accurate time of day setting at its > end points. > =20 > TWAMP [TWAMP] is a similar protocol that enables measurement of = two- > way (round trip) characteristics. TWAMP does not require accurate > time of day, and, furthermore, allows the use of a simple session > reflector, making it an attractive alternative to OWAMP. > =20 > OWAMP and TWAMP use two separate protocols: a Control plane = protocol, > and a Test plane protocol. > =20 > 3.6.2. Control and Test Protocols > =20 > OWAMP and TWAMP control protocols run over TCP, while the test > protocols run over UDP. The purpose of the control protocols is to > initiate, start, and stop test sessions, and for OWAMP to fetch > results. The test protocols introduce test packets (which contain > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 24] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > sequence numbers and timestamps) along the IP path under test > according to a schedule, and record statistics of packet arrival. > Multiple sessions may be simultaneously defined, each with a = session > identifier, and defining the number of packets to be sent, the = amount > of padding to be added (and thus the packet size), the start time, > and the send schedule (which can be either a constant time between > test packets or exponentially distributed pseudo-random). = Statistics > recorded conform to the relevant IPPM RFCs. > =20 > OWAMP and TWAMP test traffic is designed with security in mind. = Test > packets are hard to detect because they are simply UDP streams > between negotiated port numbers, with potentially nothing static in > the packets. OWAMP and TWAMP also include optional authentication > and encryption for both control and test packets. > =20 > 3.6.3. OWAMP > =20 > OWAMP defines the following logical roles: Session-Sender, Session- > Receiver, Server, Control-Client, and Fetch-Client. The Session- > Sender originates test traffic that is received by the Session- > Receiver. The Server configures and manages the session, as well = as > returning the results. The Control-Client initiates requests for > test sessions, triggers their start, and may trigger their > termination. The Fetch-Client requests the results of a completed > session. Multiple roles may be combined in a single host - for > example, one host may play the roles of Control-Client, = Fetch-Client, > and Session-Sender, and a second playing the roles of Server and > Session-Receiver. > =20 > In a typical OWAMP session the Control-Client establishes a TCP > connection to port 861 of the Server, which responds with a server > greeting message indicating supported security/integrity modes. The > Control-Client responds with the chosen communications mode and the > Server accepts the modes. The Control-Client then requests and = fully > describes a test session to which the Server responds with its > acceptance and supporting information. More than one test session > may be requested with additional messages. The Control-Client then > starts a test session and the Server acknowledges. The Session- > Sender then sends test packets with pseudorandom padding to the > Session-Receiver until the session is complete or until the = Control- > client stops the session. Once finished, the Fetch-Client sends a > fetch request to the server, which responds with an acknowledgement > and immediately thereafter the result data. > =20 > =20 > =20 > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 25] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > 3.6.4. TWAMP > =20 > TWAMP defines the following logical roles: session-sender, session- > reflector, server, and control-client. These are similar to the > OWAMP roles, except that the Session-Reflector does not collect any > packet information, and there is no need for a Fetch-Client. > =20 > In a typical TWAMP session the Control-Client establishes a TCP > connection to port 862 of the Server, and mode is negotiated as in > OWAMP. The Control-Client then requests sessions and starts them. > The Session-Sender sends test packets with pseudorandom padding to > the Session-Reflector which returns them with insertion of > timestamps. > =20 > 3.7. Summary of OAM Functions > =20 > Table 3 summarizes the OAM functions that are supported in each of > the categories that were analyzed in this section. > =20 > = +-----------+-------+--------+--------+-----------+-------+--------+ > | Standard |Continu|Connecti|Path |Defect |Perform|Other = | > | |ity |vity |Discover|Indications|ance = |Function| > | |Check |Verifica|y | |Monitor|s = | > | | |tion | | |ing | = | > = +-----------+-------+--------+--------+-----------+-------+--------+ > |IP Ping | |Echo | | | | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |IP | | |Tracerou| | | = | > |Traceroute | | |te | | | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |BFD |BFD |BFD | | | | = | > | |Control|Echo | | | | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |MPLS OAM | |"Ping" |"Tracero| | | = | > |(LSP Ping) | |mode |ute" | | | = | > | | | |mode | | | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |MPLS-TP |CC |CV/pro- |Route |-Alarm |-LM = |-Diagnos| > |OAM | |active |Tracing | Reporting |-DM | tic = Tes| > | | |or on- | |-Client | | t = | > | | |demand | | Failure | |-Lock = | > | | | | | Indication| | = | > | | | | |-Remote | | = | > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 26] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > | | | | | Defect | | = | > | | | | | Indication| | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |PWE3 OAM |BFD |-BFD |LSP-Ping| | | = | > | | |-ICMP | | | | = | > | | | Ping | | | | = | > | | |-LSP- | | | | = | > | | | Ping | | | | = | > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |OWAMP and | | | | |-Delay | = | > |TWAMP | | | | | measur| = | > | | | | | | ement | = | > | | | | | |-Packet| = | > | | | | | | loss | = | > | | | | | | measur| = | > | | | | | | ement | = | > = +-----------+-------+--------+--------+-----------+-------+--------+ > Table 3 Summary of OAM Functions > =20 > 4. Security Considerations > =20 > This memo presents an overview of existing OAM mechanisms, and > proposes no new OAM mechanisms. Therefore, this document introduces > no security considerations. However, the OAM mechanism reviewed in > this document can and do present security issues. The reader is > encouraged to review the Security Considerations section of each > document reference by this memo. > =20 > 5. IANA Considerations > =20 > There are no new IANA considerations implied by this document. > =20 > 6. Acknowledgments > =20 > The authors gratefully acknowledge Sasha Vainshtein, Carlos > Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other > members of the OPSAWG mailing list for their helpful comments. > =20 > This document was prepared using 2-Word-v2.0.template.dot. > =20 > =20 > =20 > =20 > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 27] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > 7. References > =20 > 7.1. Normative References > =20 > [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol > Label Switched (MPLS) Data Plane Failures", RFC 4379, > February 2006. > =20 > [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., > Matsushima, S., "Operations and Management (OAM) > Requirements for Multi-Protocol Label Switched (MPLS) > Networks", RFC 4377, February 2006. > =20 > [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for = Multi-Protocol > Label Switching (MPLS) Operations and Management > (OAM)", RFC 4378, February 2006. > =20 > [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for > Multiprotocol Label Switching Architecture (MPLS) > Operation and Maintenance (OAM) Functions", RFC 3429, > November 2002. > =20 > [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for > OAM in MPLS Transport Networks", RFC 5860, May 2010. > =20 > [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic > Associated Channel", RFC 5586, June 2009. > =20 > [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual = Circuit > Connectivity Verification (VCCV): A Control Channel > for Pseudowires", RFC 5085, December 2007. > =20 > [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., > "Pseudowire Emulation Edge-to-Edge (PWE3) Control = Word > for Use over an MPLS PSN", RFC 4385, February 2006. > =20 > [ICMPv4] Postel, J., "Internet Control Message Protocol", STD = 5, > RFC 792, September 1981. > =20 > [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet = Control > Message Protocol (ICMPv6) for the Internet Protocol > Version 6 (IPv6) Specification", RFC 4443, March = 2006. > =20 > [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T., > "Operations and Management (OAM) Requirements for > Point-to-Multipoint MPLS Networks", RFC 4687, > September 2006. > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 28] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP > Extensions for Multiprotocol Label Switching", RFC > 4950, August 2007. > =20 > [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro, C., > "Extended ICMP to Support Multi-Part Messages", RFC > 4884, April 2007. > =20 > [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., = Rivers, > JR., "Extending ICMP for Interface and Next-Hop > Identification", RFC 5837, April 2010. > =20 > [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and > TCP/IP Tools and Utilities", RFC 2151, June 1997. > =20 > [NetTools] Stine, R., "FYI on a Network Management Tool Catalog: > Tools for Monitoring and Debugging TCP/IP Internets > and Interconnected Devices", RFC 1147, April 1990. > =20 > [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., > "Framework for IP Performance Metrics", RFC 2330, May > 1998. > =20 > [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring > Connectivity", RFC 2678, September 1999. > =20 > [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way > Delay Metric for IPPM", RFC 2679, September 1999. > =20 > [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way > Packet Loss Metric for IPPM", RFC 2680, September > 1999. > =20 > [IPPM-2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A = Round-trip > Delay Metric for IPPM", RFC 2681, September 1999. > =20 > [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., = and > Zekauskas, M., "A One-way Active Measurement Protocol > (OWAMP)", RFC 4656, September 2006. > =20 > [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and > Babiarz, J., "A Two-Way Active Measurement Protocol > (TWAMP)", RFC 5357, October 2008. > =20 > [BFD] Katz, D., Ward, D., "Bidirectional Forwarding = Detection > (BFD)", RFC 5880, June 2010. > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 29] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding = Detection > (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June > 2010. > =20 > [BFD-Gen] Katz, D., Ward, D., "Generic Application of > Bidirectional Forwarding Detection (BFD)", RFC 5882, > June 2010. > =20 > [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding = Detection > (BFD) for Multihop Paths", RFC 5883, June 2010. > =20 > [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, > G., "Bidirectional Forwarding Detection (BFD) for = MPLS > Label Switched Paths (LSPs)", RFC 5884, June 2010. > =20 > [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding > Detection (BFD) for the Pseudowire Virtual Circuit > Connectivity Verification (VCCV)", RFC 5885, June > 2010. > =20 > [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration and > Maintenance Framework for MPLS-based Transport > Networks ", RFC 6371, September 2011. > =20 > [TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive > Connectivity Verification, Continuity Check and = Remote > Defect indication for MPLS Transport Profile", RFC > 6428, November 2011. > =20 > [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. = "MPLS > On-Demand Connectivity Verification and Route > Tracing", RFC 6426, November 2011. > =20 > [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay > Measurement for MPLS Networks", RFC 6374, September > 2011. > =20 > [TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay > Measurement Profile for MPLS-Based Transport > Networks", RFC 6375, September 2011. > =20 > [TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, = S., > "MPLS Fault Management Operations, Administration, = and > Maintenance (OAM)", RFC 6427, November 2011. > =20 > =20 > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 30] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, > M., Dai, X., "MPLS Transport Profile Lock Instruct = and > Loopback Functions", RFC 6435, November 2011. > =20 > [ITU-T-CT] Betts, M., "Allocation of a Generic Associated = Channel > Type for ITU-T MPLS Transport Profile Operation, > Maintenance, and Administration (MPLS-TP OAM)", RFC > 6671, November 2012. > =20 > [PW-Map] M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. > Nadeau, "Pseudowire (PW) Operations, Administration, > and Maintenance (OAM) Message Mapping", RFC 6310, = July > 2011. > =20 > [PW-G-ACh] Li, H., Martini, L., He, J., Huang, F., "Using the > Generic Associated Channel Label for Pseudowire in = the > MPLS Transport Profile (MPLS-TP)", RFC 6423, November > 2011. > =20 > 7.2. Informative References > =20 > [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., = Romascanu, > D., Mansfield, S., "Guidelines for the use of the OAM > acronym in the IETF ", RFC 6291, June 2011. > =20 > [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool > Set for MPLS based Transport Networks", RFC 6669, > July 2012. > =20 > [TP-Term] Van Helvoort, H., Andersson, L., Sprecher, N., "A > Thesaurus for the Terminology used in Multiprotocol > Label Switching Transport Profile (MPLS-TP) > drafts/RFCs and ITU-T's Transport Network > Recommendations", work-in-progress, draft-ietf-mpls- > tp-rosetta-stone, July 2012. > =20 > [IEEE802.1ag] IEEE 802.1Q, "IEEE Standard for Local and = metropolitan > area networks - Media Access Control (MAC) Bridges = and > Virtual Bridged Local Area Networks", October 2012. > =20 > [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions = and > Mechanisms for Ethernet-based Networks", July 2011. > =20 > [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance > mechanism for MPLS networks", February 2004. > =20 > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 31] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology = - > Local and metropolitan area networks - Carrier sense > multiple access with collision detection (CSMA/CD) > access method and physical layer specifications", > clause 57, December 2008. > =20 > [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of > transport equipment - Description methodology and > generic functionality", January 2009. > =20 > [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, > administration and maintenance mechanisms for MPLS-TP > networks using the tools defined for MPLS", November > 2012. > =20 > [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, > Administration and Maintenance mechanism for MPLS-TP > in Packet Transport Network (PTN)", November 2012. > =20 > =20 > =20 > Authors' Addresses > =20 > Tal Mizrahi > Marvell > 6 Hamada St. > Yokneam, 20692 > Israel > =20 > Email: talmi@marvell.com > =20 > =20 > Nurit Sprecher > Nokia Siemens Networks > 3 Hanagar St. Neve Ne'eman B > Hod Hasharon, 45241 > Israel > =20 > Email: nurit.sprecher@nsn.com > =20 > =20 > Elisa Bellagamba > Ericsson > 6 Farogatan St. > Stockholm, 164 40 > Sweden > =20 > =20 > =20 > Mizrahi, et al. Expires July 9, 2013 [Page 32] > Internet-Draft Overview of OAM Mechanisms January 2013 > =20 > =20 > Phone: +46 761440785 > Email: elisa.bellagamba@ericsson.com > =20 > =20 > Yaacov Weingarten > 34 Hagefen St. > Karnei Shomron, 4485500 > Israel > =20 > Email: wyaacov@gmail.com > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > draft-ietf-opsawg-oam-overview authors, >=20 > Here is my feedback on this document. >=20 > 1. > Is this document in line with = http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?=20 > * For example, the following definitions could be reused. > Fault: The term Fault refers to an inability to perform a required > action, e.g., an unsuccessful attempt to deliver a packet. > =20 > Defect: The term Defect refers to an interruption in the normal > operation, such that over a period of time no packets are delivered > successfully. > =20 > Failure: The term Failure refers to the termination of the required > function over a longer period of time. Persistence of a defect for = a > period of time is interpreted as a failure. > =20 > * For example, on the basic abstract=20 > Abstract > =20 > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset that can be used for fault detection and > isolation, and for performance measurement. OAM mechanisms have = been > defined for various layers in the protocol stack, and are used with = a > variety of protocols. > =20 > Abstract (draft-ietf-trill-oam-req-04) > =20 > OAM (Operations, Administration and Maintenance) is a general term > used to identify functions and toolsets to troubleshoot and monitor > networks. This document presents, OAM Requirements applicable to > TRILL.=20 > =20 > So, as an example: does OAM include function?=20 > I advice to review draft-ietf-trill-oam-req-04 > =20 > 2.=20 > draft-ietf-trill-oam is not mentioned, while the abstract mentions: > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF. > Search for OAM in the current draft names = (https://datatracker.ietf.org/), and you will find many references. > Ok, I see later on: =20 > This document focuses on IETF > documents that have been published as RFCs, while other ongoing = OAM- > related work is outside the scope. > Ok, fine then: we don't need a reference to all the drafts.=20 > However, draft-ietf-trill-oam is closed to be a RFC, and should be = mentioned. > =20 > =20 > 3. > Section 1 > The term OAM in this document refers to Operations, Administration > and Maintenance [OAM-Def], focusing on the forwarding plane of OAM. > What does it mean "focusing on the forwarding plane of OAM"? > Do you take a subset of the definition for this document? > Btw, I don't see a definition in the terminology section. > In section 2.2.3 > A Maintenance Point (MP) is a functional entity that is defined at = a > node in the network, and either initiates or reacts to OAM = messages. > Which plane is MP? > =20 > 4. > Section 1, Introduction > "Hence, management aspects are outside the scope of this document." > I don't understand which management aspects we speak about here. > 5. > Clarifying question regarding 1.2 > If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, = control plane, or management plane? > Note that I found later on in the draft: > OWAMP and TWAMP use two separate protocols: a Control plane = protocol, > and a Test plane protocol. > Interestingly enough, after reading the document, I reviewed = http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, = and saw the same feedback from Stewart Bryant: > Provide a clear view of OAM functionality and its relationship > to various =93planes=94 of networking (data plane, control plane, > management plane). In particular, the importance of > fate-sharing of OAM and user traffic flows in packet networks > should be explained. > 6. > I see a multiplication of "plane" terms in the IETF document, and in = this document in particular. > I could find: forwarding plane, management plane, control plane, data = plane, user plane, and test plane. > Way too many. > Please be consistent > 7. > Table 1 summarizes the IETF OAM related RFCs discussed in this > document. > =20 > Table 2 summarizes the OAM standards mentioned in this document.=20 > =20 > You need to change the Table 2 description. Do you want to say = something along the lines of: > Table 2 summarizes the OAM standards specified by other Standard = Development Organization=20 > (SDO) than the IETF, along with IETF references where applicable. > =20 > =20 > 8. > Section 2.2.1 > For a formal definition of each term, refer to the references at = the end of > this document. > Without a reference to a specific RFC, this is the type of statement = which is not useful: you have 5 pages of references. > You position this document as "An Overview of Operations, = Administration, and Maintenance (OAM) Mechanisms", but you tell the = reader: "if you want to know about the terms, > just read first all references!" > =20 > 9. > You specify some terms and some OAM categories,=20 > 2.2.2. OAM Maintenance Entities .......................... 13 > 2.2.3. OAM Maintenance Points ............................ 14 > 2.2.4. Proactive and On-demand activation ................ 15 > 2.2.5. Connectivity Verification and Continuity Checks ... 15 > 2.2.6. Failures .......................................... 15 > ... but you don't use them in the section 3 > =20 > Just one example with section 3.2.2 > - > o Demand mode: in this mode, BFD control packets are sent = on-demand. > Upon need, a system initiates a series of BFD control packets to > verify the liveness of the session > Instead of liveness, you have defined Connectivity Verification and = Continuity Checks in section 2.2.5 > - OLD: > Each of the end-points of the monitored path maintains its own > session identification > NEW: > Each of the MEP maintains its own session identification > OR NEW (actually I don't know) > Each of the MP maintains its own session identification > - OLD > A BFD echo packet is sent to a peer system > Peer system =3D MEP, MP, or something else? > - etc...=20 > =20 > 10.=20 > This document is composed of a list of OAM content and references, but = I'm really missing the document "scope and target audience". > When we did RFC 6632, which is the companion document, we had = http://tools.ietf.org/html/rfc6632#section-1.1 > =20 > The target audience of the document is, on the one hand, IETF = working > groups, which aim to select appropriate standard management = protocols > and data models to address their needs concerning network = management. > On the other hand, the document can be used as an overview and > guideline by non-IETF Standards Development Organizations (SDOs) > planning to use IETF management technologies and data models for = the > realization of management applications. The document can also be > used to initiate a discussion between the bodies with the goal to > gather new requirements and to detect possible gaps. Finally, this > document is directed to all interested parties that seek to get an > overview of the current set of the IETF network management = protocols > such as network administrators or newcomers to the IETF. > =20 > You should have something similar. > =20 > =20 > 11. > Section 3.6.1, put the paragraph 2 at the end of the section. The = "alternative" in the following sentence would then make sense > Alternative protocols for performance measurement are defined, for > example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet > OAM [ITU-T-Y1731]. > =20 > =20 > My conclusions: this document still needs some work > =20 > Regards, Benoit > =20 > The IESG has received a request from the Operations and Management = Area > Working Group WG (opsawg) to consider the following document: > - 'An Overview of Operations, Administration, and Maintenance (OAM) > Mechanisms' > as Informational RFC > =20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > =20 > Abstract > =20 > =20 > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset that can be used for fault detection and > isolation, and for performance measurement. OAM mechanisms have = been > defined for various layers in the protocol stack, and are used with = a > variety of protocols. > =20 > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF. > =20 > =20 > =20 > =20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ > =20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ > =20 > =20 > No IPR declarations have been submitted directly on this I-D. > =20 > =20 > =20 > =20 > =20 > =20 --Apple-Mail=_DCB4A4FF-5CD7-4373-98F2-EE12D7699596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
The changes look ok except for = one minor one:

One of = the changes in 4.4.2 BFD for MPLS states the = following:

The = advantage of BFD is that it can
provide faster = failure detection, and scales better to a large number
of = LSPs


<= div>
That is a popular misconception. = When I at a previous gig we were able to actually figure out how to make = them both perform
equally well for CV operations, but we just = decided to not implement it that way. I'd suggest removing that sentence = altogether.
They are two tools with different implementations, = some more optimal than others. 

=

Hi Tom,

 

Thanks again for your = comments.

A link to the updated = draft:

http= ://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13

 

We believe the current draft addresses all the = comments below.

We have replied to every single comment below = (search for [TM]).

 

Please let us know if you believe something is = still amiss.

 

Thanks,

Tal.

 

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com= ]
Sent: Monday, January 20, 2014 5:29 PM
To: Benoit = Claise
Cc: draft-ietf-o= psawg-oam-overview@tools.ietf.org; opsawg@ietf.org; IETF = Disgust
Subject: Re: Last Call: = <draft-ietf-opsawg-oam-overview-08.txt> (An Overview of = Operations, Administration, and Maintenance (OAM) Mechanisms) to = Informational RFC

 

 

        &= nbsp;   Reviewing the current version of the draft = (12), many of the comments below are still not = addressed.

 

        &= nbsp;   --Tom

 

 

 

Here is Tom Nadeau's feedback, forwarded = with permission:

Regards, = Benoit

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Some general = comments:

 

  1. I did not find any discussion around use of configuration = within OAM mechanisms. This is clearly something that is happening in = groups like PWE3 and CCAMP. The motivation for this should be explained = and documented to at least guide these efforts.

[TM] The current draft includes a significantly = clearer explanation, up front  in the abstract and introduction, = that this document focuses on OAM tools, i.e., on the data plane of OAM. = That is why, for example we do not discuss configuration contexts such = as CCAMP.

2.= There is no real discussion around the security aspects of these tools. = Should there be?

 

[TM] We received a similar comment from other = reviewers, as well as the SecDir review in the previous IETF last call. = After some discussion between our AD at the time (Ron Bonica) and the = Sec AD (Sean Turner), the current phrasing of the "Security = Considerations" section was agreed. It is mainly an issue of where you = draw the line between which content to include and which content not to = include in the draft, and security is currently out of scope. =

 

3. While the document provides a nice taxonomy of = various OAM tools, it does not really discuss the techniques for using = them. I do not expect anything in detail, but it is not obvious that = many of these tools can be orchestrated to form a "toolset" that can be = used to do multi-layer OAM functions for services such as carrier = Ethernet over VPLS over MPLS, for example.

 

[TM] Following your comment, we added quite a bit = of text to the introduction to explain this multi-layer orchestration. = You can take full credit for the fact that this doll IETF draft now = includes an ASCII art figure (Figure 1). :)

 

 

4. It might be useful to at least mention in the = performance metrics section, a discussion around the accuracy of these = tools and how it depends on scale, implementation and network = configurations.

[TM] Following your comment we added a note about = this in section 4.7.1. See the paragraphs beginning with =93It should be = noted that while [OWAMP]=85=94.

 

 

My detailed comments inline starting with = TOM:

 

--Tom

 

 

 

 

 

 

Expires: July 2013         =                     =    Nokia Siemens Networks

              =                     =                     =      E. Bellagamba

              =                     =                     =           Ericsson

              =                     =                     =      Y. Weingarten

 

              =                     =                     =    January 9, 2013

 

              =                 An Overview = of

      =   Operations, Administration, and Maintenance (OAM) = Mechanisms

    =               =  draft-ietf-opsawg-oam-overview-08.txt

 

 

Abstract

 

   Operations, Administration, and = Maintenance (OAM) is a general = term

   that refers to a toolset that can be = used for fault detection and

   isolation, and for performance = measurement. OAM mechanisms have been

   defined for various layers in the = protocol stack, and are used with a

   variety of = protocols.

 

   This document presents an overview of = the OAM mechanisms that have

   been defined and are currently being = defined by the IETF.

 

Status of this Memo

 

   This Internet-Draft is submitted to = IETF in full conformance with the

   provisions of BCP 78 and BCP = 79.

 

   Internet-Drafts are working documents = of the Internet Engineering

   Task Force (IETF), its areas, and its = working groups.  Note that

   other groups may also distribute = working documents as Internet-

   Drafts.

 

   Internet-Drafts are draft documents = valid for a maximum of six months

   and may be updated, replaced, or = obsoleted by other documents at any

   time.  It is inappropriate to use = Internet-Drafts as reference

   material or to cite them other than as = "work in progress."

 

   The list of current Internet-Drafts can = be accessed at

 

   The list of Internet-Draft Shadow = Directories can be accessed at

   publication of this document. Please = review these documents

   carefully, as they describe your rights = and restrictions with respect

   to this document. Code Components = extracted from this document must

   include Simplified BSD License text as = described in Section 4.e of

   the Trust Legal Provisions and are = provided without warranty as

   described in the Simplified BSD = License.

 

Table of Contents

 

 

   1. Introduction = ................................................. = 3

      = 1.1. The Building Blocks of OAM .............................. = 3

      = 1.2. Forwarding Plane vs. Management Plane ................... = 4

      = 1.3. The OAM toolsets ........................................ = 4

      = 1.4. IETF OAM Documents ...................................... = 6

      = 1.5. Non-IETF OAM Documents ................................. = 10

   2. Basic = Terminology ........................................... = 12

      = 2.1. Abbreviations .......................................... = 12

      = 2.2. Terminology used in OAM Standards ...................... = 13

      =    2.2.1. General Terms ..................................... = 13

      =    2.2.2. OAM Maintenance Entities .......................... = 13

      =    2.2.3. OAM Maintenance Points ............................ = 14

      =    2.2.4. Proactive and On-demand activation ................ = 15

      =    2.2.5. Connectivity Verification and Continuity Checks ... = 15

      =    2.2.6. Failures .......................................... = 15

   3. OAM = Tools ................................................... = 16

      = 3.1. IP Ping and Traceroute ................................. = 16

      =    3.1.1. Ping .............................................. = 16

      =    3.1.2. Traceroute......................................... = 16

      = 3.2. Bidirectional Forwarding Detection (BFD) ............... = 17

      =    3.2.1. Overview .......................................... = 17

      =    3.2.2. BFD Control ....................................... = 17

      =    3.2.3. BFD Echo .......................................... = 18

      = 3.3. MPLS OAM ............................................... = 18

      = 3.4. MPLS-TP OAM ............................................ = 19

      =    3.4.1. Overview .......................................... = 19

      =    3.4.2. Generic Associated Channel ........................ = 19

      =    3.4.3. MPLS-TP OAM Toolset ............................... = 20

      =       3.4.3.1. Continuity Check and Connectivity = Verification 20

 

 

Mizrahi, et al.         Expires = July 9, 2013                 =  [Page 2]

Internet-Draft       Overview of OAM = Mechanisms           January = 2013

 

 

            3.4.3.2. = Route Tracing ................................ = 21

      =       3.4.3.3. Lock Instruct = ................................ 21

            3.4.3.4. = Lock Reporting ............................... = 21

      =       3.4.3.5. Alarm Reporting = .............................. 21

            3.4.3.6. = Remote Defect Indication ..................... = 22

      =       3.4.3.7. Client Failure Indication = .................... 22

            3.4.3.8. = Packet Loss Measurement (LM) ................. = 22

      =       3.4.3.9. Packet Delay Measurement (DM) = ................ 22

 =     3.5. PWE3 OAM = ............................................... = 23

      =    3.5.1. PWE3 OAM using Virtual Circuit Connectivity = Verification

  =        (VCCV) = ................................................... = 23

      =    3.5.2. PWE3 OAM using G-ACh .............................. = 24

      = 3.6. OWAMP and TWAMP......................................... = 24

      =    3.6.1. Overview .......................................... = 24

      =    3.6.2. Control and Test Protocols ........................ = 24

      =    3.6.3. OWAMP ............................................. = 25

      =    3.6.4. TWAMP ............................................. = 26

      = 3.7. Summary of OAM Functions ............................... = 26

   4. = Security Considerations ..................................... = 27

   5. IANA = Considerations ......................................... = 27

   6. = Acknowledgments ............................................. = 27

   7. = References .................................................. = 28

      = 7.1. Normative References ................................... = 28

      = 7.2. Informative References ................................. = 31

 

1. Introduction

 

   OAM is a general term that refers to a = toolset for detecting,

   isolating and reporting connection = failures and performance

  =  degradation.

 

   This document summarizes the OAM tools = and mechanisms defined in the

   IETF.

 

   The term OAM in this document refers to = Operations, Administration

   and Maintenance [OAM-Def], focusing on = the forwarding plane of OAM.

   Hence, management aspects are outside = the scope of this document.

 

TOM: This is a curious sentence to me since to me, = OAM is management, or a subset of it.   Also, if you look at the = referenced documents, there are many indirect references to MIBs, = Netconf, etc=85 making this sentence further confusing. It might be = helpful to explain more clearly that the authors here intended to not = cover those things explicitly rather than grouping them arbitrarily = under the definition of "management aspects"  Further, to clarify, = it might be useful to expand on what "forwarding plane" is here just to = be clear.   That is, is this "in band" or "out-of band" or both? = Some of the tools referred to here also are part of the control AND data = planes. 

[TM] We significantly improved the distinction = between the different planes: data plane, control plane, management = plane. We added a definition of each of the terms, and we now explicitly = explain that the draft focuses on the data plane. We also explain in the = current draft that we adopt the OAM acronym as recommended in RFC 6291: = Operations, Administration and Maintenance (without Management...). = Please let us know if you think something is still missing = here.

 

 

1.1. The Building Blocks of = OAM

 

   An OAM protocol is run in the context = of a Maintenance Domain,

   consisting of two or more nodes that = run the OAM protocol, referred

   to as Maintenance Points = (MP).

 

   This subsection provides a brief = summary of the common tools used by

   OAM protocols. An OAM protocol = typically supports one or more of the

   tools described = below.

 

 

Mizrahi, et al.         Expires = July 9, 2013                 =  [Page 3]

Internet-Draft       Overview of OAM = Mechanisms           January = 2013

 

 

   o Continuity Checking = (CC):

    =   Used for verifying the liveness of a connection between two = MPs.

 

   o Connectivity Verification = (CV):

    =   Allows an MP to check whether it is connected to a peer MP, and = to

      = verify that messages from the peer MP are received through = the

      = expected path.

 

   o Path Discovery / Fault = Localization:

  =     An MP uses this mechanism to trace the route to a peer MP, = i.e.,

    =   to identify the nodes along the path to the peer MP. When = a

      = connection fails, this mechanism also allows the MP to detect = the

      = location of the failure.

 

TOM: The definition calls this "path discovery" but = then talks about tracing routes. A better way of describing this in the = paragraph would be that there I a use of path tracing in order to = discover (or re-discover) paths that have been changed, created or = destroyed.  

[TM] We rephrased this paragraph, and hopefully it = is clearer and more accurate now.

 

 

   o Performance = Monitoring:

  =     Consists of 3 main functions

 

        o Loss Measurement (LM) = - monitors the packet loss rate of a

          = connection.

 

        o Delay Measurement (DM) = - monitors the delay and delay

          variation between = MPs.

 

        o Throughput measurement = - monitors the throughput of a

          = connection.

 

TOM: Along with the discussion above around path = trace/discovery, it is imperative that paths be discovered (one way or = another) in order to successfully d performance monitoring on those = paths.

[TM] True. However this section presents a short = list of typical OAM functions, and we would rather stick with succinct = descriptions in this section.

 

 

1.2. Forwarding Plane vs. Management = Plane

 

   While the OAM tools may, and quite = often do, work in conjunction with

   a control-plane or management plane, = they are usually defined to be

   independent of the control-plane. =  The OAM tools communicate with the

   management plane to raise alarms, and = often the on-demand tools may

   be activated by the management, e.g. to = locate and localize problems.

 

   The considerations of the control-plane = maintenance tools or the

   functionality of the management-plane = are out of scope for this

   document, which will concentrate on = presenting the forwarding-plane

   tools that are used for = OAM.

 

TOM: What about the data plane? For example, the = GACH OAM type is such an example. VCCV also operates within the data = plane after its configuration capabilities have been signaled.  It = should also be mentioned that it is imperative that when required, OAM = tools are capable of testing the actual data plane in as much accuracy = as possible, but that they all should note how accurate.   Not all = OAM tools are created equal.

[TM] We rephrased this subsection, and now have a = much clearer definition of each plane in =932.2.4. Data Plane, Control = Plane and Management Plane=94. We also added specific text about the = importance of fate-sharing (see section 1.4), which addresses the second = part of your comment.

 

 

1.3. The OAM toolsets

 

   This memo provides an overview of the = different sets of OAM

   mechanisms defined by the IETF. It is = intended for those with little

   or no familiarity with the described = mechanisms. The set of OAM

   mechanisms described in this memo are = applicable to IP unicast, MPLS,

   pseudowires, and MPLS for the transport = environment (MPLS-TP). While

   OAM mechanisms that are applicable to = other technologies exist, they

 

 

Mizrahi, et al.         Expires = July 9, 2013                 =  [Page 4]

Internet-Draft       Overview of OAM = Mechanisms           January = 2013

 

 

   are beyond the scope of this memo. This = document focuses on IETF

   documents that have been published as = RFCs, while other ongoing OAM-

   related work is outside the = scope.

 

   The IETF has defined OAM protocols and = mechanisms in several

   different = fronts:

 

   o IP Ping and = Traceroute:

  =     Ping is a very simple and common application for failure = diagnosis

 

TOM: I am not sure the term "common" is = necessary.

[TM] Removed.

 

      that uses ICMP Echo requests, = as defined in [ICMPv4], and

      = [ICMPv6].

    =   Traceroute ([TCPIP-Tools], [NetTools]) is an application = that

    =   allows users to trace the path between an IP source and an = IP

      = destination, i.e., to identify the nodes along the = path.

 

   o BFD:

      Bidirectional Forwarding = Detection (BFD) is defined in [BFD] as a

      framework for a lightweight = generic OAM mechanism.  The intention

      is to define a base mechanism = that can be used with various

      encapsulation types, network = environments, and in various medium

      = types.

 

   o MPLS OAM:

      MPLS LSP Ping, as defined in = [MPLS-OAM], [MPLS-OAM-FW] and [LSP-

      Ping], is an OAM mechanism for = point to point MPLS LSPs. It

      includes two main functions: = Ping and Traceroute.

 

   o MPLS-TP = OAM:

    =   MPLS-TP OAM is defined in a set of RFCs. The OAM requirements = for

      = MPLS Transport Profile (MPLS-TP) are defined in = [MPLS-TP-OAM].

  =     Each of the tools in the OAM toolset is defined in its own = RFC, as

    =   specified in Section 1.4.

 

   o PWE3 OAM:

      The PWE3 OAM architecture = defines control channels that support

      the use of existing IETF OAM = tools to be used for a pseudowire

      (PW).  The control = channels that are defined in [VCCV] and = [PW-G-

    =   ACH] may be used in conjunction with ICMP Ping, LSP Ping, and = BFD

      = to perform CC and CV functionality.  In addition the = channels

    =   support use of any of the MPLS-TP based OAM tools for = completing

    =   their respective OAM functionality for a = PW.

 

   o OWAMP and = TWAMP:

    =   The One Way Active Measurement Protocol (OWAMP) and the Two = Way

      = Active Measurement Protocols (TWAMP) are two protocols defined = in

      = the IP Performance Metrics (IPPM) working group in the IETF. = These

    =   protocols allow delay and packet loss measurement in IP = networks.

 

 

Mizrahi, et al.         Expires = July 9, 2013                 =  [Page 5]

Internet-Draft       Overview of OAM = Mechanisms           January = 2013

 

 

   This document summarizes the OAM = mechanisms defined by the IETF. We

   first present a comparison of the = terminology used in various OAM

   standards, and then summarize the OAM = functions that each OAM

   standard = provides.

 

1.4. IETF OAM Documents

 

   Table 1 summarizes the IETF OAM related = RFCs discussed in this

   document.

 

   The table includes a "Type" column, = specifying the nature of each of

   the listed = documents:

 

   o Tool: documents that define an OAM = tool or mechanism.

 

   o Prof.: documents that define a = profile or a variant for an OAM

      tool that is defined in other = documents.

 

   o Inf.: documents that define an = infrastructure that is used by OAM

      = tools.

 

   o Misc.: other OAM related documents, = e.g., OAM requirement and

      framework = documents.

 

  =  +-----------+--------------------------------------+-----+----------= +

   |   =         | Title           =                     =  |Type | RFC      |

  =  +-----------+--------------------------------------+-----+----------= +

   |IP Ping = and| Internet Control Message Protocol    |Tool | RFC 792 =  |

  =  |Traceroute | [ICMPv4]             =                 |     = |          |

   |           = +--------------------------------------+-----+----------+

   |       =     | Internet Control Message Protocol    |Tool | = RFC 4443 |

  =  |           | (ICMPv6) for the Internet = Protocol   |     |         =  |

   | =           | Version 6 (IPv6) Specification =       |     |         =  |

   | =           | [ICMPv6]       =                     =   |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | A Primer On Internet and TCP/IP     =  |Tool | RFC 2151 |

   |           | = Tools and Utilities [TCPIP-Tools]    |     |   =        |

   |           = +--------------------------------------+-----+----------+

   |       =     | FYI on a Network Management Tool     |Tool | = RFC 1147 |

  =  |           | Catalog: Tools for = Monitoring and    |     |       =    |

  =  |           | Debugging TCP/IP Internets = and       |     |         =  |

   | =           | Interconnected Devices [NetTools] =    |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Extended ICMP to Support Multi-Part  |Tool | RFC = 4884 |

 

 

Mizrahi, et al.         Expires = July 9, 2013                 =  [Page 6]

Internet-Draft       Overview of OAM = Mechanisms           January = 2013

 

 

   |           | = Messages [ICMP-MP]               =     |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | ICMP Extensions for Multiprotocol    |Tool | = RFC 4950 |

  =  |           | Label Switching [ICMP-Ext] =           |     |     =      |

   |           = +--------------------------------------+-----+----------+

   |       =     | Extending ICMP for Interface and     |Tool | = RFC 5837 |

  =  |           | Next-Hop Identification = [ICMP-Int]   |     |         =  |

  =  +-----------+--------------------------------------+-----+----------= +

   |BFD =        | Bidirectional Forwarding Detection   = |Tool | RFC 5880 |

  =  |           | [BFD]       =                     =      |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Bidirectional Forwarding Detection   |Prof.| RFC = 5881 |

   | =           | (BFD) for IPv4 and IPv6 (Single = Hop) |     |         =  |

   | =           | [BFD-IP]       =                     =   |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Generic Application of Bidirectional |Misc.| RFC 5882 = |

   |   =         | Forwarding Detection [BFD-Gen]   =     |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Bidirectional Forwarding Detection   |Prof.| RFC = 5883 |

   | =           | (BFD) for Multihop Paths = [BFD-Multi] |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Bidirectional Forwarding Detection   |Prof.| RFC = 5884 |

   | =           | for MPLS Label Switched Paths = (LSPs) |     |         =  |

   | =           | [BFD-LSP]       =                     =  |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Bidirectional Forwarding Detection   |Prof.| RFC = 5885 |

   | =           | for the Pseudowire Virtual Circuit =   |     |         =  |

   | =           | Connectivity Verification (VCCV) =     |     |         =  |

   | =           | [BFD-VCCV]       =                     | =     |         =  |

  =  +-----------+--------------------------------------+-----+----------= +

   |MPLS OAM =   | Operations and Management (OAM)      |Misc.| RFC = 4377 |

   | =           | Requirements for Multi-Protocol = Label|     |         =  |

   | =           | Switched (MPLS) Networks [MPLS-OAM] =  |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | A Framework for Multi-Protocol       = |Misc.| RFC 4378 |

  =  |           | Label Switching (MPLS) = Operations    |     |         =  |

   | =           | and Management (OAM) [MPLS-OAM-FW] =   |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Detecting Multi-Protocol Label       = |Tool | RFC 4379 |

  =  |           | Switched (MPLS) Data Plane = Failures  |     |         =  |

   | =           | [LSP-Ping]       =                     | =     |         =  |

 

 

Mizrahi, et al.         Expires = July 9, 2013                 =  [Page 7]

Internet-Draft       Overview of OAM = Mechanisms           January = 2013

 

 

   |           = +--------------------------------------+-----+----------+

   |       =     | Operations and Management (OAM)     =  |Misc.| RFC 4687 |

   |           | = Requirements for Point-to-Multipoint |     |     =      |

   |           | = MPLS Networks [MPLS-P2MP]            | =     |         =  |

  =  +-----------+--------------------------------------+-----+----------= +

   |MPLS-TP =    | Requirements for OAM in MPLS-TP     =  |Misc.| RFC 5860 |

   |OAM        | = [MPLS-TP-OAM]                 =        |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | MPLS Generic Associated Channel     =  |Inf. | RFC 5586 |

   |           | = [G-ACh]                   =            |     |     =      |

   |           = +--------------------------------------+-----+----------+

   |       =     | MPLS-TP OAM Framework           =      |Misc.| RFC 6371 |

   |           | = [TP-OAM-FW]                 =          |     |       =    |

  =  |           = +--------------------------------------+-----+----------+

   |       =     | Proactive Connectivity Verification, |Tool | RFC 6428 = |

   |   =         | Continuity Check, and Remote Defect =  |     |         =  |

   | =           | Indication for the MPLS Transport =    |     |         =  |

   | =           | Profile [TP-CC-CV]     =               |     | =          |

   |           = +--------------------------------------+-----+----------+

   |       =     | MPLS On-Demand Connectivity         =  |Tool | RFC 6426 |

   |           | = Verification and Route Tracing       |     | =          |

   |           | = [OnDemand-CV]                 =        |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | MPLS Fault Management Operations,    |Tool | = RFC 6427 |

  =  |           | Administration, and = Maintenance (OAM)|     |         =  |

   | =           | [TP-Fault]       =                     | =     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | MPLS Transport Profile Lock Instruct |Tool | RFC 6435 = |

   |   =         | and Loopback Functions [Lock-Loop]   = |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Packet Loss and Delay Measurement for|Tool | RFC 6374 = |

   |   =         | MPLS Networks [MPLS-LM-DM]     =       |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | A Packet Loss and Delay Measurement  |Prof.| RFC = 6375 |

   | =           | Profile for MPLS-Based Transport =     |     |         =  |

   | =           | Networks [TP-LM-DM]     =              |     |   =        |

  =  +-----------+--------------------------------------+-----+----------= +

   |PWE3 OAM =   | Pseudowire Virtual Circuit           = |Inf. | RFC 5085 |

  =  |           | Connectivity Verification = (VCCV):    |     |         =  |

   | =           | A Control Channel for Pseudowires =    |     |         =  |

   | =           | [VCCV]         =                     =   |     |         =  |

 

 

Mizrahi, et al.         Expires = July 9, 2013                 =  [Page 8]

Internet-Draft       Overview of OAM = Mechanisms           January = 2013

 

 

   |           = +--------------------------------------+-----+----------+

   |       =     | Bidirectional Forwarding Detection   |Prof.| RFC = 5885 |

   | =           | for the Pseudowire Virtual Circuit =   |     |         =  |

   | =           | Connectivity Verification (VCCV) =     |     |         =  |

   | =           | [BFD-VCCV]       =                     | =     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Using the Generic Associated Channel |Inf. | RFC 6423 = |

   |   =         | Label for Pseudowire in the MPLS   =   |     |         =  |

   | =           | Transport Profile (MPLS-TP)   =        |     |         =  |

   | =           | [PW-G-ACh]       =                     | =     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Pseudowire (PW) Operations,         =  |Misc.| RFC 6310 |

   |           | = Administration, and Maintenance (OAM)|     |     =      |

   |           | = Message Mapping [PW-Map]             | =     |         =  |

  =  +-----------+--------------------------------------+-----+----------= +

   |OWAMP = and  | A One-way Active Measurement Protocol|Tool | RFC 4656 = |

   |TWAMP =      | [OWAMP]             =                  |   =   |          |

   |           = +--------------------------------------+-----+----------+

   |       =     | A Two-Way Active Measurement Protocol|Tool | RFC 5357 = |

   |   =         | [TWAMP]           =                    | =     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | Framework for IP Performance Metrics |Misc.| RFC 2330 = |

   |   =         | [IPPM-FW]         =                    | =     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | IPPM Metrics for Measuring         =   |Misc.| RFC 2678 |

   |           | = Connectivity [IPPM-Con]             =  |     |         =  |

   | =           = +--------------------------------------+-----+----------+

   |       =     | A One-way Delay Metric for IPPM     =  |Misc.| RFC 2679 |

   |           | = [IPPM-1DM]                 =           |     |     =      |

   |           = +--------------------------------------+-----+----------+

   |       =     | A One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 = |

   |   =         | [IPPM-1LM]         =                   |   =   |          |

   |           = +--------------------------------------+-----+----------+

   |       =     | A Round-trip Delay Metric for IPPM   |Misc.| RFC = 2681 |

   | =           | [IPPM-2DM]       =                     | =     |         =  |

  =  +-----------+--------------------------------------+-----+----------= +

      =            Table 1 Summary of IETF OAM = Related RFCs

 

 

 

 

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 =  [Page 9]

Internet-Draft       Overview of OAM = Mechanisms           January = 2013

 

 

1.5. Non-IETF OAM = Documents

 

   In addition to the OAM mechanisms = defined by the IETF, the IEEE and

   ITU-T have also defined various OAM = mechanisms that focus on

   Ethernet, and various other transport = network environments. These

   various mechanisms, defined by the = three standard organizations, are

   often tightly coupled, and have had a = mutual effect on each other.

   The ITU-T and IETF have both defined = OAM mechanisms for MPLS LSPs,

   [ITU-T-Y1711] and [LSP-Ping]. The = following OAM standards by the IEEE

   and ITU-T are to some extent linked to = IETF OAM mechanisms listed

   above and are mentioned here only as = reference material:

 

   o OAM mechanisms for Ethernet based = networks have been defined by

      both the ITU-T in = [ITU-T-Y1731], and by the IEEE in = [IEEE802.1ag].

  =     The IEEE 802.3 standard defines OAM for one-hop Ethernet = links

    =   [IEEE802.3ah].

 

   o The ITU-T has defined OAM for MPLS = LSPs in [ITU-T-Y1711], and

      MPLS-TP OAM in [ITU-G8113.1] = and [ITU-G8113.2].

 

   Table 2 summarizes the OAM standards = mentioned in this document. This

   document focuses on IETF OAM standards, = but these non-IETF standards

   are referenced where = relevant.

 

  =  +-----------+--------------------------------------+---------------+=

   |   =         | Title           =                     =  |Standard/Draft |

  =  +-----------+--------------------------------------+---------------+=

   |ITU-T =      | Operation & Maintenance mechanism   =  | ITU-T Y.1711  |

   |MPLS OAM   | for MPLS networks = [ITU-T-Y1711]      |           =     |

  =  |           = +--------------------------------------+---------------+

   |       =     | Assignment of the 'OAM Alert Label'  | RFC 3429 =      |

   |           | = for Multiprotocol Label Switching    |       =         |

   |           | = Architecture (MPLS) Operation and    |       =         |

   |           | = Maintenance (OAM) Functions          |   =             |

   |           | = [OAM-Label]                 =          |           =     |

  =  |           |         =                     =          |           =     |

  =  |           |  Note: although this = is an IETF      |           =     |

  =  |           |  document, it is = listed as one of the|               = |

   |   =         |  non-IETF OAM standards, since it =    |               = |

   |   =         |  was defined as a complementary part = |               = |

   |   =         |  of ITU-T Y.1711.     =                |     =           |

  =  +-----------+--------------------------------------+---------------+=

   |ITU-T =      | Operations, administration and     =   |ITU-T G.8113.2 |

   |MPLS-TP OAM| Maintenance mechanisms = for MPLS-TP   |               = |

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 10]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   |           | = networks using the tools defined for |         =       |

   |           | = MPLS [ITU-G8113.2]               =     |               = |

   |   =         |             =                     =      |               = |

   |   =         |  Note: this document describes the =   |               = |

   |   =         |  OAM toolset defined by the IETF for = |               = |

   |   =         |  MPLS-TP, whereas ITU-T G.8113.1 =     |               = |

   |   =         |  describes the OAM toolset defined =   |               = |

   |   =         |  by the ITU-T.       =                 |     =           |

   |           = +--------------------------------------+---------------+

   |       =     | Operations, Administration and       = |ITU-T G.8113.1 |

  =  |           | Maintenance mechanism for = MPLS-TP in |               = |

   |   =         | Packet Transport Network (PTN)   =     |               = |

   |   =         = +--------------------------------------+---------------+

   |       =     | Allocation of a Generic Associated   | RFC 6671 =      |

   |           | = Channel Type for ITU-T MPLS Transport|         =       |

   |           | = Profile Operation, Maintenance, and  |         =       |

   |           | = Administration (MPLS-TP OAM)         |     =           |

   |           | = [ITU-T-CT]                 =           |           =     |

  =  |           |         =                     =          |           =     |

  =  |           |  Note: although this = is an IETF      |           =     |

  =  |           |  document, it is = listed as one of the|               = |

   |   =         |  non-IETF OAM standards, since it =    |               = |

   |   =         |  was defined as a complementary part = |               = |

   |   =         |  of ITU-T G.8113.1.     =              |       =         |

  =  +-----------+--------------------------------------+---------------+=

   |ITU-T =      | OAM Functions and Mechanisms for     = |[ITU-T-Y1731]  |

   |Ethernet   | Ethernet-based = Networks              |     =           |

   |OAM        | =                     =                  |   =             |

  =  +-----------+--------------------------------------+---------------+=

   |IEEE =       | Connectivity Fault Management     =    | IEEE 802.1ag  |

   |CFM        | = [IEEE802.1ag]                 =        |             =   |

   | =           |           =                     =        |             =   |

   | =           |  Note: CFM was originally = published  |               = |

   |   =         |  as IEEE 802.1ag, but is now   =       |               = |

   |   =         |  incorporated in the 802.1Q = standard.|               = |

  =  +-----------+--------------------------------------+---------------+=

   |IEEE =       | Media Access Control Parameters,     | = IEEE 802.3ah  |

   |802.3      | Physical = Layers, and Management      |         =       |

   |link level | Parameters for Subscriber = Access     |               = |

   |OAM =        | Networks [IEEE802.3ah]       =         |             =   |

   | =           |           =                     =        |             =   |

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 11]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   |           | =  Note: link level OAM was originally |         =       |

   |           | =  defined in IEEE 802.3ah, and is now |         =       |

   |           | =  incorporated in the 802.3 standard. |         =       |

  =  +-----------+--------------------------------------+---------------+=

      =    Table 2 Non-IETF OAM Standards Mentioned in this = Document

 

2. Basic Terminology

 

2.1. Abbreviations

 

   ACH    Associated Channel = Header

 

   AIS    Alarm Indication = Signal

 

   BFD    Bidirectional = Forwarding Detection

 

   CC     Continuity = Check

 

   CV     Connectivity = Verification

 

   DM     Delay = Measurement

 

   FEC    Forwarding Equivalence = Class

 

   GAL    Generic Associated = Label

 

   ICMP   Internet Control Message = Protocol

 

   LDP    Label Distribution = Protocol

 

   LM     Loss = Measurement

 

   LSP    Label Switched = Path

 

   ME     Maintenance = Entity

 

   MEG    Maintenance Entity = Group

 

   MEP    MEG End = Point

 

   MIP    MEG Intermediate = Point

 

   MP     Maintenance = Point

 

   MPLS   Multiprotocol Label = Switching

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 12]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   MPLS-TP MPLS Transport = Profile

 

   MTU    Maximum Transmission = Unit

 

   OAM    Operations, = Administration, and Maintenance

 

   PW     = Pseudowire

 

   PWE3   Pseudowire Emulation = Edge-to-Edge

 

   RDI    Remote Defect = Indication

 

   TTL    Time To = Live

 

   VCCV   Virtual Circuit = Connectivity Verification

 

 

TOM: Why is this section not at the top of this = document, as is customary for RFCs?  

[TM] The introduction is now significantly shorter = than it was when you sent this comment, which means that the terminology = section is now much closer to the beginning of the = document.

 

 

2.2. Terminology used in OAM = Standards

 

2.2.1. General Terms

 

   A wide variety of terms is used in = various OAM standards. Each of the

   OAM standards listed in the reference = section includes a section that

   defines terms relevant to that tool. A = thesaurus of terminology for

   MPLS-TP terms is presented in = [TP-Term], and provides a good summary

   of some of the OAM related = terminology.

 

   This section presents a comparison of = the terms used in various OAM

   standards, without fully quoting the = definition of each term. For a

   formal definition of each term, refer = to the references at the end of

   this = document.

 

2.2.2. OAM Maintenance = Entities

 

   OAM tools are designed to monitor and = manage a Maintenance Entity

   (ME).  An ME, as defined in = [TP-OAM-FW], defines a relationship

   between two points of a transport path = to which maintenance and

   monitoring operations = apply.

 

   The following related terms are also = quoted from [TP-OAM-FW]:

 

   o MEP: The two points that define a = maintenance entity.

 

   o MEG: The collection of one or more = MEs that belongs to the same

      transport path and that are = maintained and monitored as a group

      are known as a Maintenance = Entity Group (MEG).

 

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 13]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   o MIP: In between MEPs, there are zero = or more intermediate points,

      called Maintenance Entity Group = Intermediate Points (MIPs).

 

   A pair of MEPs engaged in an ME are = connected by a communication

   link, which may be one of several types = of connection, e.g. a single

   physical connection, a set of physical = connections, or a virtual link

   such as an MPLS = LSP.

 

   The term Maintenance Entity (ME) is = used in ITU-T Recommendations

   (e.g. [ITU-T-Y1731]), as well as in the = MPLS-TP terminology ([TP-OAM-

   FW]). Various terms are used to refer = to an ME. For example, BFD does

   not explicitly use a term that is = equivalent to ME, but rather uses

   the term "session", referring to the = relationship between two nodes

   using a BFD protocol. The MPLS LSP Ping = ([LSP-Ping]) terminology

   simply uses the term "LSP" in this = context.

 

   MPLS-TP has defined the terms ME and = Maintenance Entity Group (MEG)

   in [TP-OAM-FW], similar to the terms = defined by ITU-T.  A MEG allows

   the monitoring of a compound set of = MEs, for example when monitoring

   a p2mp MEG that is considered to be the = set of MEs between the root

   and each individual destination = MEP.

 

2.2.3. OAM Maintenance = Points

 

   A Maintenance Point (MP) is a = functional entity that is defined at a

   node in the network, and either = initiates or reacts to OAM messages.

   A Maintenance End Point (MEP) is one of = the end points of an ME, and

   can initiate OAM messages and respond = to them. A Maintenance

   Intermediate Point (MIP) is an = intermediate point between two MEPs,

   that does not generally initiate OAM = frames (one exception to this is

   the use of AIS notifications), but is = able to respond to OAM frames

   that are destined to it. A MIP in = MPLS-TP identifies OAM packets

   destined to it by the value of the TTL = field in the OAM packet. The

   term Maintenance Point is a general = term for MEPs and MIPs.

 

   The 802.1ag defines a finer distinction = between Up MPs and Down MPs.

   An MP is a bridge interface, that is = monitored by an OAM protocol

   either in the direction facing the = network, or in the direction

   facing the bridge. A Down MP is an MP = that receives OAM packets from,

   and transmits them to the direction of = the network. An Up MP receives

   OAM packets from, and transmits them to = the direction of the bridging

   entity.

 

   MPLS-TP ([TP-OAM-FW]) uses a similar = distinction on the placement of

   the MP - either at the ingress, egress, = or forwarding function of the

   node (Down / Up MPs).  This = placement is important for localization

   of a connection = failure.

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 14]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

2.2.4. Proactive and On-demand = activation

 

   The different OAM tools may be used in = one of two basic types of

   activation:

 

   o Proactive activation - indicates that = the tool is activated on a

      continual basis periodically, = where messages are sent between the

      two MEPs, and errors are = detected when a certain number of

      expected messages are not = received.

 

   o On-demand activation - indicates that = the tool is activated

      "manually" to detect a specific = anomaly.  In this activation a

      small number of OAM messages = are sent by a MEP and the reply

      message is = received.

 

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.

 

   Continuity checks are used to verify = the liveness of a connection or

   a path between two MPs, and are = typically sent proactively, though

   they can be invoked on-demand as = well.

 

   A connectivity verification function = allows an MP to check whether it

   is connected to a peer MP or not. This = function also allows the MP to

   verify that messages from the peer MP = are received through the

   correct path, thereby verifying not = only that the two MPs are

   connected, but also that they are = connected through the expected

   path. This allows detection of = unexpected topology changes. A

   connectivity verification (CV) protocol = typically uses a CV message,

   followed by a CV reply that is sent = back to the originator. A CV

   function can be applied proactively or = on-demand.

 

   Connectivity verification and = continuity checks are considered

   complementary mechanisms, and are often = used in conjunction with each

   other.

 

2.2.6. Failures

 

   The terms Failure, Fault, and Defect = are used interchangeably in the

   standards, referring to a malfunction = that can be detected by a

   connectivity or a continuity check. In = some standards, such as

   [IEEE802.1ag], there is no distinction = between these terms, while in

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 15]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   other standards each of these terms = refers to a different type of

  =  malfunction.

 

   The terminology used in IETF MPLS-TP = OAM takes after the ITU-T, which

   distinguishes between these terms in = [ITU-T-G.806]; The term Fault

   refers to an inability to perform a = required action, e.g., an

   unsuccessful attempt to deliver a = packet. The term Defect refers to

   an interruption in the normal = operation, such as a consecutive period

   of time where no packets are delivered = successfully. The term Failure

   refers to the termination of the = required function. While a Defect

   typically refers to a limited period of = time, a failure refers to a

   long period of = time.

 

3. OAM Tools

 

3.1. IP Ping and = Traceroute

 

3.1.1. Ping

 

   Ping is a common network diagnosis = application for IP networks that

   uses ICMP. The ICMP Echo request/reply = exchange is a connectivity

   verification function for the Internet = Protocol. The originator

   transmits an ICMP Echo request packet, = and the receiver replies with

   an Echo reply. ICMP ping is defined in = two variants, [ICMPv4] is used

   for IPv4, and [ICMPv6] is used for = IPv6.

 

3.1.2. Traceroute

 

   Traceroute ([TCPIP-Tools], [NetTools]) = is an application that allows

   users to discover the path between an = IP source and an IP

 =  destination. Traceroute sends a sequence of UDP packets to UDP = port

   33434 = at the destination. By default, Traceroute begins by = sending

  =  three packets (the number of packets is configurable in = most

  =  Traceroute implementations), each with an IP Time-To-Live (TTL) = value

   of = one to the destination. These packets expire as soon as they = reach

   the = first router in the path. That router responds by sending = three

   ICMP = Time Exceeded Messages to the Traceroute application. = Traceroute

  =  now sends another three UDP packets, each with the TTL value of = 2.

   These = messages cause the second router to return ICMP messages. = This

  =  process continues, with ever increasing values for the TTL = field,

  =  until the packets actually reach the destination. Because = no

  =  application listens to port 33434 at the destination, the = destination

  =  returns ICMP Destination Unreachable Messages indicating = an

  =  unreachable port. This event indicates to the Traceroute = application

  =  that it is finished.  The Traceroute program displays the = round-trip

  =  delay associated with each of the = attempts.

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 16]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   Note that IP routing may be asymmetric. = While Traceroute reveals the

   path between a source and destination, = it may not reveal the reverse

   path.

 

   A few ICMP extensions ([ICMP-Ext], = [ICMP-MP], [ICMP-Int]) have been

   defined in the context of Traceroute. = These extensions augment the

   ICMP Destination Unreachable message, = and can be used by Traceroute

  =  applications.

 

3.2. Bidirectional Forwarding Detection = (BFD)

 

3.2.1. Overview

 

   While multiple OAM mechanisms have been = defined for various protocols

   in the protocol stack, Bidirectional = Forwarding Detection [BFD],

   defined by the IETF BFD working group, = is a generic OAM mechanism

   that can be deployed over various = encapsulating protocols, and in

   various medium types. The IETF has = defined variants of the protocol

   for IP ([BFD-IP], [BFD-Multi]), for = MPLS LSPs [BFD-LSP], and for PWE3

   [BFD-VCCV]. The usage of BFD in MPLS-TP = is defined in [MPLS-TP-CC-

   CV].

 

   BFD includes two main OAM functions, = using two types of BFD packets:

   BFD Control packets, and BFD Echo = packets.

 

3.2.2. BFD Control

 

   BFD supports a bidirectional continuity = check, using BFD control

   packets, that are exchanged within a = BFD session. BFD sessions

   operate in one of two = modes:

 

   o Asynchronous mode (i.e. proactive): = in this mode BFD control

      packets are sent periodically. = When the receiver detects that no

      BFD control packet have been = received during a predetermined

      period of time, a failure is = detected.

 

   o Demand mode: in this mode, BFD = control packets are sent on-demand.

      Upon need, a system initiates a = series of BFD control packets to

      verify the liveness of the = session. BFD control packets are sent

      independently in each = direction.

 

   Each of the end-points of the monitored = path maintains its own

   session identification, called a = Discriminator, both of which are

   included in the BFD Control Packets = that are exchanged between the

   end-points.  At the time of = session establishment, the Discriminators

   are exchanged between the two-end = points.  In addition, the

   transmission (and reception) rate is = negotiated between the two end-

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 17]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   points, based on information included = in the control packets.  These

   transmission rates may be renegotiated = during the session.

 

   During normal operation of the session, = i.e. no failures are

   detected, the BFD session is in the Up = state.  If no BFD Control

   packets are received during a fixed = period of time, called the

 

TOM: Fixed, pre-configured or negotiated period of = time (i.e.: BFD interval)

[TM] We rephrased this = sentence.

 

   Detection Time, the session is declared = to be Down. The detection

   time is a function of the negotiated = transmission time, and a

   parameter called Detect Mult. Detect = Mult determines the number of

   missing BFD Control packets that cause = the session to be declared as

   Down. This parameter is included in the = BFD Control packet.

 

3.2.3. BFD Echo

 

   A BFD echo packet is sent to a peer = system, and is looped back to the

   originator. The echo function can be = used proactively, or on-demand.

 

   The BFD echo function has been defined = in BFD for IPv4 and IPv6

   ([BFD-IP]), but is not used in BFD for = MPLS LSPs, PWs, or in BFD for

   MPLS-TP.

 

3.3. MPLS OAM

 

   The IETF MPLS working group has defined = OAM for MPLS LSPs. The

   requirements and framework of this = effort are defined in [MPLS-OAM-

   FW] and [MPLS-OAM], respectively. The = corresponding OAM mechanism

   defined, in this context, is LSP Ping = [LSP-Ping].

 

   LSP Ping is based on ICMP Ping and just = like its predecessor may be

   used in one of two = modes:

 

   o "Ping" mode: In this mode LSP ping is = used for end-to-end

 =     connectivity verification between two = LERs.

 

   o "Traceroute" mode: This mode is used = for hop-by-hop fault

      = isolation.

 

   LSP Ping extends the basic ICMP Ping = operation (of data-plane

   connectivity verification) with = functionality to verify data-plane

   vs. control-plane consistency for a = Forwarding Equivalence Class

   (FEC) and also Maximum Transmission = Unit (MTU) problems. The

   traceroute functionality may be used to = isolate and localize the MPLS

   faults, using the Time-to-live (TTL) = indicator to incrementally

   identify the sub-path of the LSP that = is successfully traversed

   before the faulty link or = node.

 

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 18]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   It should be noted that LSP Ping = supports unique identification of

   the LSP within an addressing domain. = The identification is checked

   using the full FEC identification. LSP = Ping is easily extensible to

   include additional information needed = to support new functionality,

   by use of Type-Length-Value (TLV) = constructs. The usage of TLVs is

   typically not easy to perform in = hardware, and is thus typically

   handled by the control = plane.

 

   LSP Ping supports both asynchronous, as = well as, on-demand

  =  activation.

 

3.4. MPLS-TP OAM

 

3.4.1. Overview

 

   The MPLS working group is currently = working on defining the OAM

   toolset that fulfills the requirements = for MPLS-TP OAM. The full set

   of requirements for MPLS-TP OAM are = defined in [MPLS-TP-OAM], and

   include both general requirements for = the behavior of the OAM

   mechanisms and a set of operations that = should be supported by the

   OAM toolset.  The set of = mechanisms required are further elaborated

   in [TP-OAM-FW], which describes the = general architecture of the OAM

   system as well as giving overviews of = the functionality of the OAM

   toolset.

 

   Some of the basic requirements for the = OAM toolset for MPLS-TP are:

 

   o MPLS-TP OAM must be able to support = both an IP based and non-IP

      based environment. If the = network is IP based, i.e. IP routing and

      forwarding are available, then = the MPLS-TP OAM toolset should rely

      on the IP routing and = forwarding capabilities. On the other hand,

      in environments where IP = functionality is not available, the OAM

      tools must still be able to = operate without dependence on IP

      forwarding and = routing.

 

   o OAM packets and the user traffic are = required to be congruent

      (i.e. OAM packets are = transmitted in-band) and there is a need to

      differentiate OAM packets from = user-plane ones. Inherent in this

      requirement is the principle = that MPLS-TP OAM be independent of

      any existing control-plane, = although it should not preclude use of

      the control-plane = functionality.

 

3.4.2. Generic Associated = Channel

 

   In order to address the requirement for = in-band transmission of MPLS-

   TP OAM traffic, MPLS-TP uses a Generic = Associated Channel (G-ACh),

   defined in [G-ACh] for LSP-based OAM = traffic. This mechanism is based

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 19]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   on the same concepts as the PWE3 ACH = and VCCV mechanisms.  However,

   to address the needs of LSPs as = differentiated from PW, the following

   concepts were defined for = [G-ACh]:

 

   o An Associated Channel Header (ACH), = that uses a format similar to

      the PW Control Word, is a = 4-byte header that is prepended to OAM

      = packets.

 

   o A Generic Associated Label (GAL). The = GAL is a reserved MPLS label

      value (13) that indicates that = the packet is an ACH packet and the

      payload follows immediately = after the label stack.

 

3.4.3. MPLS-TP OAM = Toolset

 

   To address the functionality that is = required of the OAM toolset, the

   MPLS WG conducted an analysis of the = existing IETF and ITU-T OAM

   mechanisms and their ability to fulfill = the required functionality.

   The conclusions of this analysis are = documented in [OAM-Analys]. The

   MPLS working group currently plans to = use a mixture of OAM mechanisms

   that are based on various existing = standards, and adapt them to the

   requirements of [MPLS-TP-OAM]. Some of = the main building blocks of

   this solution are based = on:

 

   o Bidirectional Forwarding Detection = ([BFD], [BFD-LSP]) for

      proactive continuity check and = connectivity verification.

 

   o LSP Ping as defined in [LSP-Ping] for = on-demand connectivity

      = verification.

 

   o New protocol packets, using G-ACH, to = address different

  =     functionality.

 

   o Performance measurement protocols = that are based on the

      functionality that is described = in [ITU-T-Y1731].

 

   The following sub-sections describe the = OAM tools defined for MPLS-TP

   as described in = [TP-OAM-FW].

 

3.4.3.1. Continuity Check and Connectivity = Verification

 

   Continuity Check and Connectivity = Verification are presented in

   Section 2.2.5. of this document. =  As presented there, these tools may

   be used either proactively or = on-demand.  When using these tools

   proactively, they are generally used in = tandem.

 

   For MPLS-TP there are two distinct = tools, the proactive tool is

   defined in [TP-CC-CV] while the = on-demand tool is defined in

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 20]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   [OnDemand-CV].Proactively [MPLS-TP-OAM] = states that the function

   should allow the MEPs to monitor the = liveness and connectivity of a

   transport path. In on-demand mode, this = function should support

   monitoring between the MEPs and, in = addition, between a MEP and MIP.

   [TP-OAM-FW] highlights,  when = performing Connectivity Verification,

   the need for the CC-V messages to = include unique identification of

   the MEG that is being monitored and the = MEP that originated the

   message.

 

   The proactive tool [TP-CC-CV] is based = on extensions to BFD (see

   Section 3.2. ) with the additional = limitation that the transmission

   and receiving rates are based on = configuration by the operator.  The

   on-demand tool [OnDemand-CV] is an = adaptation of LSP Ping (see

   Section 3.3. ) for the required = behavior of MPLS-TP.

 

3.4.3.2. Route Tracing

 

   [MPLS-TP-OAM] defines that there is a = need for functionality that

   would allow a path end-point to = identify the intermediate and end-

   points of the path. This function would = be used in on-demand mode.

   Normally, this path will be used for = bidirectional PW, LSP, and

   sections, however, unidirectional paths = may be supported only if a

   return path exists.  The tool for = this is based on the LSP Ping (see

   Section 3.3. ) functionality and is = described in [OnDemand-CV].

 

3.4.3.3. Lock Instruct

 

   The Lock Instruct function [Lock-Loop] = is used to notify a transport

   path end-point of an administrative = need to disable the transport

   path.  This functionality will = generally be used in conjunction with

   some intrusive OAM function, e.g. = Performance measurement, Diagnostic

   testing, to minimize the side-effect on = user data traffic.

 

3.4.3.4. Lock Reporting

 

   Lock Reporting is a function used by an = end-point of a path to report

   to its far-end end-point that a lock = condition has been affected on

   the path.

 

3.4.3.5. Alarm Reporting

 

   Alarm Reporting is a function used by = an intermediate point of a

   path, that becomes aware of a fault on = the path, to report to the

   end-points of the path. [TP-OAM-FW] = states that this may occur as a

   result of a defect condition discovered = at a server sub-layer. This

   generates an Alarm Indication Signal = (AIS) that continues until the

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 21]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   fault is cleared. The consequent action = of this function is detailed

   in = [TP-OAM-FW].

 

3.4.3.6. Remote Defect = Indication

 

   Remote Defect Indication (RDI) is used = proactively by a path end-

   point to report to its peer end-point = that a defect is detected on a

   bidirectional connection between them. = [MPLS-TP-OAM] points out that

   this function may be applied to a = unidirectional LSP only if there a

   return path exists.  [TP-OAM-FW] = points out that this function is

   associated with the proactive CC-V = function.

 

3.4.3.7. Client Failure = Indication

 

   Client Failure Indication (CFI) is = defined in [MPLS-TP-OAM] to allow

   the propagation information from one = edge of the network to the

   other. The information concerns a = defect to a client, in the case

   that the client does not support alarm = notification.

 

3.4.3.8. Packet Loss Measurement = (LM)

 

   Packet Loss Measurement is a function = used to verify the quality of

   the service. This function indicates = the ratio of packets that are

   not delivered out of all packets that = are transmitted by the path

   source.

 

   There are two possible ways of = determining this measurement:

 

   o Using OAM packets, it is possible to = compute the statistics based

      on a series of OAM packets. = This, however, has the disadvantage of

      being artificial, and may not = be representative since part of the

      packet loss may be dependent = upon packet sizes.

 

TOM: Not just packet sizes. Things like = implementation (as I mentioned above with the comment about the accuracy = or truthfulness of the data plane processing of OAM packets). =  Doing very accurate RTT as a simple example, with just IP Pings, = is a tricky thing to make work.  Also, it is important to mention = that the scale in terms of number of packets, number of tests, etc=85 = can and will impact these parameters too.

[TM] Following your comment we rephrased this = sentence.

 

 

 

   o Sending delimiting messages for the = start and end of a measurement

      period during which the source = and sink of the path count the

      packets transmitted and = received. After the end delimiter, the

      ratio would be calculated by = the path OAM entity.

 

3.4.3.9. Packet Delay Measurement = (DM)

 

   Packet Delay Measurement is a function = that is used to measure one-

   way or two-way delay of a packet = transmission between a pair of the

   end-points of a path (PW, LSP, or = Section). Where:

 

 

 

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 22]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   o One-way packet delay is the time = elapsed from the start of

      transmission of the first bit = of the packet by a source node until

      the reception of the last bit = of that packet by the destination

      = node.

 

   o Two-way packet delay is the time = elapsed from the start of

      transmission of the first bit = of the packet by a source node until

      the reception of the last bit = of the loop-backed packet by the

      same source node, when the = loopback is performed at the packet's

      destination = node.

 

   Similarly to the packet loss = measurement this could be performed in

   either of the two ways outlined = above.

 

3.5. PWE3 OAM

 

3.5.1. PWE3 OAM using Virtual Circuit Connectivity = Verification (VCCV)

 

   VCCV, as defined in [VCCV], provides a = means for end-to-end fault

   detection and diagnostics tools to be = extended for PWs (regardless of

   the underlying tunneling technology). = The VCCV switching function

   provides a control channel associated = with each PW (based on the PW

   Associated Channel Header (ACH) which = is defined in [PW-ACH]), and

   allows transmitting the OAM packets = in-band with PW data (using CC

   Type 1: In-band = VCCV).

 

   VCCV currently supports the following = OAM mechanisms: ICMP Ping, LSP

   Ping, and BFD. ICMP and LSP Ping are IP = encapsulated before being

   sent over the PW ACH. BFD for VCCV = [BFD-VCCV] supports two modes of

   encapsulation - either IP/UDP = encapsulated (with IP/UDP header) or

   PW-ACH encapsulated (with no IP/UDP = header) and provides support to

   signal the AC status. The use of the = VCCV control channel provides

   the context, based on the MPLS-PW = label, required to bind and

   bootstrap the BFD session to a = particular pseudo wire (FEC),

   eliminating the need to exchange = Discriminator values.

 

   VCCV consists of two components: (1) = signaled component to

   communicate VCCV capabilities as part = of VC label, and (2) switching

   component to cause the PW payload to be = treated as a control packet.

 

   VCCV is not directly dependent upon the = presence of a control plane.

   The VCCV capability negotiation may be = performed as part of the PW

   signaling when LDP is used. In case of = manual configuration of the

   PW, it is the responsibility of the = operator to set consistent

   options at both = ends.

 

TOM: Might be helpful to note that the static mode = was created specifically to handle the MPLS-TP cases where no control = plane was a requirement. However, new use cases such as pure mobile = backhaul, etc=85 find this functionality useful too.

[TM] Following your comment we added some text to = explain this.

 

 

 

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 23]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

3.5.2. PWE3 OAM using = G-ACh

 

   As mentioned above, VCCV enables OAM = for PWs by using a control

   channel for OAM packets. When PWs are = used in MPLS-TP networks,

   rather than the control channels = defined in VCCV, the G-ACh can be

   used as an alternative control channel. = The usage of the G-ACh for

   PWs is defined in = [PW-G-ACh].

 

3.6. OWAMP and TWAMP

 

3.6.1. Overview

 

   The IPPM working group in the IETF = defines common criteria and

   metrics for measuring performance of IP = traffic ([IPPM-FW]). Some of

   the key RFCs published by this working = group have defined metrics for

   measuring connectivity [IPPM-Con], = delay ([IPPM-1DM], [IPPM-2DM]),

   and packet loss = [IPPM-1LM].

 

   Alternative protocols for performance = measurement are defined, for

   example, in MPLS-TP OAM ([MPLS-LM-DM], = [TP-LM-DM]), and in Ethernet

   OAM = [ITU-T-Y1731].

 

   The IPPM working group has defined not = only metrics for performance

   measurement, but also protocols that = define how the measurement is

   carried out. The One-way Active = Measurement Protocol [OWAMP] and the

   Two-Way Active Measurement Protocol = [TWAMP] define a method and

   protocol for measuring delay and packet = loss in IP networks.

 

   OWAMP [OWAMP] enables measurement of = one-way characteristics of IP

   networks, such as one-way packet loss = and one-way delay.  For its

   proper operation OWAMP requires = accurate time of day setting at its

   end points.

 

   TWAMP [TWAMP] is a similar protocol = that enables measurement of two-

   way (round trip) characteristics. =  TWAMP does not require accurate

   time of day, and, furthermore, allows = the use of a simple session

   reflector, making it an attractive = alternative to OWAMP.

 

   OWAMP and TWAMP use two separate = protocols: a Control plane protocol,

   and a Test plane = protocol.

 

3.6.2. Control and Test = Protocols

 

   OWAMP and TWAMP control protocols run = over TCP, while the test

   protocols run over UDP.  The = purpose of the control protocols is to

   initiate, start, and stop test = sessions, and for OWAMP to fetch

   results.  The test protocols = introduce test packets (which contain

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 24]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   sequence numbers and timestamps) along = the IP path under test

   according to a schedule, and record = statistics of packet arrival.

   Multiple sessions may be simultaneously = defined, each with a session

   identifier, and defining the number of = packets to be sent, the amount

   of padding to be added (and thus the = packet size), the start time,

   and the send schedule (which can be = either a constant time between

   test packets or exponentially = distributed pseudo-random). Statistics

   recorded conform to the relevant IPPM = RFCs.

 

   OWAMP and TWAMP test traffic is = designed with security in mind.  Test

   packets are hard to detect because they = are simply UDP streams

   between negotiated port numbers, with = potentially nothing static in

   the packets.  OWAMP and TWAMP also = include optional authentication

   and encryption for both control and = test packets.

 

3.6.3. OWAMP

 

   OWAMP defines the following logical = roles: Session-Sender, Session-

   Receiver, Server, Control-Client, and = Fetch-Client.  The Session-

   Sender originates test traffic that is = received by the Session-

   Receiver.  The Server configures = and manages the session, as well as

   returning the results.  The = Control-Client initiates requests for

   test sessions, triggers their start, = and may trigger their

   termination.  The Fetch-Client = requests the results of a completed

   session.  Multiple roles may be = combined in a single host - for

   example, one host may play the roles of = Control-Client, Fetch-Client,

   and Session-Sender, and a second = playing the roles of Server and

  =  Session-Receiver.

 

   In a typical OWAMP session the = Control-Client establishes a TCP

   connection to port 861 of the Server, = which responds with a server

   greeting message indicating supported = security/integrity modes. The

   Control-Client responds with the chosen = communications mode and the

   Server accepts the modes.  The = Control-Client then requests and fully

   describes a test session to which the = Server responds with its

   acceptance and supporting information. =  More than one test session

   may be requested with additional = messages.  The Control-Client then

   starts a test session and the Server = acknowledges.  The Session-

   Sender then sends test packets with = pseudorandom padding to the

   Session-Receiver until the session is = complete or until the Control-

   client stops the session.  Once = finished, the Fetch-Client sends a

   fetch request to the server, which = responds with an acknowledgement

   and immediately thereafter the result = data.

 

 

 

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 25]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

3.6.4. TWAMP

 

   TWAMP defines the following logical = roles: session-sender, session-

   reflector, server, and control-client. =  These are similar to the

   OWAMP roles, except that the = Session-Reflector does not collect any

   packet information, and there is no = need for a Fetch-Client.

 

   In a typical TWAMP session the = Control-Client establishes a TCP

   connection to port 862 of the Server, = and mode is negotiated as in

   OWAMP.  The Control-Client then = requests sessions and starts them.

   The Session-Sender sends test packets = with pseudorandom padding to

   the Session-Reflector which returns = them with insertion of

   timestamps.

 

3.7. Summary of OAM = Functions

 

   Table 3 summarizes the OAM functions = that are supported in each of

   the categories that were analyzed in = this section.

 

  =  +-----------+-------+--------+--------+-----------+-------+--------+=

   | Standard =  |Continu|Connecti|Path    |Defect     = |Perform|Other   |

   |           = |ity    |vity    |Discover|Indications|ance   = |Function|

  =  |           |Check  |Verifica|y =       |           |Monitor|s =       |

   |           | =       |tion    |        | =           |ing    |     =    |

  =  +-----------+-------+--------+--------+-----------+-------+--------+=

   |IP Ping =    |       |Echo    |     =    |           |       = |        |

   + --------- + ----- + ------ + ------ + = --------- + ----- + ------ +

   |IP         | =       |        |Tracerou|   =         |       |     =    |

  =  |Traceroute |       |       =  |te      |           | =       |       =  |

   + = --------- + ----- + ------ + ------ + --------- + ----- + ------ = +

   |BFD =        |BFD    |BFD     |   =      |           |     =   |        |

   |           = |Control|Echo    |        |     =       |       |       =  |

   + = --------- + ----- + ------ + ------ + --------- + ----- + ------ = +

   |MPLS OAM =   |       |"Ping"  |"Tracero|     =       |       |       =  |

  =  |(LSP Ping) |       |mode    |ute"   =  |           |       | =        |

   |           | =       |        |mode    | =           |       |   =      |

   + --------- + ----- + ------ + ------ + = --------- + ----- + ------ +

   |MPLS-TP    |CC     = |CV/pro- |Route   |-Alarm     |-LM   =  |-Diagnos|

  =  |OAM        |       |active =  |Tracing | Reporting |-DM    | tic = Tes|

   | =           |       |or on- =  |        |-Client    |     =   | t      |

   |           | =       |demand  |        | = Failure   |       |-Lock   = |

   |   =         |       |     =    |        | Indication|     =   |        |

   |           | =       |        |       =  |-Remote    |       |     =    |

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 26]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   |           | =       |        |       =  | Defect    |       |     =    |

  =  |           |       | =        |        | Indication| =       |       =  |

   + = --------- + ----- + ------ + ------ + --------- + ----- + ------ = +

   |PWE3 OAM =   |BFD    |-BFD    |LSP-Ping|     =       |       |       =  |

   | =           |       |-ICMP   = |        |           | =       |       =  |

   | =           |       | Ping   = |        |           | =       |       =  |

   | =           |       |-LSP-   = |        |           | =       |       =  |

   | =           |       | Ping   = |        |           | =       |       =  |

   + = --------- + ----- + ------ + ------ + --------- + ----- + ------ = +

   |OWAMP = and  |       |        |   =      |           |-Delay | =        |

   |TWAMP      |   =     |        |       =  |           | measur|     =    |

  =  |           |       | =        |        |     =       | ement |       =  |

   | =           |       |   =      |        |       =     |-Packet|       =  |

   | =           |       |   =      |        |       =     | loss  |       =  |

   | =           |       |   =      |        |       =     | measur|       =  |

   | =           |       |   =      |        |       =     | ement |       =  |

  =  +-----------+-------+--------+--------+-----------+-------+--------+=

      =                Table 3 Summary = of OAM Functions

 

4. Security = Considerations

 

   This memo presents an overview of = existing OAM mechanisms, and

   proposes no new OAM mechanisms. = Therefore, this document introduces

   no security considerations. However, = the OAM mechanism reviewed in

   this document can and do present = security issues. The reader is

   encouraged to review the Security = Considerations section of each

   document reference by this = memo.

 

5. IANA Considerations

 

   There are no new IANA considerations = implied by this document.

 

6. Acknowledgments

 

   The authors gratefully acknowledge = Sasha Vainshtein, Carlos

   Pignataro, David Harrington, Dan = Romascanu, Ron Bonica and other

   members of the OPSAWG mailing list for = their helpful comments.

 

   This document was prepared using = 2-Word-v2.0.template.dot.

 

 

 

 

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 27]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

7. References

 

7.1. Normative = References

 

   [LSP-Ping]    Kompella, K., = Swallow, G., "Detecting Multi-Protocol

              =    Label Switched (MPLS) Data Plane Failures", RFC = 4379,

    =              February = 2006.

 

   [MPLS-OAM]    Nadeau, T., = Morrow, M., Swallow, G., Allan, D.,

              =    Matsushima, S., "Operations and Management = (OAM)

    =              Requirements for = Multi-Protocol Label Switched (MPLS)

              =    Networks", RFC 4377, February = 2006.

 

   [MPLS-OAM-FW] Allan, D., Nadeau, T., "A = Framework for Multi-Protocol

              =    Label Switching (MPLS) Operations and = Management

    =              (OAM)", RFC 4378, = February 2006.

 

   [OAM-Label]   Ohta, H., = "Assignment of the 'OAM Alert Label' for

              =    Multiprotocol Label Switching Architecture = (MPLS)

    =              Operation and = Maintenance (OAM) Functions", RFC 3429,

              =    November 2002.

 

   [MPLS-TP-OAM] Vigoureux, M., Ward, D., = Betts, M., "Requirements for

              =    OAM in MPLS Transport Networks", RFC 5860, May = 2010.

 

   [G-ACh]       Bocci, M., = Vigoureux, M., Bryant, S., "MPLS Generic

              =    Associated Channel", RFC 5586, June = 2009.

 

   [VCCV]       =  Nadeau, T., Pignataro, C., "Pseudowire Virtual = Circuit

    =              Connectivity = Verification (VCCV): A Control Channel

              =    for Pseudowires", RFC 5085, December = 2007.

 

   [PW-ACH]      Bryant, = S., Swallow, G., Martini, L., McPherson, D.,

              =    "Pseudowire Emulation Edge-to-Edge (PWE3) Control = Word

    =              for Use over an MPLS = PSN", RFC 4385, February 2006.

 

   [ICMPv4]      Postel, = J., "Internet Control Message Protocol", STD = 5,

      =            RFC 792, September = 1981.

 

   [ICMPv6]      Conta, A., = Deering, S., and M. Gupta, "Internet Control

              =    Message Protocol (ICMPv6) for the Internet = Protocol

    =              Version 6 (IPv6) = Specification", RFC 4443, March 2006.

 

   [MPLS-P2MP]   Yasukawa, S., = Farrel, A., King, D., Nadeau, T.,

              =    "Operations and Management (OAM) Requirements = for

      =            Point-to-Multipoint MPLS = Networks", RFC 4687,

              =    September 2006.

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 28]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   [ICMP-Ext]    Bonica, R., = Gan, D., Tappan, D., Pignataro, C., "ICMP

              =    Extensions for Multiprotocol Label Switching", = RFC

      =            4950, August = 2007.

 

   [ICMP-MP]     Bonica, R., = Gan, D., Tappan, D., Pignataro, C.,

              =    "Extended ICMP to Support Multi-Part Messages", = RFC

      =            4884, April = 2007.

 

   [ICMP-Int]    Atlas, A., = Bonica, R., Pignataro, C., Shen, N., Rivers,

              =    JR., "Extending ICMP for Interface and = Next-Hop

    =              Identification", RFC = 5837, April 2010.

 

   [TCPIP-Tools] Kessler, G., Shepard, S., = "A Primer On Internet and

              =    TCP/IP Tools and Utilities", RFC 2151, June = 1997.

 

   [NetTools]    Stine, R., "FYI = on a Network Management Tool Catalog:

              =    Tools for Monitoring and Debugging TCP/IP = Internets

    =              and Interconnected = Devices", RFC 1147, April 1990.

 

   [IPPM-FW]     Paxson, V., = Almes, G., Mahdavi, J., and Mathis, M.,

              =    "Framework for IP Performance Metrics", RFC 2330, = May

      =           =  1998.

 

   [IPPM-Con]    Mahdavi, J., = Paxson, V., "IPPM Metrics for Measuring

              =    Connectivity", RFC 2678, September = 1999.

 

   [IPPM-1DM]    Almes, G., = Kalidindi, S., Zekauskas, M., "A One-way

              =    Delay Metric for IPPM", RFC 2679, September = 1999.

 

   [IPPM-1LM]    Almes, G., = Kalidindi, S., Zekauskas, M., "A One-way

              =    Packet Loss Metric for IPPM", RFC 2680, = September

    =             =  1999.

 

   [IPPM-2DM]    Almes, G., = Kalidindi, S., Zekauskas, M., "A Round-trip

              =    Delay Metric for IPPM", RFC 2681, September = 1999.

 

   [OWAMP]       Shalunov, = S., Teitelbaum, B., Karp, A., Boote, J., and

              =    Zekauskas, M., "A One-way Active Measurement = Protocol

    =              (OWAMP)", RFC 4656, = September 2006.

 

   [TWAMP]       Hedayat, = K., Krzanowski, R., Morton, A., Yum, K., and

              =    Babiarz, J., "A Two-Way Active Measurement = Protocol

    =              (TWAMP)", RFC 5357, = October 2008.

 

   [BFD]         Katz, = D., Ward, D., "Bidirectional Forwarding = Detection

    =              (BFD)", RFC 5880, June = 2010.

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 29]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   [BFD-IP]      Katz, D., = Ward, D., "Bidirectional Forwarding = Detection

    =              (BFD) for IPv4 and IPv6 = (Single Hop)", RFC 5881, June

              =    2010.

 

   [BFD-Gen]     Katz, D., Ward, = D., "Generic Application of

              =    Bidirectional Forwarding Detection (BFD)", RFC = 5882,

    =              June = 2010.

 

   [BFD-Multi]   Katz, D., Ward, D., = "Bidirectional Forwarding Detection

              =    (BFD) for Multihop Paths", RFC 5883, June = 2010.

 

   [BFD-LSP]     Aggarwal, R., = Kompella, K., Nadeau, T., and Swallow,

              =    G., "Bidirectional Forwarding Detection (BFD) for = MPLS

    =              Label Switched Paths = (LSPs)", RFC 5884, June 2010.

 

   [BFD-VCCV]    Nadeau, T., = Pignataro, C., "Bidirectional Forwarding

              =    Detection (BFD) for the Pseudowire Virtual = Circuit

    =              Connectivity = Verification (VCCV)", RFC 5885, June

              =    2010.

 

   [TP-OAM-FW]   Busi, I., Allan, D., = "Operations, Administration and

              =    Maintenance Framework for MPLS-based = Transport

    =              Networks ", RFC 6371, = September 2011.

 

   [TP-CC-CV]    Allan, D., = Swallow, G., Drake, J., "Proactive

              =    Connectivity Verification, Continuity Check and = Remote

    =              Defect indication for = MPLS Transport Profile", RFC

              =    6428, November 2011.

 

   [OnDemand-CV] Gray, E., Bahadur, N., = Boutros, S., Aggarwal, R. "MPLS

              =    On-Demand Connectivity Verification and = Route

    =              Tracing", RFC 6426, = November 2011.

 

   [MPLS-LM-DM]  Frost, D., Bryant, = S., "Packet Loss and Delay

              =    Measurement for MPLS Networks", RFC 6374, = September

    =             =  2011.

 

   [TP-LM-DM]    Frost, D., = Bryant, S., "A Packet Loss and Delay

              =    Measurement Profile for MPLS-Based = Transport

    =              Networks", RFC 6375, = September 2011.

 

   [TP-Fault]    Swallow, G., = Fulignoli, A., Vigoureux, M., Boutros, S.,

              =    "MPLS Fault Management Operations, Administration, = and

      =            Maintenance (OAM)", RFC 6427, = November 2011.

 

 

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 30]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   [Lock-Loop]   Boutros, S., = Sivabalan, S., Aggarwal, R., Vigoureux,

              =    M., Dai, X., "MPLS Transport Profile Lock Instruct = and

      =            Loopback Functions", RFC 6435, = November 2011.

 

   [ITU-T-CT]    Betts, M., = "Allocation of a Generic Associated Channel

              =    Type for ITU-T MPLS Transport Profile = Operation,

    =              Maintenance, and = Administration (MPLS-TP OAM)", RFC

              =    6671, November 2012.

 

   [PW-Map]      M. = Aissaoui, P. Busschbach, L. Martini, M. Morrow, = T.

      =            Nadeau, "Pseudowire (PW) = Operations, Administration,

              =    and Maintenance (OAM) Message Mapping", RFC 6310, = July

    =             =  2011.

 

   [PW-G-ACh]    Li, H., = Martini, L., He, J., Huang, F., "Using the

              =    Generic Associated Channel Label for Pseudowire in = the

      =            MPLS Transport Profile = (MPLS-TP)", RFC 6423, November

              =    2011.

 

7.2. Informative = References

 

   [OAM-Def]     Andersson, L., = Van Helvoort, H., Bonica, R., Romascanu,

              =    D., Mansfield, S., "Guidelines for the use of the = OAM

      =            acronym in the IETF ", RFC = 6291, June 2011.

 

   [OAM-Analys]  Sprecher, N., Fang, = L., "An Overview of the OAM Tool

              =    Set for  MPLS based Transport Networks", RFC = 6669,

    =              July = 2012.

 

   [TP-Term]     Van Helvoort, = H., Andersson, L., Sprecher, N., "A

              =    Thesaurus for the Terminology used in = Multiprotocol

  =                Label Switching = Transport Profile (MPLS-TP)

              =    drafts/RFCs and ITU-T's Transport = Network

    =              Recommendations", = work-in-progress, draft-ietf-mpls-

              =    tp-rosetta-stone, July 2012.

 

   [IEEE802.1ag] IEEE 802.1Q, "IEEE = Standard for Local and metropolitan

              =    area networks - Media Access Control (MAC) Bridges = and

      =            Virtual Bridged Local Area = Networks", October 2012.

 

   [ITU-T-Y1731] ITU-T Recommendation = G.8013/Y.1731, "OAM Functions and

              =    Mechanisms for Ethernet-based Networks", July = 2011.

 

   [ITU-T-Y1711] ITU-T Recommendation = Y.1711, "Operation & Maintenance

              =    mechanism for MPLS networks", February = 2004.

 

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 31]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   [IEEE802.3ah] IEEE 802.3, "IEEE = Standard for Information technology -

              =    Local and metropolitan area networks - Carrier = sense

    =              multiple access with = collision detection (CSMA/CD)

              =    access method and physical layer = specifications",

  =                clause 57, = December 2008.

 

   [ITU-T-G.806] ITU-T Recommendation = G.806, "Characteristics of

              =    transport equipment - Description methodology = and

      =            generic functionality", January = 2009.

 

   [ITU-G8113.2] ITU-T Recommendation = G.8113.2/Y.1372.2, "Operations,

              =    administration and maintenance mechanisms for = MPLS-TP

    =              networks using the tools = defined for MPLS", November

              =    2012.

 

   [ITU-G8113.1] ITU-T Recommendation = G.8113.1/Y.1372.1, "Operations,

              =    Administration and Maintenance mechanism for = MPLS-TP

    =              in Packet Transport = Network (PTN)", November 2012.

 

 

 

Authors' Addresses

 

   Tal Mizrahi

   Marvell

   6 Hamada = St.

  =  Yokneam, 20692

   Israel

 

   Email: talmi@marvell.com

 

 

   Nurit = Sprecher

  =  Nokia Siemens Networks

   3 Hanagar St. Neve Ne'eman = B

   Hod = Hasharon,   45241

   Israel

 

 

 

   Elisa = Bellagamba

  =  Ericsson

  =  6 Farogatan St.

   Stockholm,   164 = 40

  =  Sweden

 

 

 

Mizrahi, et al.         Expires = July 9, 2013                 = [Page 32]

Internet-Draft =       Overview of OAM Mechanisms       =     January 2013

 

 

   Phone: +46 = 761440785

 

 

   Yaacov = Weingarten

  =  34 Hagefen St.

   Karnei Shomron,   = 4485500

  =  Israel

 

   Email: wyaacov@gmail.com

 

 

 

 

 

 

 

 

 

draft-ietf-opsawg-oam-overview authors,

Here = is my feedback on this document.

1.
Is this document in line = with http://too= ls.ietf.org/html/draft-ietf-trill-oam-req-04?
* For example, the = following definitions could be reused.

   =
Fault: The term Fault refers to an inability to perform a =
required
   action, e.g., an unsuccessful =
attempt to deliver a =
packet.
 
   =
Defect: The term Defect refers to an interruption in the =
normal
   operation, such that over a =
period of time no packets are =
delivered
   =
successfully.
 
  =
; Failure: The term Failure refers to the termination of the =
required
   function over a longer period =
of time. Persistence of a defect for a
   =
period of time is interpreted as a =
failure.
 
* For example, =
on the basic abstract =

Abstract
 
   Operations, Administration, and Maintenance (OAM) is =
a general term
   that refers to a =
toolset that can be used for fault detection =
and
   isolation, and for performance =
measurement. OAM mechanisms have been
   =
defined for various layers in the protocol stack, and are used with =
a
   variety of =
protocols.
 
Abstract =
(draft-ietf-trill-oam-req-04)
 
=

   OAM (Operations, Administration and Maintenance) is a =
general term
   used to identify =
functions and toolsets to troubleshoot and =
monitor
   networks. This document =
presents, OAM Requirements applicable =
to
   TRILL. =

 
So, as an example: =
does OAM include function? 
I advice to review =
draft-ietf-trill-oam-req-04
 
2. 
draft-ietf-trill-oam is not mentioned, while =
the abstract mentions:
   This document =
presents an overview of the OAM mechanisms that =
have
   been defined and are currently =
being defined by the IETF.
Search for OAM in the =
current draft names (https://datatracker.ietf.org/),=
 and you will find many references.
Ok, I see later =
on:       =

   This document focuses on =
IETF
   documents that have been =
published as RFCs, while other ongoing =
OAM-
   related work is outside the =
scope.
Ok, fine then: we don't need a reference to =
all the drafts. 
However, draft-ietf-trill-oam is =
closed to be a RFC, and should be =
mentioned.
 
 
3.
Section =
1
   The term OAM in this document refers =
to Operations, Administration
   and =
Maintenance [OAM-Def], focusing on the forwarding plane of =
OAM.
What does it mean "focusing on the forwarding =
plane of OAM"?
Do you take a subset of the =
definition for this document?
Btw, I don't see a =
definition in the terminology section.
In section =
2.2.3
   A Maintenance Point (MP) is a =
functional entity that is defined at a
   =
node in the network, and either initiates or reacts to OAM =
messages.
Which plane is =
MP?
 
4.
Section 1, Introduction
"Hence, management =
aspects are outside the scope of this document."
I =
don't understand which management aspects we speak about =
here.

5.
Clarifying question = regarding 1.2
If speak about OWAMP or TWAMP 'synthetic traffic), is = that data plane, control plane, or management plane?
Note that I = found later on in the draft:

   OWAMP and =
TWAMP use two separate protocols: a Control plane =
protocol,
   and a Test plane =
protocol.

Interestingly enough, = after reading the document, I reviewed http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballo= t/, and saw the same feedback from Stewart = Bryant:

Provide a clear view of OAM functionality and =
its relationship
to various =93planes=94 of =
networking (data plane, control plane,
management =
plane). In particular, the importance =
of
fate-sharing of OAM and user traffic flows in =
packet networks
should be =
explained.

6.

I =
see a multiplication of "plane" terms in the IETF document, and in this =
document in particular.
I could find: forwarding =
plane, management plane, control plane, data plane, user plane, and test =
plane.
Way too many.
Please be =
consistent

7.

   Table 1 =
summarizes the IETF OAM related RFCs discussed in =
this
   =
document.
 
   =
Table 2 summarizes the OAM standards mentioned in this document. =

 
You need to change the =
Table 2 description. Do you want to say something along the lines =
of:
   Table 2 summarizes the OAM =
standards specified by other Standard Development Organization =

   (SDO) than the IETF, along with =
IETF references where =
applicable.
 
 
8.
Section =
2.2.1
   For a formal definition of each =
term, refer to the references at the end =
of
   this =
document.
Without a reference to a specific RFC, =
this is the type of statement which is not useful: you have 5 pages of =
references.
You position this document as "An =
Overview of Operations, Administration, and Maintenance (OAM) =
Mechanisms", but you tell the reader: "if you want to know about the =
terms,
just read first all =
references!"
 
9.
You specify some terms and some OAM categories, =

   2.2.2. OAM Maintenance Entities .......................... =
13
       =
  2.2.3. OAM Maintenance Points ............................ =
14
       =
  2.2.4. Proactive and On-demand activation ................ =
15
       =
  2.2.5. Connectivity Verification and Continuity Checks ... =
15
       =
  2.2.6. Failures .......................................... =
15
... but you don't use them in the =
section 3
 
Just one =
example with section =
3.2.2
-
   o Demand =
mode: in this mode, BFD control packets are sent =
on-demand.
      Upon =
need, a system initiates a series of BFD control packets =
to
      verify the =
liveness of the session
Instead of liveness, you =
have defined Connectivity Verification and Continuity Checks in section =
2.2.5
- OLD:
   Each =
of the end-points of the monitored path maintains its =
own
   session =
identification
NEW:
  =
 Each of the MEP maintains its own session =
identification
OR NEW (actually I don't =
know)
   Each of the MP maintains its own =
session identification
- =
OLD
   A BFD echo packet is sent to a =
peer system
Peer system =3D MEP, MP, or something =
else?
- etc... =

 
10. =

This document is composed of a list of OAM content =
and references, but I'm really missing the document "scope and target =
audience".
When we did RFC 6632, which is the =
companion document, we had http://tools.ietf.=
org/html/rfc6632#section-1.1
 
   The target audience of the document is, on the one =
hand, IETF working
   groups, which aim =
to select appropriate standard management =
protocols
   and data models to address =
their needs concerning network =
management.
   On the other hand, the =
document can be used as an overview =
and
   guideline by non-IETF Standards =
Development Organizations (SDOs)
   =
planning to use IETF management technologies and data models for =
the
   realization of management =
applications.  The document can also =
be
   used to initiate a discussion =
between the bodies with the goal to
   =
gather new requirements and to detect possible gaps.  Finally, =
this
   document is directed to all =
interested parties that seek to get an
   =
overview of the current set of the IETF network management =
protocols
   such as network =
administrators or newcomers to the =
IETF.
 
You should have =
something =
similar.
 
 
11.
Section 3.6.1, put the paragraph 2 =
at the end of the section. The "alternative" in the following sentence =
would then make sense
   Alternative =
protocols for performance measurement are defined, =
for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in =
Ethernet
   OAM [ITU-T-Y1731].
 
 
My conclusions: this document still =
needs some =
work
 
Regards, =
Benoit
 
The IESG has =
received a request from the Operations and Management =
Area
Working Group WG (opsawg) to consider the =
following document:
- 'An Overview of Operations, =
Administration, and Maintenance (OAM)
   =
Mechanisms'
  =
<draft-ietf-opsawg-oam-overview-08.txt> as Informational =
RFC
 
The IESG plans to =
make a decision in the next few weeks, and =
solicits
final comments on this action. Please send =
substantive comments to the
ietf@ietf.org mailing lists by =
2013-01-25. Exceptionally, comments may be
sent to =
iesg@ietf.org instead. In either =
case, please retain the
beginning of the Subject =
line to allow automated =
sorting.
 
Abstract
 
 
&nbs=
p;  Operations, Administration, and Maintenance (OAM) is a general =
term
   that refers to a toolset that can =
be used for fault detection and
   =
isolation, and for performance measurement. OAM mechanisms have =
been
   defined for various layers in the =
protocol stack, and are used with a
   =
variety of =
protocols.
 
   =
This document presents an overview of the OAM mechanisms that =
have
   been defined and are currently =
being defined by the =
IETF.
 
 
 
 
The =
file can be obtained via
h=
ttp://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/
 
IESG discussion can be tracked =
via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballo=
t/
 
 <=
/pre>
No IPR declarations have been submitted directly on this =
I-D.
 
 
 

 

 

 


= --Apple-Mail=_DCB4A4FF-5CD7-4373-98F2-EE12D7699596-- --Apple-Mail=_FFD6B328-041F-4033-8DCE-C5818D85FA75 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS587OAAoJEPcO+I7eiUJZT20QAI0R9eB15G16UxoZe4P4ycmE mV2KBf2FNLzD+uXV/dAiGQz1ican7mrg8Fo3fCj7+NC7hVvHXQnVO6aA67q5OzcH V+FUSxdKmZ/O3tIZZNUYey6ymEzImnWKXGa1ag9A1ic4JwQxNz09Bu9ssaK+DQMq u/TRC9zwEJcD3HMf7o+1gUgGaEffC8uBmaUJhBJb/JZ8QSOgQ4IASNEhm4i+YM2H 2bQOvQqQtWiTK+z+lzW9LdQKkNS7D1HNbT1AwLhdBMFqP9eS7qiBPs5i/+m1MFRB JlVZovlqTjBtrYuOMUg4PHu/JnZwMA3UzsB5md/IzgQoqybNdbi7rkKK2X+HTTyL GHZS3rNhWtDH420IXxvH828yGO+7lxUSGvL9uuYSN3N5QnNpXDzX0kEdQKoOeVl/ PXCARwK1sTh9ZMQEUuoTfNhT3EmSf2H0Q4dM8OI18rSfVMMjd+H9NIdLgUTKnfgd sjb2gFrnAl9FLW/vM7uRJge4sTZlj3/oNlOnxMMSQ5KNET0/6nQ68/4GBizGwVKO N1qFILR7/2aro30/pFYpwXMbUpD1rwNb/nak8AnFHFNgryzgZ44oOktJbBMMN+Rg sbutxi7fiZ5fKwQk3qJBERjPmWT4HjSZ/ovAOL7vh/7JVboqkS0M7ZiTTeJEE+U/ bCRNgMI08wLjOATvenE7 =CLjJ -----END PGP SIGNATURE----- --Apple-Mail=_FFD6B328-041F-4033-8DCE-C5818D85FA75-- From brian.e.carpenter@gmail.com Tue Jan 28 16:04:08 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4241A03E7 for ; Tue, 28 Jan 2014 16:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmoRoVKp-XoC for ; Tue, 28 Jan 2014 16:04:06 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8373C1A03CA for ; Tue, 28 Jan 2014 16:04:06 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id rd3so1040818pab.2 for ; Tue, 28 Jan 2014 16:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=8x2EmEBqy2VKpAZUZfWzOp+aNIBEJGV0vo3kW7DYr8A=; b=jgV7aeJSVjcDBh7BoFb3e46jDGk0ntC3bbTRPLj3I0MzkANHUPAuUdMjHhFYsqK4e+ 4M5/jzQX2dWfQNf8MHvD8AEslpti7fYzVf6vQm3mSHeDsnS039IEw+T90BY4cAd3+6ph EmzO+Ke0UDkS40jUA/79abvwRPUZTRaCY32t1FUM5gKg+0yW0hjMHGeVRTWkXU6zL5e6 /FrJ7c+uoFOxQcQg545FQJ4m0Lf12WZ2ePSh2a4svfzQc0126f0BcpPoGs/lB4hBXXyL jKFrldT/4wDrUUIUIYtz+FTt6R4g0O1TFw/eo81hrxaPTgi8ou+7wIhhv3Sn6ij8/QXT tbQA== X-Received: by 10.68.162.66 with SMTP id xy2mr4617689pbb.46.1390953844024; Tue, 28 Jan 2014 16:04:04 -0800 (PST) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id fk4sm2247323pab.23.2014.01.28.16.04.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 16:04:03 -0800 (PST) Message-ID: <52E84575.3090408@gmail.com> Date: Wed, 29 Jan 2014 13:04:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Negotiation replacing configuration X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 00:04:08 -0000 Hi, I'm a bit surprised at the silence on this. After all, we are suggesting a fairly radical change of approach: from centrally-driven configuration of devices to peer negotiation between devices. In this WG we'd like to get feedback on the problem statement based on real experience, since the NMRG discussion is more likely to be theoretical. Also, is our summary of existing protocols accurate? Brian -------- Original Message -------- Subject: I-D Action: draft-jiang-config-negotiation-ps-02.txt Date: Sat, 18 Jan 2014 11:23:25 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Configuration Negotiation Problem Statement and Requirements Authors : Sheng Jiang Yuanbin Yin Brian Carpenter Filename : draft-jiang-config-negotiation-ps-02.txt Pages : 14 Date : 2014-01-18 Abstract: This document describes a problem statement and general requirements for distributed autonomous configuration of multiple aspects of networks, in particular carrier networks. The basic model is that network elements need to negotiate configuration settings with each other to meet overall goals. The document describes a generic negotiation behavior model. The document also reviews whether existing management and configuration protocols may be suitable for autonomic networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-ps/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-jiang-config-negotiation-ps-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -- Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182 From ghanwani@gmail.com Thu Jan 30 19:18:48 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F901A0527 for ; Thu, 30 Jan 2014 19:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9Z-aMAs2gxI for ; Thu, 30 Jan 2014 19:18:46 -0800 (PST) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 731191A0526 for ; Thu, 30 Jan 2014 19:18:46 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id 11so2633405vbe.10 for ; Thu, 30 Jan 2014 19:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BxKXC4zuF+mARippwEEewj12eldE7BChpOBilIzaZvI=; b=LoHryiJWxKzVzj5kzGpCKBTBkr2OCT+MOSzgEKnJC5TAIfXsqosQbaRiyNIWx8veQd sM2dqMhj9SWtUdtMo4eQpVqmdcHhwtuZlsXSKQoeSIpfivxMLqYkMMfMzNRAJ3/zPI/r dsUFrafVKENz2qbmkKx09Glbfr0vFxrP8FwNTEvAtWkDs1MLlPx0yGUgF1vms1SNAg25 q9wPJmdAogcSRSCQcebhiIhzznYEivnYoZkHUMCuRXlbhXRYJ6O5XiG4O0UAKbGxYP4F LyxsekuoEfLdl8sW78K0nCx91Qr8iYX4FBHMeXbjUkCxJ/7aGGUVLoznI3IoNF4Aqlcj GQTA== MIME-Version: 1.0 X-Received: by 10.221.29.196 with SMTP id rz4mr51438vcb.8.1391138322718; Thu, 30 Jan 2014 19:18:42 -0800 (PST) Sender: ghanwani@gmail.com Received: by 10.58.244.2 with HTTP; Thu, 30 Jan 2014 19:18:42 -0800 (PST) In-Reply-To: <52E84575.3090408@gmail.com> References: <52E84575.3090408@gmail.com> Date: Thu, 30 Jan 2014 19:18:42 -0800 X-Google-Sender-Auth: 2KwT2VwDHXZQq388W6CSMc8RoCc Message-ID: From: Anoop Ghanwani To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1133a1c08f24e704f13ba19f Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Negotiation replacing configuration X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 03:18:48 -0000 --001a1133a1c08f24e704f13ba19f Content-Type: text/plain; charset=ISO-8859-1 Brian, Many protocols already do some type of negotiation but it is based on capabilities and local/remote configuration rather than operational state -- at the link layer 802.3x and DCBX come to mind, with routing protocols operational parameters such as the hello timer come to mind, or even with TCP things like ECN and SACK are negotiated. But that is a one-off negotiation at startup. The draft seems to want to take this kind of negotiation one step further. It looks like an interesting concept. I worry a bit about the complexity. This also seems to be moving in the opposite direction of a centralized SDN controller making global decisions and implementing them (just an observation, not a judgement about whether it's a good or bad thing). It would help to see a detailed example of how this would actually work for a sample network/application for folks to get a feel for the complexity. Anoop On Tue, Jan 28, 2014 at 4:04 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > I'm a bit surprised at the silence on this. After all, we > are suggesting a fairly radical change of approach: from > centrally-driven configuration of devices to peer negotiation > between devices. In this WG we'd like to get feedback on > the problem statement based on real experience, since the > NMRG discussion is more likely to be theoretical. > Also, is our summary of existing protocols accurate? > > Brian > > -------- Original Message -------- > Subject: I-D Action: draft-jiang-config-negotiation-ps-02.txt > Date: Sat, 18 Jan 2014 11:23:25 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Network Configuration Negotiation Problem > Statement and Requirements > Authors : Sheng Jiang > Yuanbin Yin > Brian Carpenter > Filename : draft-jiang-config-negotiation-ps-02.txt > Pages : 14 > Date : 2014-01-18 > > Abstract: > This document describes a problem statement and general requirements > for distributed autonomous configuration of multiple aspects of > networks, in particular carrier networks. The basic model is that > network elements need to negotiate configuration settings with each > other to meet overall goals. The document describes a generic > negotiation behavior model. The document also reviews whether > existing management and configuration protocols may be suitable for > autonomic networks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-ps/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-jiang-config-negotiation-ps-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > -- > Regards > Brian Carpenter > http://orcid.org/0000-0001-7924-6182 > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a1133a1c08f24e704f13ba19f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Brian,

Many protocols already do some t= ype of negotiation but it is based on capabilities and local/remote configu= ration rather than operational state -- at the link layer 802.3x and DCBX c= ome to mind, with routing protocols operational parameters such as the hell= o timer come to mind, or even with TCP things like ECN and SACK are negotia= ted. =A0But that is a one-off negotiation at startup.

The draft seems to want to take this kind of negotiatio= n one step further. =A0It looks like an interesting concept. =A0I worry a b= it about the complexity. =A0This also seems to be moving in the opposite di= rection of a centralized SDN controller making global decisions and impleme= nting them (just an observation, not a judgement about whether it's a g= ood or bad thing). =A0It would help to see a detailed example of how this w= ould actually work for a sample network/application for folks to get a feel= for the complexity.

Anoop


On Tue, Jan 28, 2014 at 4:04 PM, Brian E Carpenter = <brian.e.carpenter@gmail.com> wrote:
Hi,

I'm a bit surprised at the silence on this. After all, we
are suggesting a fairly radical change of approach: from
centrally-driven configuration of devices to peer negotiation
between devices. In this WG we'd like to get feedback on
the problem statement based on real experience, since the
NMRG discussion is more likely to be theoretical.
Also, is our summary of existing protocols accurate?

=A0 =A0 Brian

-------- Original Message --------
Subject: I-D Action: draft-jiang-config-negotiation-ps-02.txt
Date: Sat, 18 Jan 2014 11:23:25 -0800
From: internet-drafts@ietf.org<= /a>
Reply-To: internet-drafts@ietf.= org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Network Configuration Negotiati= on Problem Statement and Requirements
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Sheng Jiang
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yuanbin Yin
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Brian Carpenter
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-jiang-config-negotiation-ps= -02.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 14
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-18

Abstract:
=A0 =A0This document describes a problem statement and general requirements=
=A0 =A0for distributed autonomous configuration of multiple aspects of
=A0 =A0networks, in particular carrier networks. =A0The basic model is that=
=A0 =A0network elements need to negotiate configuration settings with each<= br> =A0 =A0other to meet overall goals. =A0The document describes a generic
=A0 =A0negotiation behavior model. =A0The document also reviews whether
=A0 =A0existing management and configuration protocols may be suitable for<= br> =A0 =A0autonomic networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-jiang-config-= negotiation-ps/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-jiang-config-negotiatio= n-ps-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-c= onfig-negotiation-ps-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--
Regards
=A0 =A0Brian Carpenter
=A0 =A0h= ttp://orcid.org/0000-0001-7924-6182



_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--001a1133a1c08f24e704f13ba19f-- From warren@kumari.net Fri Jan 31 13:23:06 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A081A03FE for ; Fri, 31 Jan 2014 13:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL6h8ax1wzUm for ; Fri, 31 Jan 2014 13:23:05 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0A59C1A03F5 for ; Fri, 31 Jan 2014 13:23:03 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id y10so9854096wgg.20 for ; Fri, 31 Jan 2014 13:22:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=PKrX+3uibaxL/rBZi7KeUmvx1vwJ/kVdgFehi0qA6cQ=; b=ALKKj5cDXeb9frNPPb8lfiJXz7zwNJpRfrU8PA5OpejBFRvBdUv8mJeAmZeEvfrp+k T3qTOLNR34aW+uRMT37VHRX3hBenUEgIVZOzXbYT2vqQkxiapxApt2qN/bVX/5u7rVKT iItJBvlmtXQi1Ij/nEz9COiwg8V19kxHooRTccTowQ2PRVfKUo5XftLuWVH4CdXGP5OM Hy6vSnHaGTP7NVNt7X7Y6xT5Lak2Qk3NWjAmtYv8MQv/ShaEKIORluaFRKeVZc5og2ea tZzDnzevFp3fSvcVxCTpqyiJHEHPlj8WOddgAteV2OjG54tHDiFMTR08e1IGRPTUwrjM aizA== X-Gm-Message-State: ALoCoQlSpqAUnviOPIvpvSw53eqBwe/CDmM5l9yCAfPQXf8avK/69t8ZVE+eAAr1p9YhnebZSQsN MIME-Version: 1.0 X-Received: by 10.194.86.130 with SMTP id p2mr87517wjz.88.1391203379684; Fri, 31 Jan 2014 13:22:59 -0800 (PST) Received: by 10.194.54.167 with HTTP; Fri, 31 Jan 2014 13:22:59 -0800 (PST) X-Originating-IP: [98.244.98.35] Date: Fri, 31 Jan 2014 16:22:59 -0500 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [OPSAWG] Call for OpsAWG agenda items. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 21:23:07 -0000 Hi all, The London meeting is fast approaching, and we are organizing the agenda. If you'd like a slot, please let us know a: what you want to discuss and b: amount of time you need. A pointer to on-list discussions on the topic would not hurt either! A reminder: In order to get agenda time, you need to have had some on-list discussions about the subject. Face to face meeting time is best used for discussing and closing issues, not introducing new work, etc. If we have an abundance of free time we might make some exceptions, but don't count on this, get your on-list discussions going now... Reminder: 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. Thank you, W From brian.e.carpenter@gmail.com Fri Jan 31 14:14:08 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22A81A1F7B for ; Fri, 31 Jan 2014 14:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS3z6wvb7q4H for ; Fri, 31 Jan 2014 14:14:04 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 874D71A1F64 for ; Fri, 31 Jan 2014 14:14:04 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kp14so4916999pab.6 for ; Fri, 31 Jan 2014 14:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZYcoQGze2zy9pK7S6OdpCV3jo5pvvwbhPlo7T+8QqP0=; b=v0Ret5noIAjxRD4yo1/5etALtX9vjBeM/kTQy/ICkuBEotbCAs3SYTmP/jWH64I4iy U4gok4nfCyVaR6ElYQrJzdqcz86PWqjVH4IIQUNq+OVYN4SHiDlonlVdRcIHwz3/hLBM VmGPIH/jUu1iK3qAVbuJjijKFzQl6OvJmN7VzzauDLs2RImphxPxt6E+iYOq5r48ifer EFByWjIC+WTH9hqYbEz52oaDD5plMSdhZHhgYG+cFj3lb5fQ69dpQpgDrjBk0R3YregW VCac05dcYzN/7WPeB8baOX3UWz6y4D8YShGmLR3AB9eDPXfOGCQz6iy8nri1py4Puila LNwQ== X-Received: by 10.66.150.69 with SMTP id ug5mr23191368pab.55.1391206440840; Fri, 31 Jan 2014 14:14:00 -0800 (PST) Received: from [192.168.178.23] (75.199.69.111.dynamic.snap.net.nz. [111.69.199.75]) by mx.google.com with ESMTPSA id vx10sm76822058pac.17.2014.01.31.14.13.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 14:14:00 -0800 (PST) Message-ID: <52EC2030.6090707@gmail.com> Date: Sat, 01 Feb 2014 11:14:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Anoop Ghanwani References: <52E84575.3090408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , draft-jiang-config-negotiation-ps@tools.ietf.org Subject: Re: [OPSAWG] Negotiation replacing configuration X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 22:14:08 -0000 Hi Anoop, thanks for the comments. Answers in line. On 31/01/2014 16:18, Anoop Ghanwani wrote: > Brian, > > Many protocols already do some type of negotiation but it is based on > capabilities and local/remote configuration rather than operational state > -- at the link layer 802.3x and DCBX come to mind, with routing protocols > operational parameters such as the hello timer come to mind, or even with > TCP things like ECN and SACK are negotiated. But that is a one-off > negotiation at startup. Yes, and we'd like more examples of existing negotiations. > The draft seems to want to take this kind of negotiation one step further. > It looks like an interesting concept. I worry a bit about the complexity. Well, our hope is that the protocol itself would be rather simple. But like "Simple" Network Management Protocol, the solutions constructed with the protocol would be rather complex. The point is that humans wouldn't have to deal with the complexity. > This also seems to be moving in the opposite direction of a centralized > SDN controller making global decisions and implementing them (just an > observation, not a judgement about whether it's a good or bad thing). Absolutely correct. It has been pointed out that SDN controllers don't have to be literally central and global, but if you have multiple controllers you'd need some kind of arbitration between them; in our minds that would be an application of generic negotiation, using negotiation objectives that mean something to an SDN controller. > It > would help to see a detailed example of how this would actually work for a > sample network/application for folks to get a feel for the complexity. Agreed. Working out some detailed use cases is necessary, but it's hard to do with assuming something about the actual protocol We do have a draft about the protocol solution too, but it seems better to start by discussing the problem. Regards Brian > Anoop > > > On Tue, Jan 28, 2014 at 4:04 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Hi, >> >> I'm a bit surprised at the silence on this. After all, we >> are suggesting a fairly radical change of approach: from >> centrally-driven configuration of devices to peer negotiation >> between devices. In this WG we'd like to get feedback on >> the problem statement based on real experience, since the >> NMRG discussion is more likely to be theoretical. >> Also, is our summary of existing protocols accurate? >> >> Brian >> >> -------- Original Message -------- >> Subject: I-D Action: draft-jiang-config-negotiation-ps-02.txt >> Date: Sat, 18 Jan 2014 11:23:25 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Network Configuration Negotiation Problem >> Statement and Requirements >> Authors : Sheng Jiang >> Yuanbin Yin >> Brian Carpenter >> Filename : draft-jiang-config-negotiation-ps-02.txt >> Pages : 14 >> Date : 2014-01-18 >> >> Abstract: >> This document describes a problem statement and general requirements >> for distributed autonomous configuration of multiple aspects of >> networks, in particular carrier networks. The basic model is that >> network elements need to negotiate configuration settings with each >> other to meet overall goals. The document describes a generic >> negotiation behavior model. The document also reviews whether >> existing management and configuration protocols may be suitable for >> autonomic networks. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-ps/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-jiang-config-negotiation-ps-02 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> -- >> Regards >> Brian Carpenter >> http://orcid.org/0000-0001-7924-6182 >> >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> >