From hermans@fox-it.com Mon Feb 3 07:24: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 D48C91A017E for ; Mon, 3 Feb 2014 07:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.535] 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 k0meUiNKIasv for ; Mon, 3 Feb 2014 07:24:22 -0800 (PST) Received: from ns2.fox-it.com (ns2.fox-it.com [178.250.144.131]) by ietfa.amsl.com (Postfix) with ESMTP id 391F41A0172 for ; Mon, 3 Feb 2014 07:24:21 -0800 (PST) Received: from FOXDFT02.FOX.local (unknown [10.0.0.66]) by ns2.fox-it.com (Postfix) with ESMTPS id A3478357FE7; Mon, 3 Feb 2014 16:24:20 +0100 (CET) Received: from FOXDFT02.FOX.local ([::1]) by FOXDFT02.FOX.local ([::1]) with mapi; Mon, 3 Feb 2014 16:24:14 +0100 From: Kees-Jan Hermans To: Brian E Carpenter Date: Mon, 3 Feb 2014 16:24:19 +0100 Thread-Topic: [OPSAWG] Negotiation replacing configuration Thread-Index: Ac8g8/7R3O6kajwFSsqdXr4CqiW3Vw== Message-ID: References: <52E84575.3090408@gmail.com> In-Reply-To: <52E84575.3090408@gmail.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, nl-NL Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 03 Feb 2014 15:24:29 -0000 Personal first impressions: - Any tool that allows for the automatic configuration of devices wrt their= routes, is also a tool for a DOS attack. You notice this, and that it shou= ld only run in 'trust relationships=92. That=92s good, but at the moment, t= he internet has scarce support for trust relationships. - Negotiation usually implies multiple messages in a tight, ordered sequenc= e. This doesn=92t necessarily do well on unstable, mobile networks where me= ssages may get lost, requiring time-consuming re-negotiation. - When you say =91XML=92, I say: needless complexity that runs afoul of wha= t most small devices can or should have to handle. You notice this too, for= tunately. Only too glad you didn=92t go for TCP ;-) - I wonder about using multicast. Doesn=92t that create a chicken-and-egg p= roblem (as the multicast configuration may be part of what we=92re trying t= o configure about a router)? Also: packet storms. KJ On 29 Jan 2014, at 01:04, Brian E Carpenter w= rote: > Hi, >=20 > 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? >=20 > Brian >=20 > -------- 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 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Network Configuration Negotiation Problem Statem= ent and Requirements > Authors : Sheng Jiang > Yuanbin Yin > Brian Carpenter > Filename : draft-jiang-config-negotiation-ps-02.txt > Pages : 14 > Date : 2014-01-18 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-ps/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-config-negotiation-ps-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 >=20 >=20 > --=20 > Regards > Brian Carpenter > http://orcid.org/0000-0001-7924-6182 >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From brian.e.carpenter@gmail.com Mon Feb 3 11:08: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 171D51A01DA for ; Mon, 3 Feb 2014 11:08:53 -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 WKc4J-PByZi2 for ; Mon, 3 Feb 2014 11:08:50 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B6F961A01CA for ; Mon, 3 Feb 2014 11:08:50 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id lj1so7399934pab.26 for ; Mon, 03 Feb 2014 11:08:50 -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=0RH+nm+kc+T8VvokdVaFqQb7XCeZvAGRtREt8Kjx92U=; b=O2EfjGCsXQWBvv49bozRlml/Z7gc2g3EZTqq2hYF5u5kag35hMiNnkFOhZlPx7cOI1 JtOAdSs02Kwj02c3fPhAdd80OU62Bx70PqrUnqV1xKjm3F3X+LL9b3sc9O2pRZnGmg9S wtdZRn0PZn3cG9hGy7fHKSLMya3FYDUYYmaZfIm8/L71e6CHP5sEgKyx1XoOdFOc4i/0 VOw/ifwh51oiNs8bx7DyPrYiL7HFirVNbXYU/CBqFv7hwKWjb/y/DlKWB3X5jTkQrzJx 5KTz4rjjwfLOBWrc4FDcMrv/kBrDViKvWRDxkEPxKSMjo4LX9Uzi8GQCnx5YKpVHBHh9 bSaA== X-Received: by 10.68.195.4 with SMTP id ia4mr9132140pbc.142.1391454530754; Mon, 03 Feb 2014 11:08:50 -0800 (PST) Received: from [192.168.178.23] (147.199.69.111.dynamic.snap.net.nz. [111.69.199.147]) by mx.google.com with ESMTPSA id da3sm58535593pbc.30.2014.02.03.11.08.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 11:08:49 -0800 (PST) Message-ID: <52EFE942.8080708@gmail.com> Date: Tue, 04 Feb 2014 08:08:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kees-Jan Hermans References: <52E84575.3090408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 03 Feb 2014 19:08:53 -0000 Kees-Jan, Good comments, thanks... On 04/02/2014 04:24, Kees-Jan Hermans wrote: > Personal first impressions: >=20 > - Any tool that allows for the automatic configuration of devices wrt t= heir routes, is also a tool for a DOS attack. You notice this, and that i= t should only run in 'trust relationships=E2=80=99. That=E2=80=99s good, = but at the moment, the internet has scarce support for trust relationship= s. One aspect is that such a protocol would only be used within a well-defined administrative boundary, so keeping an external DOS attack out is probably possible. An internally generated DOS attack will be harder to block, especially if it attacks the authentication of the protocol itself. > - Negotiation usually implies multiple messages in a tight, ordered seq= uence. This doesn=E2=80=99t necessarily do well on unstable, mobile netwo= rks where messages may get lost, requiring time-consuming re-negotiation.= Good point. But p2p routing for mobiles has a similar problem; we need to look at how MANET handles this. > - When you say =E2=80=98XML=E2=80=99, I say: needless complexity that r= uns afoul of what most small devices can or should have to handle. You no= tice this too, fortunately. Only too glad you didn=E2=80=99t go for TCP ;= -) >=20 > - I wonder about using multicast. Doesn=E2=80=99t that create a chicken= -and-egg problem (as the multicast configuration may be part of what we=E2= =80=99re trying to configure about a router)? Also: packet storms. Yes, that needs careful thought. Brian > KJ >=20 > On 29 Jan 2014, at 01:04, Brian E Carpenter wrote: >=20 >> 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 dir= ectories. >> >> >> Title : Network Configuration Negotiation Problem Sta= tement 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=3Ddraft-jiang-config-negotiation-ps-0= 2 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> 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 >> >> >> --=20 >> Regards >> Brian Carpenter >> http://orcid.org/0000-0001-7924-6182 >> >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >=20 >=20 From mehmet.ersue@nsn.com Mon Feb 3 11:27: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 1919E1A01E7 for ; Mon, 3 Feb 2014 11:27:33 -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 vcDOVW9PDlkS for ; Mon, 3 Feb 2014 11:27:30 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id ACE6D1A01CE for ; Mon, 3 Feb 2014 11:27:29 -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 s13JRRSY018824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Feb 2014 20:27:28 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s13JRQRI002830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 20:27:27 +0100 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 3 Feb 2014 20:27:26 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 20:27:26 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "'ext Sehgal, Anuj'" , "opsawg@ietf.org" Thread-Topic: Review of draft-opsawg-ersue-coman-*-00 Thread-Index: AQHPCPQWWEuKpIexs0+SqAGsC1Q1oJpzxoIAgARU1bA= Date: Mon, 3 Feb 2014 19:27:25 +0000 Message-ID: References: <4BBB7BFA-A744-40F2-803E-83ADB957F198@jacobs-university.de> <4B92C175-DBEC-492B-B4B1-FEC68522D9A2@jacobs-university.de> In-Reply-To: <4B92C175-DBEC-492B-B4B1-FEC68522D9A2@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.121] Content-Type: text/plain; charset="iso-8859-1" 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: 4559 X-purgate-ID: 151667::1391455648-00001A6F-D7E8FF08/0-0/0-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: Mon, 03 Feb 2014 19:27:33 -0000 Hi Anuj, thank you for your thorough review. See below (ME: ). 1.3 Network Types and Characteristics in Focus ---------------------------------------------- (a) "Mobile Adhoc networks (MANET) are self-configuring _infrastructureless_ networks of mobile devices connected by wireless technologies." --> Why is a differentiation being made between MANETs and other types of wireless networks? Couldn't moblie phones technically fit into the IoT as well? Is the differentiation only made based on the _infrastructureless_ part of it? If so, does it make sense to have categories of infrastructure and infrastructureless, rather than MANET and non-MANET networks? ME: I can go with your proposal to use infrastructureless networks and give= MANET as an example. I think Car-to-car networks is another example but this wouldn't be necessa= rily constrained. I think mobile phones shouldn't be counted as constrained devices.=20 (b) "Wireline non-constrained networks are mainly used for specific applications like Building Automation or Infrastructure Monitoring. However, wireline and wireless networks with multi-hop or point-to- multipoint connectivity are especially in the interest of the analysis on the management of constrained devices in this document." --> This paragraph is unclear. What is it trying to convey? Is it saying that only wireline multi-hop and point-to-multipoint are within the scope of this document? Why not regular wireline networks that may have constrained devices as part of a non-constrained network? ME: By saying they are "especially in the interest of the analysis the text= does not exclude the others. Non-constrained wireline networks with constrained devices are in scope (e.= g. Building automation). --> There is talk about bandwidth, but not frame size, which is likely to have a bigger impact than the overall bandwidth available in a channel. Maybe this should be mentioned? ME: In section 3.11. Implementation Requirements we talk on protocol messag= e size. Though we don't talk on frame size 1.6. Managing the Constrainedness of a Device or Network --------------------------------------------------------- (a) "might only be able to support one simple communication protocol, i.e. the management protocol needs to be possible to downscale from constrained (C2) to very constrained (C0) devices" --> Is it important that the same management protocol be applicable to the entire range of constrained devices? Why not allow the capabilities of the management protocol to scale up and down with the type/capabilities of the device at hand? SOLUTION: A new bullet point stating that different management protocols work on different class of devices. ME: It is for sure possible that different management protocols work on=20 different class of devices. Though it is desirable that the protocol=20 is prepared for downscaling enabling the use of same type of message and=20 information exchange as well as easy mapping of protocol commands. (b) "might only be able to support limited or no user and/or transport security" AND "might only be able to support very simple encryption" --> Simple encryption doesn't make sense, maybe it should be efficient encryption instead? ME: I can agree with "efficient for memory and CPU usage". Efficient=20 only does not explain what we want to say. (c) "might also need energy-efficient key management algorithms for security." --> Not just energy-efficient, but also memory, processing and etc. efficient. No? SOLUTION: Change text to only efficient key management. ME: I think it needs to described what kind of efficiency we mean. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Sehgal, Anuj [mailto:s.anuj@jacobs-university.de] > Sent: Saturday, January 04, 2014 3:28 AM > To: opsawg@ietf.org > Cc: Ersue, Mehmet (NSN - DE/Munich); Sch=F6nw=E4lder, J=FCrgen > Subject: Re: Review of draft-opsawg-ersue-coman-*-00 >=20 > Hi, >=20 > As per the call for reviewing the COMAN documents, I have taken a look at= the latest > versions and have a few comments/recommendations for both. The reviews, a= long > with suggestions on fixing them, are attached to this email in appropriat= e files. >=20 > Regards, > Anuj Sehgal From hermans@fox-it.com Wed Feb 5 01:58:18 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 B3A371A00B7 for ; Wed, 5 Feb 2014 01:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 Tf5MEXBIRzM9 for ; Wed, 5 Feb 2014 01:58:15 -0800 (PST) Received: from ns2.fox-it.com (ns2.fox-it.com [178.250.144.131]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECD61A00BF for ; Wed, 5 Feb 2014 01:58:14 -0800 (PST) Received: from FOXDFT02.FOX.local (unknown [10.0.0.66]) by ns2.fox-it.com (Postfix) with ESMTPS id BD983357A30; Wed, 5 Feb 2014 10:58:13 +0100 (CET) Received: from FOXDFT02.FOX.local ([::1]) by FOXDFT02.FOX.local ([::1]) with mapi; Wed, 5 Feb 2014 10:58:13 +0100 From: Kees-Jan Hermans To: Brian E Carpenter Date: Wed, 5 Feb 2014 10:58:12 +0100 Thread-Topic: [OPSAWG] Negotiation replacing configuration Thread-Index: Ac8iWMfx130Cs7rsSkeSaczb67ASXA== Message-ID: References: <52E84575.3090408@gmail.com> <52EFE942.8080708@gmail.com> In-Reply-To: <52EFE942.8080708@gmail.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, nl-NL Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 05 Feb 2014 09:58:18 -0000 My - strictly personal - take (but I=92m completely derailing the discussio= n here) would be to extend ICMP and create a path MTU message equivalent fo= r throughput. Something with an optional solicitation message (could be ICM= P ping with special code), and a reply along the lines of an ICMP type 3, = code 4 (=91packet too big=92) message. When TCP on a host, or a router in g= eneral, thinks that things are going too slow, he=92ll send one of those. T= hey could also be sent back unsolicited in the way that packet too big mess= ages are usually sent. The added benefit would be that routers along the pa= th benefit from the information, and re-think their routes. Sincerely, KJ On 03 Feb 2014, at 20:08, Brian E Carpenter w= rote: > Kees-Jan, >=20 > Good comments, thanks... >=20 > On 04/02/2014 04:24, Kees-Jan Hermans wrote: >> Personal first impressions: >>=20 >> - Any tool that allows for the automatic configuration of devices wrt th= eir routes, is also a tool for a DOS attack. You notice this, and that it s= hould only run in 'trust relationships=92. That=92s good, but at the moment= , the internet has scarce support for trust relationships. >=20 > One aspect is that such a protocol would only be used within a > well-defined administrative boundary, so keeping an external > DOS attack out is probably possible. An internally generated DOS > attack will be harder to block, especially if it attacks the > authentication of the protocol itself. >=20 >> - Negotiation usually implies multiple messages in a tight, ordered sequ= ence. This doesn=92t necessarily do well on unstable, mobile networks where= messages may get lost, requiring time-consuming re-negotiation. >=20 > Good point. But p2p routing for mobiles has a similar problem; > we need to look at how MANET handles this. >=20 >> - When you say =91XML=92, I say: needless complexity that runs afoul of = what most small devices can or should have to handle. You notice this too, = fortunately. Only too glad you didn=92t go for TCP ;-) >>=20 >> - I wonder about using multicast. Doesn=92t that create a chicken-and-eg= g problem (as the multicast configuration may be part of what we=92re tryin= g to configure about a router)? Also: packet storms. >=20 > Yes, that needs careful thought. >=20 > Brian >=20 >> KJ >>=20 >> On 29 Jan 2014, at 01:04, Brian E Carpenter wrote: >>=20 >>> Hi, >>>=20 >>> 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? >>>=20 >>> Brian >>>=20 >>> -------- 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 >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>>=20 >>>=20 >>> Title : Network Configuration Negotiation Problem State= ment and Requirements >>> Authors : Sheng Jiang >>> Yuanbin Yin >>> Brian Carpenter >>> Filename : draft-jiang-config-negotiation-ps-02.txt >>> Pages : 14 >>> Date : 2014-01-18 >>>=20 >>> 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. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-ps/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-config-negotiation-ps-02 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> 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 >>>=20 >>>=20 >>> --=20 >>> Regards >>> Brian Carpenter >>> http://orcid.org/0000-0001-7924-6182 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >>=20 >=20 From dromasca@avaya.com Wed Feb 5 07:20:02 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 D14541A01FB for ; Wed, 5 Feb 2014 07:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 cYOdxEgOo1b6 for ; Wed, 5 Feb 2014 07:19:52 -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 DBDEC1A0205 for ; Wed, 5 Feb 2014 07:19:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngRAD5W8lKHCzI1/2dsb2JhbABZgkgjIThXqDsIlTJPgQ4WdIInAQEDEggBDAZFGQEVBRAWAT8XDwEEGwESB4djAQyecIRSq3cXjg0QBwEBHg+CWA9mgRQEiRGLMYpZizGDLYFoCRci X-IronPort-AV: E=Sophos;i="4.95,786,1384318800"; d="scan'208,217";a="48246222" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 05 Feb 2014 10:19:48 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 05 Feb 2014 10:07:10 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 16:19:46 +0100 From: "Romascanu, Dan (Dan)" To: "opsawg@ietf.org" Thread-Topic: comments resolution for draft-ietf-opsawg-coman-probstate-reqs-00 Thread-Index: Ac8ihZYGxDYxy3H1TMuOOruN9Q9BBw== Date: Wed, 5 Feb 2014 15:19:46 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3ED218@AZ-FFEXMB04.global.avaya.com> 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_9904FB1B0159DA42B0B887B7FA8119CA2E3ED218AZFFEXMB04globa_" MIME-Version: 1.0 Subject: [OPSAWG] comments resolution for draft-ietf-opsawg-coman-probstate-reqs-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: Wed, 05 Feb 2014 15:20:03 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3ED218AZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We received a number of valuable comments for draft-ietf-opsawg-coman-prob= state-reqs-00. Thanks to everybody who reviewed and commented. Here are our= proposed comments resolution and edits. First review was mine: http://www.ietf.org/mail-archive/web/opsawg/current/= msg03077.html =D8 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 autom= atic association of a device being small implying that it is also constrain= ed. Nor are all constrained devices small in size. PROPOSED RESOLUTION: s/small devices/constrained devices/ (there are three = instances in the document) =D8 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 netw= orks, 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 wh= ich constrained networks are mentioned should be carefully examined to make= sure that the focus of the document stays with constrained devices, and th= at if constrained networks are mentioned at all this is in the context of t= heir relationship with the constrained devices. DISCUSSION: Fix the last two bullets in section 1.5. In 4.1.006, and Sectio= n A.2 rephrase as 'network of constrained devices' =D8 3. I do not believe that we can get away with a zero-content security = considerations section here either. The document even says: =D8 If specific requirements for security will be identified, they will be described in future versions of this document. =D8 This is not accurate - section 3.6 already speaks about requirments fo= r security and access control, and section 1.6 mentions limitations that wo= uld prevent the implementation of strong scryptographic algorythms. The tex= t needs to be reviewed and revised from this perspective. PROPOSED RESOLUTION: OLD: 5. Security Considerations This document discusses the problem statement and requirements on the network of constrained devices. If specific requirements for security will be identified, they will be described in future versions of this document. NEW: 5. Security Considerations This document discusses the problem statement and requirements on networks of constrained devices. Section 1.6 mentions a number of limita= tions that could prevent the implementation of strong cryptographic algorithms= . Requirements for security and access control are listed in Section 3.6. Message from Zhen Cao: http://www.ietf.org/mail-archive/web/opsawg/current/= msg03104.html =D8 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. PROPOSED RESOLUTION: Sleepy devices as well as putting interfaces to sleep are already mentioned= in section 3.7. A couple of more clarification edits can help: In section 1.6: OLD: might only be able to support a limited operating time (e.g. based on the available battery), i.e. the devices need to economize their energy usage with suitable mechanisms and the managing entity needs to monitor and control the energy status of the constrained devices it manages. NEW: might only be able to support a limited operating time (e.g. based on the available battery), or may behave as 'sleepy endpoints' setting their network links to a disconnected state during long periods of time i.e. the devices need to economize their energy usage with suitable mechanisms and the managing entity needs to monitor and control the energy status of the constrained devices it manages. Req. 4.1.006: OLD: Description: Some constrained devices will only be able to support lossy and unreliable links characterized by a limited data rate, a high latency, and a high transmission error rate. Furthermore constrained devices often duty cycle their radio or the whole device in order to save energy. In both cases the management system must not assume that constrained devices are always reachable. NEW: Description: Some constrained devices will only be able to support lossy and unreliable links characterized by a limited data rate, a high latency, and a high transmission error rate. Furthermore constrained devices often duty cycle their radio or the whole device in order to save energy. Some classes of devices labelled as 'sleepy endpoints' set their network links to a disconnected state during long periods of time. In all cases the management system must not assume that constrained devices are always reachable. Comments from Bert Wijnen: http://www.ietf.org/mail-archive/web/opsawg/curr= ent/msg03096.html =D8 - 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 implementation is in fact monolythic. It often save memory and possibly cpu cycles. PROPOSED RESOLUTION: clarify that the requirement is for the specification = of the protocol and not for the implementation on the devices. OLD: Description: Management protocols should allow modular implementations, i.e., it should be possible to implement only a basic set of protocol primitives on highly constrained devices while devices with additional resources may provide more support for additional protocol primitives. NEW: Description: Management protocols should be specified so that they allo= w for modular implementations, i.e., it should be possible to implement only a basic set of protocol primitives on highly constrained devices while devices with additional resources may provide more support for additional protocol primitives. =D8 - for requirement 4.9.001 It might be good to add a refereence to RFC2914 ?? Just thinking aloud. PROPOSED RESOLUTION: OLD: Description: Provide the ability to avoid congestion by modifying the device's reporting rate for periodical data (which is usually redundant) based on the importance and reliability level of the management data. This functionality is usually controlled by the managing entity, where the managing entity marks the data as important or relevant for reliability. However reducing a device's reporting rate can also be initiated by a device if it is able to detect congestion or has insufficient buffer memory. NEW: Description: Support congestion control principles as defined by [RFC2914]= , e.g. the ability to avoid congestion by modifying the device's reporting rate for periodical data (which is usually redundant) based on the importance and reliability level of the management data. This functionality is usually controlled by the managing entity, where the managing entity marks the data as important or relevant for reliability. However reducing a device's reporting rate can also be initiated by a device if it is able to detect congestion or has insufficient buffer memory. Add [RFC2914] to the Informational References section - for requirement 4.9.003 is that more or less an "implementation" suggestion for requirement 4.9.0= 01 ?? PROPOSED RESOLUTION: reject - congestion avoidance is only one of the reaso= ns traffic delay is applied in networks, so 4.9.003 is not necessarily rela= ted to 4.9.001 Comments from Bert Greevenbosch: http://www.ietf.org/mail-archive/web/opsaw= g/current/msg03116.html (BG1) Section 2: "tininess" can be replaced by "contraints" PROPOSED RESOLUTION: s/tininess/constraints/ (BG2) Section 2: "constraindness" -> constrainedness", "therefor" -> "there= fore" PROPOSED RESOLUTION: accept (BG3) Section 3.1, req 4.1.001: Device type should be "C0, C1 and/or C2" as= described in section 3. PROPOSED RESOLUTION: accept (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. PROPOSED RESOLUTION: reject - this sentence clarifies scalability as enounc= ed in the previous sentence. (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. PROPOSED RESOLUTION: accept - delete or separate the sentence in a note aft= er the requirement (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. PROPOSED RESOLUTION: same as the previous (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. PROPOSED RESOLUTION: move text starting from this sentence to a separate no= te. The text is important to be maintained as in underlines the use of temp= lates filtered by device roles and capacities (BG8) Section 3.2, req 4.2.002: is this a non-functional requirement? If so= , write this in requirement type. PROPOSED RESOLUTION: reject - this is a functional requirement (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. PROPOSED RESOLUTION: accept (BG10) Section 3.2, req 4.2.004: "Hence this requirement is marked optional= for device class C2." - This can be deleted; it should have been device class C0 (most constraine= d) anyway. PROPOSED RESOLUTION: accept (BG11) Sentences like those in BG9 and BG10 appear also elsewhere. Propose = to remove. PROPOSED RESOLUTION: accept (BG12) Section 3.2, req 4.2.004: "Device type: C2", add "C1". (related to B= G10) PROPOSED RESOLUTION: add "C1 (optional)". s/Hence this requirement is marke= d optional for devices class C2/ Hence this requirement is marked optional = for devices class C1/ (BG12) Section 3.2, req 4.2.006: "Device type: C2", add "C1". PROPOSED RESOLUTION: add "C1 (optional)". s/Hence this requirement is marke= d optional for devices class C2/ Hence this requirement is marked optional = for devices class C1/ (BG13) Section 3.3, req 4.3.003: the description should be more verbose and= explicit. PROPOSED RESOLUTION: reject - what is missing? (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. PROPOSED RESOLUTION: reject - we do not believe rollback can be implemented= on C0 devices (BG15) Section 3.4, req 4.4.001: "data caching mechanism" requires a defini= tion or explanation. PROPOSED RESOLUTION: accept (BG16) Section 3.4, req 4.4.004 is marked as "low priority". Isn't network = status monitoring a major use-case? PROPOSED RESOLUTION: reject - we are talking about the computed network sta= tus (BG17) Section 3.4, req 4.4.006 contains "(TBD)". Remove. PROPOSED RESOLUTION: accept (BG18) Section 3.4, req 4.4.011: should C0 (low priority) be mentioned? PROPOSED RESOLUTION: s/Low for C1/Low for C0 and C1/ (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. PRPOSED RESOLUTION: reject, this sentence defines a specific mode of work a= nd scalability for authentication - it does belong here (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. PROPOSED RESOLUTION: accept (BG21) Section 3.6, req 4.6.004: "(like some elliptic curve algorithm)" can= be deleted, as it seems unnecessary information. PROPOSED RESOLUTION: accept (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". PROPOSED RESOLUTION: reject, the difference in priority originates in the f= act that SW-based mechanisms are more resource demanding (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". PROPOSED RESOLUTION: accept (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." PROPOSED RESOLUTION: accept (BG25) Section 3.10: put a "---" line between reqs 4.10.003 and 4.10.004. PROPOSED RESOLUTION: accept (BG26) Section 3.11: put a "---" line between reqs 4.11.001 and 4.11.002. PROPOSED RESOLUTION: accept (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. PROPOSED RESOLUTION: accept, already addressed by the resolution to a previ= ous comment (BG28) Appendix A has some overlap with draft-greevenbosch-coman-candidate-= tech, which also describes current available technology. PROPOSED RESOLUTION: deleted appendices A and B (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. PROPOSED RESOLUTION: see above (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. PROPOSED RESOLUTION: accept - remove section Comments from Hui Deng: http://www.ietf.org/mail-archive/web/opsawg/current= /msg03105.html 1. in section 3., a section of 'IPv4/v6 address management' could be = helpful, including the discussion of different types of ip addresses on dev= ices, link-local, global, private, etc.. It is not really clear what the commenter means here. Mehmet asked, we did = not see an answer yet. 2. in Appendix A, any relevant discussion in 'oneM2M'? PROPOSED RESOLUTION: see above, appendix removed Comments from James Nguyen: http://www.ietf.org/mail-archive/web/opsawg/cur= rent/msg03127.html (1) Req-ID 4.3.002 Title: Capacity Discovery I don't quite understand this req. Please be more specific. The commenter took back his comment after being pointed by Juergen to the r= elevant text. (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 configu= rations is issued, reliable multicast with negative acknowledgement (e.g. N= egative ACKnowledgement (NACK)-Oriented Reliable Multicast (NORM)) would wo= rk 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 const= rained networks. DISCUSS: Juergen had an exchange of mails with the commenter - not clear wh= at edits are required if any. : The concern is that 4.10.003 asks for Best-= effort multicast only and lets reliable multicast out. We cannot list relia= ble multicast as a requirements as it is hard to achieve and only needed by= special use cases like the ones James is mentioning. We are in favor of ke= eping the draft more generic and not include such special use cases mention= ed by James. Also we mentioned "stateless" already in the architecture requ= irement 4.1.004 with req on RESTful protocols. (3) Section 3.8 Group-based provisioning As I mentioned in (2), a common data model would be required for commo= n redundant configurations. I suggest to add this requirement here. PROPOSED RESOLUTION: In section 3.8: OLD: Description: Support group-based provisioning, i.e. firmware update and configuration management, of a large set of constrained devices with eventual consistency and coordinated reload times. The device should accept group-based configuration management based on bulk commands, which aim similar configurations of a large set of constrained devices of the same type in a given group. Activation of configuration may be based on pre-loaded sets of default values. NEW: Description: Support group-based provisioning, i.e. firmware update and configuration management, of a large set of constrained devices with eventual consistency and coordinated reload times. The device should accept group-based configuration management based on bulk commands, which aim similar configurations of a large set of constrained devices of the same type in a given group, and which may share a common data model. Activation of configuration may be based on pre-loaded sets of default values. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3ED218AZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

We received a number of valuable comments  for = draft-ietf-opsawg-coman-probstate-reqs-00. Thanks to everybody who reviewed= and commented. Here are our proposed comments resolution and edits.

 

First review was mine: http://www.ietf.org/mail-archive/web/opsawg/current/msg03077.html<= /o:p>

 

=D8  1. The draft uses the 'ad= jective' 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.

 

PROPOSED RESOLUTION: s/small devices/constrained devices/ = (there are three instances in the document)

 

=D8  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 st= ill has text about constrained networks - this section and other in which c= onstrained 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 menti= oned at all this is in the context of their relationship with the constrain= ed devices.

 

DISCUSSION: Fix the last two bullets in section 1.5. In 4.= 1.006, and Section A.2 rephrase as ‘network of constrained devices= 217;

 

=D8  3. I do not believe that = we can get away with a zero-content security considerations section here ei= ther. The document even says:

 

=D8  If specific requirements = for

   security will be identified, they will be des= cribed in future

   versions of this document.<= /p>

 

=D8  This is not accurate - se= ction 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 n= eeds to be reviewed and revised from this perspective.

 

PROPOSED RESOLUTION:

 

OLD:

 

5.  Security Considerations

   This document discusses the problem statement and requirements= on the
   network of constrained devices.  If specific requirements= for
   security will be identified, they will be described in future<= br>    versions of this document.

 

NEW:

 

5.  Security Considerations

   This document discusses the problem statement and requirements= on
   networks of constrained devices. Section 1.6 mentions a n= umber of limitations

   that could prevent the implementation of strong cryptograph= ic algorithms.

   Requirements for security and access  control are= listed in Section 3.6.

 

   

Message from Zhen Cao: http://www.ietf.org/mail-archive/web/opsawg/current/msg03104.html =

 

=D8  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<=
/pre>

management', the scope of sleepy nodes management should be broader


than that.


 


PROPOSED RESOLUTION:



 <=
/p>

Sleepy devices as well as=
 putting interfaces to sleep are already mentioned in section 3.7. A couple=
 of more clarification edits can help:



 <=
/p>

In section 1.6:


 <=
/p>

OLD:



 <=
/p>

      might only be able to support a limited o=
perating time (e.g. based

      on the available battery), i.e. the devices =
need to economize

      their energy usage with suitable mechanisms =
and the managing

      entity needs to monitor and control the ener=
gy status of the

      constrained devices it manages.<=
/o:p>


 

NEW:



 <=
/p>

      might only be able to support a limited o=
perating time (e.g. based

      on the available battery), or may behave as =
‘sleepy endpoints’ 


      setting their network links to a dis=
connected state during long



      periods of time i.e. the devices nee=
d to economize

      their energy usage with suitable mechanisms =
and the managing

      entity needs to monitor and control the ener=
gy status of the

      constrained devices it manages.<=
/o:p>


 

Req. 4.1.006:<=
/o:p>


 

OLD: 

 

Description:  Some constrained devices will only be able to support=


      lossy and unreliable links characterized by =
a limited data rate, a

      high latency, and a high transmission error =
rate.  Furthermore

      constrained devices often duty cycle their r=
adio or the whole

      device in order to save energy.  In bot=
h cases the management

      system must not assume that constrained devi=
ces are always

      reachable.  


 

NEW:


 

Description:  Some constrained devices will only be able to support=


      lossy and unreliable links characterized by =
a limited data rate, a

      high latency, and a high transmission error =
rate.  Furthermore

      constrained devices often duty cycle their r=
adio or the whole

      device in order to save energy. Some classes=
 of devices labelled as


      ‘sleepy endpoints’ set their =
network links to a disconnected state



      during long periods of time. In all =
cases the management

      system must not assume that constrained devi=
ces are always

      reachable.  


 

 

Comments from Bert =
Wijnen: 
http://www.ietf.org/mail-archive/web/opsawg/current/msg03096.html<=
/o:p>


 

 

=D8  - for re=
quirement 4.2.0001


  I wonder why a C0 device would have to implement in a modular f=
ashion.


  I could see that a C0 device (Maybe even C1) does the minimal


  modular-function-set implementation, but that the implementatio=
n is in


  fact monolythic. It often save memory and possibly cpu cycles.<=
o:p>


 


PROPOSED RESOLUTION: clarify that the requirement is for the specifica=
tion of the protocol and not for the implementation on the devices.


 


OLD: 


 


   Description:  Management protocols should allow modula=
r

      implementations, i.e., it should be possible=
 to implement only a

      basic set of protocol primitives on highly c=
onstrained devices

      while devices with additional resources may =
provide more support

      for additional protocol primitives. <=
o:p>


 


NEW: 


 


   Description:  Management protocols should be specified=
 so that they allow



      for modular implementations, i.e., i=
t should be possible to implement



      only a basic set of protocol primiti=
ves on highly constrained devices

      while devices with additional resources may =
provide more support

      for additional protocol primitives. <=
o:p>


 


 


=D8  - for re=
quirement 4.9.001


  It might be good to add a refereence to RFC2914 ??

  Just thinking aloud.


 


PROPOSED RESOLUTION: 


 


OLD: 


 


Description:  Provide the ability to=
 avoid congestion by modifying

      the device's reporting rate for periodical d=
ata (which is usually

      redundant) based on the importance and relia=
bility level of the

      management data.  This functionality is=
 usually controlled by the

      managing entity, where the managing entity m=
arks the data as

      important or relevant for reliability. =
 However reducing a

      device's reporting rate can also be initiate=
d by a device if it is

      able to detect congestion or has insufficien=
t buffer memory.


NEW: 


 


Description:  Support congestion con=
trol principles as defined by [RFC2914],



      e.g. =
 the ability to avoid congestion by modifying

      the device's reporting rate for periodical d=
ata (which is usually

      redundant) based on the importance and relia=
bility level of the

      management data.  This functionality is=
 usually controlled by the

      managing entity, where the managing entity m=
arks the data as

      important or relevant for reliability. =
 However reducing a

      device's reporting rate can also be initiate=
d by a device if it is

      able to detect congestion or has insufficien=
t buffer memory.


Add [RFC2914] to the Informational References section


 


 


- for requirement 4.9.003


  is that more or less an "implementation" suggestion f=
or requirement 4.9.001 ??


 


PROPOSED RESOLUTION=
: reject – congestion avoidance is only one of the reasons traffic de=
lay is applied in networks, so 4.9.003 is not necessarily related to 4.9.00=
1


 

 

Comments from Bert =
Greevenbosch:
http://www.ietf.org/mail-archive/web/opsawg/current/msg03116.html


 

(BG1) Section 2: "tininess" can be replaced by "contrai=
nts"


 


PROPOSED RESOLUTION: s/tininess/constraints/


 


(BG2) Section 2: "constraindness" -> constrainedness"=
;, "therefor" -> "therefore"


 


PROPOSED RESOLUTION: accept


 


(BG3) Section 3.1, req 4.1.001: Device type should be "C0, C1 and=
/or C2" as described in section 3.


 


PROPOSED RESOLUTION: accept


 


(BG4) Section 3.1, req 4.1.002: "This implies that e.g. the manag=
ing 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 tw=
o client requests."


- I think this would better be a separate requirement.

 


PROPOSED RESOLUTION: reject – this sentence clarifies scalabilit=
y as enounced in the previous sentence.


 


(BG5) Section 3.1, req 4.1.004: "One way to achieve this is to ad=
opt a RESTful architecture that minimizes the amount of state maintained by=
 managed constrained devices and that makes resources of a device addressab=
le via URIs."


- This is a solution, not a requirement. I think the text can be delet=
ed.


 


PROPOSED RESOLUTION: accept – delete or separate the sentence in=
 a note after the requirement


 


(BG6) Section 3.1, req 4.1.006: "Intermediaries may be used that =
provide information for devices currently inactive or that take responsibil=
ity to resynchronize devices when they become reachable again after an exte=
nded offline period."


- This is a solution, not a requirement. I think the text can be delet=
ed.


 


PROPOSED RESOLUTION: same as the previous


 


(BG7) Section 3.1, req 4.1.007: "The identification of the releva=
nt subset of policies to be provisioned is according to the capabilities of=
 each device and can be obtained from a pre-configured data-repository.&quo=
t;


- This is a solution, not a requirement. I think the text can be delet=
ed.


 


PROPOSED RESOLUTION: move text starting from this sentence to a separa=
te note. The text is important to be maintained as in underlines the use of=
 templates filtered by device roles and capacities


 


(BG8) Section 3.2, req 4.2.002: is this a non-functional requirement? =
If so, write this in requirement type.


 


PROPOSED RESOLUTION: reject – this is a functional requirement


 


(BG9) Section 3.2, req 4.2.003: "As such, this requirement is mar=
ked as optional."


- I think most requirements are optional at this point, since the draf=
t does not point at a specific solution. Delete the sentence.

 


PROPOSED RESOLUTION: accept


 


(BG10) Section 3.2, req 4.2.004: "Hence this requirement is marke=
d optional for device class C2." 


- This can be deleted; it should have been device class C0 (most const=
rained) anyway.


 


PROPOSED RESOLUTION: accept


 


(BG11) Sentences like those in BG9 and BG10 appear also elsewhere. Pro=
pose to remove.


 


PROPOSED RESOLUTION: accept


 


(BG12) Section 3.2, req 4.2.004: "Device type: C2", add &quo=
t;C1". (related to BG10)


 


PROPOSED RESOLUTION: add "C1 (optional)". s/Hence this requi=
rement is marked optional for devices class C2/ Hence this requirement is m=
arked optional for devices class C1/


 


(BG12) Section 3.2, req 4.2.006: "Device type: C2", add &quo=
t;C1".


 


PROPOSED RESOLUTION: add "C1 (optional)". s/Hence this requi=
rement is marked optional for devices class C2/ Hence this requirement is m=
arked optional for devices class C1/


 


(BG13) Section 3.3, req 4.3.003: the description should be more verbos=
e and explicit.


 


PROPOSED RESOLUTION: reject – what is missing? 


 


(BG14) Section 3.3, req 4.3.003: why does the requirement not apply to=
 C0 devices? They may be sleepy and thus require asynchronous transactions.=



 


PROPOSED RESOLUTION: reject – we do not believe rollback can be =
implemented on C0 devices


 


(BG15) Section 3.4, req 4.4.001: "data caching mechanism" re=
quires a definition or explanation.


 


PROPOSED RESOLUTION: accept


 


(BG16) Section 3.4, req 4.4.004 is marked as "low priority".=
 Isn't network status monitoring a major use-case?


 


PROPOSED RESOLUTION: reject – we are talking about the computed =
network status


 


(BG17) Section 3.4, req 4.4.006 contains "(TBD)". Remove.


 


PROPOSED RESOLUTION: accept


 


(BG18) Section 3.4, req 4.4.011: should C0 (low priority) be mentioned=
?


 


PROPOSED RESOLUTION: s/Low for C1/Low=
 for C0 and C1/


 


(BG19) Section 3.6, req 4.6.001: "In certain application scenario=
s, it is possible that a large number of devices need to be (re)started at =
about the same time. Protocols and authentication systems should be designe=
d such that 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.


 


PRPOSED RESOLUTION: reject, this sentence defines a specific mode of w=
ork and scalability for authentication – it does belong here


 


(BG20) Section 3.6, req 4.6.002: propose to change "add them to a=
ccess control lists." to "provide them with appropriate access co=
ntrol permissions.", as "access control lists" are a specifi=
c solution.


 


PROPOSED RESOLUTION: accept


 


(BG21) Section 3.6, req 4.6.004: "(like some elliptic curve algor=
ithm)" can be deleted, as it seems unnecessary information.=



 


PROPOSED RESOLUTION: accept


 


(BG22) Section 3.6, req 4.6.004: why is there a distinction in priorit=
y between hardware-supported algorithms and other algorithms? I propose to =
set the priority of all to "high".


 


PROPOSED RESOLUTION: reject, the difference in priority originates in =
the fact that SW-based mechanisms are more resource demanding

 


(BG23) Section 3.7, req 4.7.003: "The device will support layer 2=
 energy management protocols (e.g. energy-efficient Ethernet IEEE 802.3az) =
and be able to report on these."


- This should be rephrased to "If the device supports layer 2 ...=
, it should be able to report on these".


 


PROPOSED RESOLUTION: accept


 


(BG24) Section 3.10, req 4.10.001: "not sensitive to the decrease=
 of the time between two client requests."


- Propose to change to "not sensitive to a high rate of incoming =
client requests."


 


PROPOSED RESOLUTION: accept


 


(BG25) Section 3.10: put a "---" line between reqs 4.10.003 =
and 4.10.004.


 


PROPOSED RESOLUTION: accept


 


(BG26) Section 3.11: put a "---" line between reqs 4.11.001 =
and 4.11.002.


 


PROPOSED RESOLUTION: accept


 


(BG27) Section 5: "If specific requirements for security will be =
identified, they will be described in future versions of this document.&quo=
t;


- There are already security requirements in section 3.6, let's mentio=
n that in the security considerations section.


 


PROPOSED RESOLUTION: accept, already addressed by the resolution to a =
previous comment


 


(BG28) Appendix A has some overlap with draft-greevenbosch-coman-candi=
date-tech, which also describes current available technology.

 


PROPOSED RESOLUTION: deleted appendices A and B


 


(BG29) Appendix A.3 "OMA" should mention that the OMA LwM2M =
Technical Specification (TS) has now reached candidate status. The appendix=
 currently only mentions the LwM2M requirements document.


 


PROPOSED RESOLUTION: see above


 


(BG30) Appendix C: "Section 4 on the management requirements ... =
needs further consolidation."


- I think this has already been done. In any case, the appendix can be=
 removed.


 


PROPOSED RESOLUTION: accept – remove section


 


 


Comments from Hui Deng: http://www.ietf.org/mail-archive/web/opsawg=
/current/msg03105.html


 


1.&=
nbsp;     
in section 3., a section of ‘IPv4/v6 address management=
217; could be helpful, including the discussion of different types of ip ad=
dresses on devices, link-local, global, private,
 etc.. 


 


It is not really clear what the comm=
enter means here. Mehmet asked, we did not see an answer yet.



 


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



 


PROPOSED RESOLUTION: see above, appendix removed


 


 


Comments from James Nguyen: http://www.ietf.org/mail-archive/web/op=
sawg/current/msg03127.html


 


(1) Req-ID 4.3.002 Title: Capacity D=
iscovery


 


     I don't quite un=
derstand this req.  Please be more specific.


 


The commenter took back his comment =
after being pointed by Juergen to the relevant text.



 


(2) Section 3.3 Configuration Manage=
ment


 


     Session-oriented=
 configuration protocol may be expensive for managing a large number of sim=
ilar devices.  In a case when common redundant configurations is issue=
d,
 reliable multicast with negative acknowledgement (e.g. Negative ACKnowledg=
ement (NACK)-Oriented Reliable Multicast (NORM)) would work best.  I s=
uggest to add a reliable transport requirement in this section.  Moreo=
ver, a common data model would be needed.
        


 


     Stateless config=
uration update solution would also work well for constrained networks.=



 


DISCUSS: Juergen had an exchange of =
mails with the commenter – not clear what edits are required if any.
: The concern is that 4.10.003 asks for =
Best-effort multicast only and lets reliable multicast out. We cannot list =
reliable multicast as a requirements as it is hard to achieve and only need=
ed by special use cases like the ones
 James is mentioning. We are in favor of keeping the draft more generic and=
 not include such special use cases mentioned by James. Also we mentioned &=
#8220;stateless” already in the architecture requirement 4.1.004 with=
 req on RESTful protocols.


 


 


(3) Section 3.8 Group-based provisio=
ning


 


     As I mentioned i=
n (2), a common data model would be required for common redundant configura=
tions.  I suggest to add this requirement here.


 


PROPOSED RESOLUTION: In section 3.8:=



 


OLD:



 


Description:  Support group-based pr=
ovisioning, i.e. firmware update

      and configuration management, of a large set=
 of constrained

      devices with eventual consistency and coordi=
nated reload times.

      The device should accept group-based configu=
ration management

      based on bulk commands, which aim similar co=
nfigurations of a

      large set of constrained devices of the same=
 type in a given

      group.  Activation of configuration may=
 be based on pre-loaded

      sets of default values.

NEW:



 


Description:  Support group-based pr=
ovisioning, i.e. firmware update

      and configuration management, of a large set=
 of constrained

      devices with eventual consistency and coordi=
nated reload times.

      The device should accept group-based configu=
ration management

      based on bulk commands, which aim similar co=
nfigurations of a

      large set of constrained devices of the same=
 type in a given

      group, and which may share a common data mod=
el. Activation of 


      confi=
guration may be based on pre-loaded sets of default values.


Regards,


 


Dan


 


 
--_000_9904FB1B0159DA42B0B887B7FA8119CA2E3ED218AZFFEXMB04globa_-- From Bert.Greevenbosch@huawei.com Sun Feb 9 19:20:32 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 D5AD61A0793 for ; Sun, 9 Feb 2014 19:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 kffl9XyQo6bE for ; Sun, 9 Feb 2014 19:20:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C2B8E1A0795 for ; Sun, 9 Feb 2014 19:20:30 -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 BAY36505; Mon, 10 Feb 2014 03:20:30 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 03:19:37 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 03:20:29 +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; Mon, 10 Feb 2014 11:20:23 +0800 From: Bert Greevenbosch To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] comments resolution for draft-ietf-opsawg-coman-probstate-reqs-00 Thread-Index: Ac8ihZYGxDYxy3H1TMuOOruN9Q9BBwDf4XngAAAEY0A= Date: Mon, 10 Feb 2014 03:20:23 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E3F51F4@SZXEMA510-MBX.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63E3F5121@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E3F5121@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OPSAWG] comments resolution for draft-ietf-opsawg-coman-probstate-reqs-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: Mon, 10 Feb 2014 03:20:33 -0000 SGkgRGFuLA0KDQpUaGFua3MgZm9yIGFkZHJlc3NpbmcgbXkgY29tbWVudHMuDQoNCkkgdGhpbmsg bW9zdCBvZiB5b3VyIHByb3Bvc2VkIHJlc29sdXRpb25zIGFyZSBPSywgc28gYmVsb3cgSSBvbmx5 IGdpdmUgZmVlZGJhY2sgb24gdGhvc2UgdGhhdCBuZWVkIG1vcmUgZGlzY3Vzc2lvbiBmcm9tIG15 IHBvaW50IG9mIHZpZXcuIElmIEkgZG9uJ3QgZ2l2ZSBmZWVkYmFjayB0byBhIHByb3Bvc2VkIHJl c29sdXRpb24sIGl0IG1lYW5zIEkgYWdyZWUgd2l0aCB0aGF0IHJlc29sdXRpb24gKGluY2x1ZGlu ZyByZWplY3Rpb24pLg0KDQpCZXN0IHJlZ2FyZHMsDQpCZXJ0DQoNCg0KPiAoQkcxMykgU2VjdGlv biAzLjMsIHJlcSA0LjMuMDAzOiB0aGUgZGVzY3JpcHRpb24gc2hvdWxkIGJlIG1vcmUgdmVyYm9z ZQ0KPiBhbmQgZXhwbGljaXQuDQo+IA0KPiBQUk9QT1NFRCBSRVNPTFVUSU9OOiByZWplY3Qg4oCT IHdoYXQgaXMgbWlzc2luZz8NCg0KVGhlIHJlbGF0ZWQgcmVxdWlyZW1lbnQgY3VycmVudGx5IGhh cyB0aGUgZm9sbG93aW5nIHdvcmRpbmc6DQoNCiJQcm92aWRlIGNvbmZpZ3VyYXRpb24gbWFuYWdl bWVudCB3aXRoIGFzeW5jaHJvbm91cyB0cmFuc2FjdGlvbiBzdXBwb3J0LiBDb25maWd1cmF0aW9u IG9wZXJhdGlvbnMgbXVzdCBzdXBwb3J0IGEgdHJhbnNhY3Rpb25hbCBtb2RlbCwgd2l0aCBhc3lu Y2hyb25vdXMgaW5kaWNhdGlvbnMgdGhhdCB0aGUgdHJhbnNhY3Rpb24gd2FzIGNvbXBsZXRlZC4i DQoNCkkgZ3Vlc3MgbXkgbWFpbiBpc3N1ZSB3aXRoIHRoaXMgaXMsIHRoYXQgSSBkb24ndCByZWFs bHkga25vdyB3aGF0IGV4YWN0bHkgaXMgbWVhbnQgYnkgYW4gImFzeW5jaHJvbm91cyB0cmFuc2Fj dGlvbiIgKGFzIGl0IGNvdWxkIGJlIHF1aXRlIGJyb2FkKS4gSXMgaXQganVzdCBhIGRlbGF5ZWQg cmVzcG9uc2UvYWNrbm93bGVkZ2VtZW50PyBPciBpcyBpdCBzb21ldGhpbmcgbGlrZSBhIHRyYXAs IHdoaWNoIHNlbmRzIGZlZWRiYWNrIHdoZW5ldmVyIGFuIGV2ZW50IGhhcHBlbnM/DQogDQo+IChC RzE0KSBTZWN0aW9uIDMuMywgcmVxIDQuMy4wMDM6IHdoeSBkb2VzIHRoZSByZXF1aXJlbWVudCBu b3QgYXBwbHkgdG8NCj4gQzAgZGV2aWNlcz8gVGhleSBtYXkgYmUgc2xlZXB5IGFuZCB0aHVzIHJl cXVpcmUgYXN5bmNocm9ub3VzDQo+IHRyYW5zYWN0aW9ucy4NCj4gDQo+IFBST1BPU0VEIFJFU09M VVRJT046IHJlamVjdCDigJMgd2UgZG8gbm90IGJlbGlldmUgcm9sbGJhY2sgY2FuIGJlDQo+IGlt cGxlbWVudGVkIG9uIEMwIGRldmljZXMNCg0KUmVsYXRlZCB0byBCRzEzLiBUaGlzIHdvdWxkIGJl IG1vcmUgZXZpZGVudCB3aGVuICJhc3luY2hyb25vdXMgdHJhbnNhY3Rpb25zIiB3ZXJlIHByb3Bl cmx5IGRlZmluZWQuDQoNCj4gKEJHMTYpIFNlY3Rpb24gMy40LCByZXEgNC40LjAwNCBpcyBtYXJr ZWQgYXMgImxvdyBwcmlvcml0eSIuIElzbid0DQo+IG5ldHdvcmsgc3RhdHVzIG1vbml0b3Jpbmcg YSBtYWpvciB1c2UtY2FzZT8NCj4gDQo+IFBST1BPU0VEIFJFU09MVVRJT046IHJlamVjdCDigJMg d2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGNvbXB1dGVkIG5ldHdvcmsNCj4gc3RhdHVzDQoNClRo ZSBkZXNjcmlwdGlvbiBjdXJyZW50bHkgaXMgYXMgZm9sbG93czoNCg0KIlByb3ZpZGUgYSBtb25p dG9yaW5nIGZ1bmN0aW9uIHRvIGNvbGxlY3QgYW5kIGV4cG9zZSBpbmZvcm1hdGlvbiByZWxhdGVk IHRvIHRoZSBzdGF0dXMgb2YgYSBuZXR3b3JrIG9yIG5ldHdvcmsgc2VnbWVudHMgY29ubmVjdGVk IHRvIHRoZSBpbnRlcmZhY2Ugb2YgdGhlIGRldmljZS4iDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHlv dSBtZWFuIHRoYXQgdGhlIGluZm9ybWF0aW9uIG9mIHRoZSBuZXR3b3JrIGlzIHByb2Nlc3NlZCwg YW5kIGV4cG9zaW5nIGluZm9ybWF0aW9uIGRvZXMgbm90IGNvbmNlcm4ganVzdCB0aGUgcmF3IGlu Zm9ybWF0aW9uPyBBcyBhbiBleGFtcGxlOiBhIGNvdW50ZXIgdGhhdCBjb3VudHMgdGhlIGluY29t aW5nIGFuZCBvdXRnb2luZyBVRFAgcGFja2V0cyBzZWVtcyBzaW1wbGUgZW5vdWdoIGZvciBDMCBk ZXZpY2VzLiBCdXQgY29sbGVjdGluZyB0aGVzZSBjb3VudGVycyBmcm9tIHNldmVyYWwgZGV2aWNl cyBhbmQgdGhlbiBjYWxjdWxhdGUgc29tZSBzdGF0aXN0aWNzIG1heSBpbmRlZWQgYmUgbW9yZSBj b21wbGljYXRlZC4NCg0KSWYgdGhpcyBpcyB3aGF0IGlzIG1lYW50LCBtYXliZSB0aGUgZGVzY3Jp cHRpb24gY291bGQgcmVmbGVjdCB0aGlzLCBlLmcuIGJ5IGFkZGluZyAiYW5hbHlzZSIgYXMgZm9s bG93czoNCg0KTkVXOg0KDQoiUHJvdmlkZSBhIG1vbml0b3JpbmcgZnVuY3Rpb24gdG8gY29sbGVj dCwgYW5hbHlzZSBhbmQgZXhwb3NlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhlIHN0YXR1cyBv ZiBhIG5ldHdvcmsgb3IgbmV0d29yayBzZWdtZW50cyBjb25uZWN0ZWQgdG8gdGhlIGludGVyZmFj ZSBvZiB0aGUgZGV2aWNlLiINCg== From dromasca@avaya.com Mon Feb 10 03:25: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 168C41A0809 for ; Mon, 10 Feb 2014 03:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 iD4bCozNax-y for ; Mon, 10 Feb 2014 03:25:13 -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 852F21A0808 for ; Mon, 10 Feb 2014 03:25:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAMm2+FLGmAcV/2dsb2JhbABZgmshgQ+DAbw8GHcWdIIlAQEBAQMSERFRBAIBBgINBAQBAQMCBh0DAgICMBQBCAgBAQQBEggah2MBjDWRPIpDoFQXgSmNIzgGgmk1gRQEnxuLMYMtgio X-IronPort-AV: E=Sophos;i="4.95,817,1384318800"; d="scan'208";a="42344570" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Feb 2014 06:25:00 -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; 10 Feb 2014 06:13:46 -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.0174.001; Mon, 10 Feb 2014 12:24:58 +0100 From: "Romascanu, Dan (Dan)" To: Bert Greevenbosch , "opsawg@ietf.org" Thread-Topic: [OPSAWG] comments resolution for draft-ietf-opsawg-coman-probstate-reqs-00 Thread-Index: Ac8ihZYGxDYxy3H1TMuOOruN9Q9BBwDf4XngAAAEY0AAEz8qwA== Date: Mon, 10 Feb 2014 11:24:57 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3F5DDF@AZ-FFEXMB04.global.avaya.com> References: <46A1DF3F04371240B504290A071B4DB63E3F5121@SZXEMA510-MBX.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63E3F51F4@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E3F51F4@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OPSAWG] comments resolution for draft-ietf-opsawg-coman-probstate-reqs-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: Mon, 10 Feb 2014 11:25:16 -0000 SGkgQmVydCwNCg0KU2VlIGluLWxpbmUuIFRoYW5rIHlvdSBhZ2FpbiBmb3IgdGhlIGZlZWRiYWNr IGFuZCB0aGUgY29udGludWF0aW9uIG9mIHRoZSBkaWFsb2cuIA0KDQpSZWdhcmRzLA0KDQpEYW4N Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlcnQgR3JlZXZlbmJv c2NoIFttYWlsdG86QmVydC5HcmVldmVuYm9zY2hAaHVhd2VpLmNvbV0NCj4gU2VudDog15nXlded wqDXkSAxMCDXpNeR16jXldeQ16ggMjAxNCAwNToyMA0KPiBUbzogUm9tYXNjYW51LCBEYW4gKERh bik7IG9wc2F3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW09QU0FXR10gY29tbWVudHMgcmVz b2x1dGlvbiBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctY29tYW4tDQo+IHByb2JzdGF0ZS1yZXFzLTAw DQo+IA0KPiBIaSBEYW4sDQo+IA0KPiBUaGFua3MgZm9yIGFkZHJlc3NpbmcgbXkgY29tbWVudHMu DQo+IA0KPiBJIHRoaW5rIG1vc3Qgb2YgeW91ciBwcm9wb3NlZCByZXNvbHV0aW9ucyBhcmUgT0ss IHNvIGJlbG93IEkgb25seSBnaXZlDQo+IGZlZWRiYWNrIG9uIHRob3NlIHRoYXQgbmVlZCBtb3Jl IGRpc2N1c3Npb24gZnJvbSBteSBwb2ludCBvZiB2aWV3LiBJZiBJDQo+IGRvbid0IGdpdmUgZmVl ZGJhY2sgdG8gYSBwcm9wb3NlZCByZXNvbHV0aW9uLCBpdCBtZWFucyBJIGFncmVlIHdpdGggdGhh dA0KPiByZXNvbHV0aW9uIChpbmNsdWRpbmcgcmVqZWN0aW9uKS4NCj4gDQo+IEJlc3QgcmVnYXJk cywNCj4gQmVydA0KPiANCj4gDQo+ID4gKEJHMTMpIFNlY3Rpb24gMy4zLCByZXEgNC4zLjAwMzog dGhlIGRlc2NyaXB0aW9uIHNob3VsZCBiZSBtb3JlDQo+ID4gdmVyYm9zZSBhbmQgZXhwbGljaXQu DQo+ID4NCj4gPiBQUk9QT1NFRCBSRVNPTFVUSU9OOiByZWplY3Qg4oCTIHdoYXQgaXMgbWlzc2lu Zz8NCj4gDQo+IFRoZSByZWxhdGVkIHJlcXVpcmVtZW50IGN1cnJlbnRseSBoYXMgdGhlIGZvbGxv d2luZyB3b3JkaW5nOg0KPiANCj4gIlByb3ZpZGUgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50IHdp dGggYXN5bmNocm9ub3VzIHRyYW5zYWN0aW9uIHN1cHBvcnQuDQo+IENvbmZpZ3VyYXRpb24gb3Bl cmF0aW9ucyBtdXN0IHN1cHBvcnQgYSB0cmFuc2FjdGlvbmFsIG1vZGVsLCB3aXRoDQo+IGFzeW5j aHJvbm91cyBpbmRpY2F0aW9ucyB0aGF0IHRoZSB0cmFuc2FjdGlvbiB3YXMgY29tcGxldGVkLiIN Cj4gDQo+IEkgZ3Vlc3MgbXkgbWFpbiBpc3N1ZSB3aXRoIHRoaXMgaXMsIHRoYXQgSSBkb24ndCBy ZWFsbHkga25vdyB3aGF0IGV4YWN0bHkgaXMNCj4gbWVhbnQgYnkgYW4gImFzeW5jaHJvbm91cyB0 cmFuc2FjdGlvbiIgKGFzIGl0IGNvdWxkIGJlIHF1aXRlIGJyb2FkKS4gSXMgaXQganVzdA0KPiBh IGRlbGF5ZWQgcmVzcG9uc2UvYWNrbm93bGVkZ2VtZW50PyBPciBpcyBpdCBzb21ldGhpbmcgbGlr ZSBhIHRyYXAsIHdoaWNoDQo+IHNlbmRzIGZlZWRiYWNrIHdoZW5ldmVyIGFuIGV2ZW50IGhhcHBl bnM/DQo+IA0KDQpJdCBpcyB0aGUgbGF0ZXIuIFdvdWxkIGl0IGhlbHAgaWYgd2UgY2xhcmlmeSBi eSBtYWtpbmcNCg0Kcy9hc3luY2hyb25vdXMgdHJhbnNhY3Rpb24vYXN5bmNocm9ub3VzIChldmVu dC1kcml2ZW4pIHRyYW5zYWN0aW9uLyA/IA0KDQo+ID4gKEJHMTQpIFNlY3Rpb24gMy4zLCByZXEg NC4zLjAwMzogd2h5IGRvZXMgdGhlIHJlcXVpcmVtZW50IG5vdCBhcHBseSB0bw0KPiA+IEMwIGRl dmljZXM/IFRoZXkgbWF5IGJlIHNsZWVweSBhbmQgdGh1cyByZXF1aXJlIGFzeW5jaHJvbm91cw0K PiA+IHRyYW5zYWN0aW9ucy4NCj4gPg0KPiA+IFBST1BPU0VEIFJFU09MVVRJT046IHJlamVjdCDi gJMgd2UgZG8gbm90IGJlbGlldmUgcm9sbGJhY2sgY2FuIGJlDQo+ID4gaW1wbGVtZW50ZWQgb24g QzAgZGV2aWNlcw0KPiANCj4gUmVsYXRlZCB0byBCRzEzLiBUaGlzIHdvdWxkIGJlIG1vcmUgZXZp ZGVudCB3aGVuICJhc3luY2hyb25vdXMNCj4gdHJhbnNhY3Rpb25zIiB3ZXJlIHByb3Blcmx5IGRl ZmluZWQuDQo+IA0KPiA+IChCRzE2KSBTZWN0aW9uIDMuNCwgcmVxIDQuNC4wMDQgaXMgbWFya2Vk IGFzICJsb3cgcHJpb3JpdHkiLiBJc24ndA0KPiA+IG5ldHdvcmsgc3RhdHVzIG1vbml0b3Jpbmcg YSBtYWpvciB1c2UtY2FzZT8NCj4gPg0KPiA+IFBST1BPU0VEIFJFU09MVVRJT046IHJlamVjdCDi gJMgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGNvbXB1dGVkDQo+ID4gbmV0d29yayBzdGF0dXMN Cj4gDQo+IFRoZSBkZXNjcmlwdGlvbiBjdXJyZW50bHkgaXMgYXMgZm9sbG93czoNCj4gDQo+ICJQ cm92aWRlIGEgbW9uaXRvcmluZyBmdW5jdGlvbiB0byBjb2xsZWN0IGFuZCBleHBvc2UgaW5mb3Jt YXRpb24gcmVsYXRlZCB0bw0KPiB0aGUgc3RhdHVzIG9mIGEgbmV0d29yayBvciBuZXR3b3JrIHNl Z21lbnRzIGNvbm5lY3RlZCB0byB0aGUgaW50ZXJmYWNlIG9mDQo+IHRoZSBkZXZpY2UuIg0KPiAN Cj4gSSB1bmRlcnN0YW5kIHRoYXQgeW91IG1lYW4gdGhhdCB0aGUgaW5mb3JtYXRpb24gb2YgdGhl IG5ldHdvcmsgaXMNCj4gcHJvY2Vzc2VkLCBhbmQgZXhwb3NpbmcgaW5mb3JtYXRpb24gZG9lcyBu b3QgY29uY2VybiBqdXN0IHRoZSByYXcNCj4gaW5mb3JtYXRpb24/IEFzIGFuIGV4YW1wbGU6IGEg Y291bnRlciB0aGF0IGNvdW50cyB0aGUgaW5jb21pbmcgYW5kDQo+IG91dGdvaW5nIFVEUCBwYWNr ZXRzIHNlZW1zIHNpbXBsZSBlbm91Z2ggZm9yIEMwIGRldmljZXMuIEJ1dCBjb2xsZWN0aW5nDQo+ IHRoZXNlIGNvdW50ZXJzIGZyb20gc2V2ZXJhbCBkZXZpY2VzIGFuZCB0aGVuIGNhbGN1bGF0ZSBz b21lIHN0YXRpc3RpY3MgbWF5DQo+IGluZGVlZCBiZSBtb3JlIGNvbXBsaWNhdGVkLg0KPiANCj4g SWYgdGhpcyBpcyB3aGF0IGlzIG1lYW50LCBtYXliZSB0aGUgZGVzY3JpcHRpb24gY291bGQgcmVm bGVjdCB0aGlzLCBlLmcuIGJ5DQo+IGFkZGluZyAiYW5hbHlzZSIgYXMgZm9sbG93czoNCj4gDQo+ IE5FVzoNCj4gDQo+ICJQcm92aWRlIGEgbW9uaXRvcmluZyBmdW5jdGlvbiB0byBjb2xsZWN0LCBh bmFseXNlIGFuZCBleHBvc2UgaW5mb3JtYXRpb24NCj4gcmVsYXRlZCB0byB0aGUgc3RhdHVzIG9m IGEgbmV0d29yayBvciBuZXR3b3JrIHNlZ21lbnRzIGNvbm5lY3RlZCB0byB0aGUNCj4gaW50ZXJm YWNlIG9mIHRoZSBkZXZpY2UuIg0KDQpGaW5lIHdpdGggbWUgd2l0aCB0aGUgZXhjZXB0aW9uIHRo YXQgbXkgc3BlbGxlciBhc2tzIHRvIHdyaXRlIGFuYWx5emUgd2l0aCBhbiAneicuIA0KDQo= From stefan.winter@restena.lu Mon Feb 10 04:53:15 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 E5F4E1A0827 for ; Mon, 10 Feb 2014 04:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 ZQLirJ8Jegh3 for ; Mon, 10 Feb 2014 04:53:13 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 55F1B1A0606 for ; Mon, 10 Feb 2014 04:53:13 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8856110589 for ; Mon, 10 Feb 2014 13:53:12 +0100 (CET) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7933210581 for ; Mon, 10 Feb 2014 13:53:12 +0100 (CET) Message-ID: <52F8CBAA.2050705@restena.lu> Date: Mon, 10 Feb 2014 13:52:58 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <20140210123846.21255.5774.idtracker@ietfa.amsl.com> In-Reply-To: <20140210123846.21255.5774.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Forwarded-Message-Id: <20140210123846.21255.5774.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ij32hveN2TD1ruDLf9gex7pAaXkcj8uaR" X-Virus-Scanned: ClamAV Subject: [OPSAWG] New Version Notification for draft-winter-opsawg-eap-metadata-00.txt (fwd) 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, 10 Feb 2014 12:53:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ij32hveN2TD1ruDLf9gex7pAaXkcj8uaR Content-Type: multipart/mixed; boundary="------------040700030305020100020901" This is a multi-part message in MIME format. --------------040700030305020100020901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A new version of I-D, draft-winter-opsawg-eap-metadata-00.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Name: draft-winter-opsawg-eap-metadata Revision: 00 Title: A Configuration File Format for Extensible Authentication Protocol (EAP) Deployments Document date: 2014-02-10 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-winter-opsawg-eap-metadata-00.t= xt Status: https://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ Htmlized: http://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-00 Abstract: This document specifies a file format for transfering configuration information of deployments of the Extensible Authentication Protocol (EAP). Such configuration files are meant to be discovered, consumed and used by EAP supplicant software to achieve secure and automatic EAP configuration on the consuming device. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------040700030305020100020901 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------040700030305020100020901-- --Ij32hveN2TD1ruDLf9gex7pAaXkcj8uaR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS+MuqAAoJEMDeajWKOdxmYtUP/1clc/piv1tu22NDaC7bN/ex l0nNvshqY+1hG+zDC8LirQGWwjt6reSF88Cg1oVocWleWj+Tm9w5RoJSx6FiWg0H Mrve9Kteec8/s+Mxjcg6dvQsrcdzUVpA92ntUGWvMYOrYJs4Ku3fG3hFwlykJhyr o+4Ykc25ywrw52eSo4tjT/ZD2KkN9WcY/XLVM+qwz6hN4tuGJjVMMR8gzglN1G7B /bO59XkVUjd8lPG6kD7K64iqMxeDP6URTHRgdXpSFZiBXfZUBenNMH1WcgLFPLnH qElaTkimDaa3jBWb7u/xwZ3VsOcw7lDPu5jlkGBu7OiKRnVXVVxax3+KieV/Rfem 4YWPQxvJC4tACaPMGHwYPRNaPPCQnKy9BQpnGh3B9RGxGSUMHB+y9XllnV9UHZAw pIPEOtPhzHNWMjkpZ889P1Yp0ZPC0YG2de5Ph44xHv0oo1HeIYM01Aon5okBjy5e ihJHvr3U8XZKfwLo1w7ZjB4xaQXzOYrZnXo1WYNWbHs9IP7nFaF9qQ/4OczG+EyQ 5fRpkgebL/aHv/vA7Zvfv0Ef0v46+UqzO8TlbDdi6BLc2T9lKHjSuMYKjtI7SjYv V7VQRByXBMtBSZAo2kBtzhUjtIb8Y7kK8dPVh+cgd3kv4sO8wATbyq7L8ZvumQ8K tqR5M7ZmI8BzfmEpmlA0 =VzGX -----END PGP SIGNATURE----- --Ij32hveN2TD1ruDLf9gex7pAaXkcj8uaR-- From stefan.winter@restena.lu Mon Feb 10 04:53:27 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 3B2071A00BC for ; Mon, 10 Feb 2014 04:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, WEIRD_PORT=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 JE7Z7m4QWMGA for ; Mon, 10 Feb 2014 04:53:25 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 407761A082F for ; Mon, 10 Feb 2014 04:53:25 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id E763D10589; Mon, 10 Feb 2014 13:53:24 +0100 (CET) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id D993910581; Mon, 10 Feb 2014 13:53:24 +0100 (CET) Message-ID: <52F8CBB6.9000005@restena.lu> Date: Mon, 10 Feb 2014 13:53:10 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "opsawg@ietf.org" X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="e6ENUFIiM6mpIDchb24GrOwXBqLosxa3W" X-Virus-Scanned: ClamAV Cc: "'sense@geant.net'" Subject: [OPSAWG] EAP configuration metadata draft 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, 10 Feb 2014 12:53:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e6ENUFIiM6mpIDchb24GrOwXBqLosxa3W Content-Type: multipart/mixed; boundary="------------010101000709050500060804" This is a multi-part message in MIME format. --------------010101000709050500060804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I would like to draw your attention to my submission of draft-winter-opsawg-eap-metadata-00 ( http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ ). I would like to ask the community how they feel about this work - is it needed, are we on the right track, etc. As a teaser for why our group thinks this piece of work is important and useful, please see the beginning of the Problem Statement section, pasted here for your convenience: "The IETF has produced the Extensible Authentication Protocol (EAP, [RFC3748] and numerous EAP methods (for example EAP-TTLS [RFC5281], EAP-TLS [RFC5216] and [RFC5931]); the methods have many properties which need to be setup on the EAP server and matched as configuration items on the EAP peer for a secure EAP deployment. Setting up these configuration items is comparatively easy if the end-user devices which implement the EAP peer functionality are under central administrative control, e.g. in closed enterprise environments. Group policies or device provisioning by the IT department can push the settings to user devices. In other environments, for example "BYOD" scenarios where users bring their own devices which are not under enterprise control, or in EAP- based WISP environments (see e.g. [HS20] and [I-D.wierenga-ietf-eduroam]) where it is not desired neither for the ISP nor for his user that the device control is in the ISPs hands, configuration of EAP is significantly harder as it has to be done by potentially very non-technical end users." There's plenty of proprietary approaches, they all vary in richness of expressability, most don't have complete public schemas or are even in binary with no explanations on how to construct them as an outsider. We find the lack of a public specification disturbing. It leads to duplication of efforts in numerous organisations, incompatiblities between the produced formats, and sometimes simply leads to bad quality specs. BTW, I have teased the list earlier (see my posting on 18 Dec 2013), and already got an on-list response (as well as offline). I believe this warrants allocation of slot time in London, and I would at this point ask the chairs if it's possible to get 5 mins (more if you have plenty :-) ) to discuss the problem itself and the solution we've put together in this first draft. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e 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 --------------010101000709050500060804 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------010101000709050500060804-- --e6ENUFIiM6mpIDchb24GrOwXBqLosxa3W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS+Mu2AAoJEMDeajWKOdxm6HIP/1nW5uqOiLG07bSIDoHpc+sH iM3x24Vwp4FAaZgdiZCArE/Q6vmSlciA39Qs2B5oQJenIy7bymW56otEO3cP4COj UYSoQ9xeKOoSdZAPVI7259xSNHMRS1TTcPZCELLd4ai14aiHM7ZqRCloResiPlYz USSDkUBF82RYWDLJdF8+0RCmlYORrEG4bk3Z/D5jVr2AIZ14yNvviXDKaa9eEwUt ewhreAQnvkLg0YOjQe+5OJ9uDHpr8q8y/oGVcTGQtqrh6U5m+6ljglI5rHNV+P/A 0rh/Uv8lqjKS2SqafwbJrceTiRgX6Q77sjzHWaPGs8XRgyNTU4QlaQvUrT12Y4wp EZRa/OIFgRCn4n11cY0KvksuhruE0zNfO+SDiLlP+B/10jj99e03i+YNJNchvugu nhrcLlWyk47heJOp7A/kx5EtBBgWE5igdePqLmTkNMQ7Bmo2zXn/6mBM8LbqVjwZ WyL603oa14dLyqhMxlOIXOaXQJZdC6tknUSts5F8mvZWFKicO8n8Puyap5z7s8Gw L1QqDySMBG7dLVUX8+zKqqAjnAuk78cLj2Zt/nwCA3vZxMI/8uMvx2KZ5HvY4n2T hsO0kBdCgT1/rydwQHc2BRxvCPpatkOjJqk98y7tmENu9vYJiBdmjp2PoH/fzbNd L1zz2filA9P+kUs6J3/Z =i1pY -----END PGP SIGNATURE----- --e6ENUFIiM6mpIDchb24GrOwXBqLosxa3W-- From internet-drafts@ietf.org Mon Feb 10 10:38: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 99D581A05E0; Mon, 10 Feb 2014 10:38:31 -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 YGQW-OwgMiYg; Mon, 10 Feb 2014 10:38:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AADFD1A03A5; Mon, 10 Feb 2014 10:38:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210183828.28279.49928.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 10:38:28 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-vmm-mib-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, 10 Feb 2014 18:38:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Management Information Base for Virtual Machines Controlled by a Hypervisor Authors : Hirochika Asai Michael MacFaden Juergen Schoenwaelder Keiichi Shima Tina Tsou Filename : draft-ietf-opsawg-vmm-mib-00.txt Pages : 58 Date : 2014-02-10 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-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 jiangsheng@huawei.com Mon Feb 10 23:15: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 2371C1A08D7 for ; Mon, 10 Feb 2014 23:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Ng6GvHS1DVu5 for ; Mon, 10 Feb 2014 23:15:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2851C1A0741 for ; Mon, 10 Feb 2014 23:15:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDL66557; Tue, 11 Feb 2014 07:15:29 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 07:15:18 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 07:15:28 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 15:15:10 +0800 From: Sheng Jiang To: "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-xia-customizable-nai-arch-00 & draft-xia-nai-modeling-language-00 Thread-Index: AQHPF+I6dTvp+qGeR0SVl1dfLdF85ZqvvIkQ Date: Tue, 11 Feb 2014 07:15:09 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ADE260F@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [OPSAWG] FW: New Version Notification for draft-xia-customizable-nai-arch-00 & draft-xia-nai-modeling-language-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: Tue, 11 Feb 2014 07:15:33 -0000 SGksIGFsbCwNCg0KSW4gb3JkZXIgdG8gYmV0dGVyIG9yZ2FuaXplIHRoZSBuZXR3b3JrIGFuZCBu ZXR3b3JrIHNlcnZpY2VzLCBhIGN1c3RvbWl6YWJsZSBOZXR3b3JrIEFic3RyYWN0IEludGVyZmFj ZSAoTkFJKSBhcmNoaXRlY3R1cmUgYmFzZWQgb24gbW9kZWwgZGVzY3JpcHRpb24gaXMgaW50cm9k dWNlZCBieSBkcmFmdC14aWEtY3VzdG9taXphYmxlLW5haS1hcmNoLTAwLiBUaGlzIGFyY2hpdGVj dHVyZSBhbGxvd3MgbmV0d29yayBhZG1pbmlzdHJhdG9ycyB0byBjdXN0b21pemUgdGhlaXIgc3Bl Y2lmaWMgTmV0d29yayBBYnN0cmFjdCBJbnRlcmZhY2UuIFRoZSBOQUkgcHJvdmlkZSBhYnN0cmFj dGVkIG5ldHdvcmsgaW5mb3JtYXRpb24gYW5kIGNhcGFiaWxpdHkgdG8gbmV0d29yayBjdXN0b21l cnMgYW5kIHJlY2VpdmUgY3VzdG9taXplZCBvcmRlcnMgZnJvbSB0aGVtLiBJdCBhbGxvd3MgdGhl aXIgY3VzdG9tZXJzIHRvIGN1c3RvbWl6ZSB0aGVpciBvd24gbmV0d29yayBzZXJ2aWNlcyBhcyB0 aGV5IG5lZWQuIFRoZSBOQUkgaXMgZGVzY3JpYmVkIGJ5IG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMg dXNpbmcgYSBuZXdseSBkZXNpZ25lZCBOQUkgbW9kZWxpbmcgbGFuZ3VhZ2UsIHdoaWNoIGlzIGlu dHJvZHVjZWQgYnkgZHJhZnQteGlhLW5haS1tb2RlbGluZy1sYW5ndWFnZS0wMA0KDQpUaGUgYXV0 aG9ycyB3b3VsZCBsaWtlIHRvIGdldCByZXZpZXdzIGFuZCBjb21tZW50cyBmcm9tIHRoZSBtYWls IGxpc3QgcGFydGljaXBhdG9ycy4gTWFueSB0aGFua3MsDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hl bmcgKyBZaW5iZW4NCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPk5h bWU6CQlkcmFmdC14aWEtY3VzdG9taXphYmxlLW5haS1hcmNoDQo+VGl0bGU6CQlDdXN0b21pemFi bGUgTmV0d29yayBBYnN0cmFjdCBJbnRlcmZhY2UgKE5BSSkgQXJjaGl0ZWN0dXJlDQo+YmFzZWQg b24gTW9kZWwgRGVzY3JpcHRpb24NCj5VUkw6DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQteGlhLWN1c3RvbWl6YWJsZS1uYWktYXJjaC0wMC50eHQNCj5TdGF0dXM6 DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteGlhLWN1c3RvbWl6YWJs ZS1uYWktYXJjaC8NCj5IdG1saXplZDoNCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC14aWEtY3VzdG9taXphYmxlLW5haS1hcmNoLTAwDQo+DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhl IG1vcmUgYW5kIG1vcmUgY29tcGxpY2F0ZWQgSVNQIG5ldHdvcmtzIGFyZSByZXF1aXJlZCBhIG5l dw0KPiAgIGludGVyYWN0aW9uIG1lY2hhbmlzbSBiZXR3ZWVuIHRoZWlyIGN1c3RvbWVycyBhbmQg dGhlaXIgbmV0d29ya3MuICBBDQo+ICAgZmxleGlibGUgTmV0d29yayBBYnN0cmFjdCBJbnRlcmZh Y2UgKE5BSSkgaXMgbmVlZGVkIHRvIHByb3ZpZGUNCj4gICBhYnN0cmFjdGVkIG5ldHdvcmsgaW5m b3JtYXRpb24gYW5kIGNhcGFiaWxpdHkgdG8gbmV0d29yayBjdXN0b21lcnMNCj4gICBhbmQgcmVj ZWl2ZSBjdXN0b21pemVkIG9yZGVycyBmcm9tIHRoZW0uICBUaGlzIGRvY3VtZW50IGludHJvZHVj ZXMgYW4NCj4gICBhcmNoaXRlY3R1cmUgdGhhdCBhbGxvd3MgbmV0d29yayBhZG1pbmlzdHJhdG9y cyB0byBjcmVhdGUgdGhlaXINCj4gICBzcGVjaWZpYyBOZXR3b3JrIEFic3RyYWN0IEludGVyZmFj ZS4NCj4NCj5OYW1lOgkJZHJhZnQteGlhLW5haS1tb2RlbGluZy1sYW5ndWFnZQ0KPlRpdGxlOgkJ TmV0d29yayBBYnN0cmFjdCBJbnRlcmZhY2UgKE5BSSkgTW9kZWxpbmcgTGFuZ3VhZ2UNCj5VUkw6 DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteGlhLW5haS1tb2Rl bGluZy1sYW5ndWFnZS0wMC50eHQNCj5TdGF0dXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQteGlhLW5haS1tb2RlbGluZy1sYW5ndWFnZS8NCj5IdG1saXplZDoNCj5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14aWEtbmFpLW1vZGVsaW5nLWxhbmd1YWdl LTAwDQo+DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgbW9k ZWxpbmcgbGFuZ3VhZ2UgdXNlZCB0byBtb2RlbCBuZXR3b3JrDQo+ICAgc2VydmljZXMgYnkgbmV0 d29yayBvcGVyYXRvcnMgYW5kIGN1c3RvbWVycyB0byBjcmVhdGUgc3BlY2lmaWMNCj4gICBuZXR3 b3JrIHNlcnZpY2UgaW5zdGFuY2VzIHRocm91Z2ggdGhlIHN0YW5kYXJkaXplZCBOZXR3b3JrIEFi c3RyYWN0DQo+ICAgSW50ZXJmYWNlIChOQUkpIGFuZCBwcm9jZXNzZWQgYXV0b21hdGljYWxseSBi eSB0aGUgbmV0d29yay4NCg== From adrian@olddog.co.uk Thu Feb 13 04:10: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 E5B341A020D for ; Thu, 13 Feb 2014 04:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 QOgMaJcFpCTd for ; Thu, 13 Feb 2014 04:10:32 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id D60101A0201 for ; Thu, 13 Feb 2014 04:10:28 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1DCAQLl032177; Thu, 13 Feb 2014 12:10:26 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1DCALWd032108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Feb 2014 12:10:24 GMT From: "Adrian Farrel" To: Date: Thu, 13 Feb 2014 12:10:20 -0000 Message-ID: <090201cf28b4$928b22d0$b7a16870$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8otF3aNRqfjO/KQDyv0/16I5UbDA== Content-Language: en-gb Cc: draft-farrkingel-pce-abno-architecture@tools.ietf.org Subject: [OPSAWG] Ops Area review of draft-farrkingel-pce-abno-architecture X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 12:10:34 -0000 Hi Ops Area Working Group, Dan and I have a little draft showing how a number of IETF components can be bundled together to provide application-based network operation. We think the draft is almost ready to be published as an RFC so we are calling for review and input. Comments on the list or direct to the authors at draft-farrkingel-pce-abno-architecture@tools.ietf.org Thanks! Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 13 February 2014 11:50 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrkingel-pce-abno-architecture-07.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A PCE-based Architecture for Application-based Network > Operations > Authors : Daniel King > Adrian Farrel > Filename : draft-farrkingel-pce-abno-architecture-07.txt > Pages : 62 > Date : 2014-02-13 > > Abstract: > Services such as content distribution, distributed databases, or > inter-data center connectivity place a set of new requirements on the > operation of networks. They need on-demand and application-specific > reservation of network connectivity, reliability, and resources (such > as bandwidth) in a variety of network applications (such as point-to- > point connectivity, network virtualization, or mobile back-haul) and > in a range of network technologies from packet (IP/MPLS) down to > optical. An environment that operates to meet this type of > requirement is said to have Application-Based Network Operations > (ABNO). > > ABNO brings together many existing technologies for gathering > information about the resources available in a network, for > consideration of topologies and how those topologies map to > underlying network resources, for requesting path computation, and > for provisioning or reserving network resources. Thus, ABNO may be > seen as the use of a toolbox of existing components enhanced with a > few new elements. The key component within an ABNO is the Path > Computation Element (PCE), which can be used for computing paths and > is further extended to provide policy enforcement capabilities for > ABNO. > > This document describes an architecture and framework for ABNO > showing how these components fit together. It provides a cookbook of > existing technologies to satisfy the architecture and meet the needs > of the applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-farrkingel-pce-abno-architecture-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/ > > _______________________________________________ > 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 From nobody Fri Feb 14 06:43:23 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 015E21A029C; Fri, 14 Feb 2014 06:43:19 -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 NSe5P8kwVWK3; Fri, 14 Feb 2014 06:43:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E831A0253; Fri, 14 Feb 2014 06:43:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214144317.22981.55352.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 06:43:17 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/LXjhMTuZouTUh1M3ySE2V7zNUho Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-extension-02.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: Fri, 14 Feb 2014 14:43:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : CAPWAP Extension for 802.11n and Power/channel Autoconfiguration Authors : Yifan Chen Dapeng Liu Hui Deng Lei Zhu Filename : draft-ietf-opsawg-capwap-extension-02.txt Pages : 15 Date : 2014-02-14 Abstract: CAPWAP binding for 802.11 is specified by RFC5416 and it was based on IEEE 802-11.2007 standard. After RFC5416 was published in 2009, there were several new amendments of 802.11 have been published. 802.11n is one of those amendments and it has been widely used in real deployment. This document extends the CAPWAP binding for 802.11 to support 802.11n and also defines a power and channel auto configuration extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-extension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-extension-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-extension-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/ From nobody Fri Feb 14 06:48: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 4B8FD1A029B for ; Fri, 14 Feb 2014 06:48:05 -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 8zqmQd69qIZA for ; Fri, 14 Feb 2014 06:48:00 -0800 (PST) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id D02201A02A3 for ; Fri, 14 Feb 2014 06:47:59 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id jx11so9949469veb.10 for ; Fri, 14 Feb 2014 06:47:58 -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=Yz0WIVIEIVSbAoiAXZFeP5jiRvb8kIO+RbyCcMcNvDI=; b=Mbb6YNzV3FGFKNc/Sfh/xKipsylrUswq9CB8kygkfXuis/2KPyK8raM8Tgp5gyVPR3 a+llzqgLJk65OLmVgUpZn3RXjkFCNaQv47TpnDMpfPckl7DdaYTIdANyugMSAdTM87bV LW1MujzTTohUNC3oX+h+/TTjEIj7fFMOEmw5aY8eKw46mGoDmSj/5m9wQhfTNIaDmkB8 jNb+FhlAwwJlGxK2URQU2moYrcNqH07CVz3Y3WLFpM7uctdyZaH9eRwIqycMIPsTXNbF Jb+z1c0r1rp6vP3dm8w44EKDWNQfxBIZG2vMuOZSWeiO+4yE4LyRaoon2Uy/pJ/3rWHv 5fdg== MIME-Version: 1.0 X-Received: by 10.53.10.137 with SMTP id ea9mr83156vdd.74.1392389278192; Fri, 14 Feb 2014 06:47:58 -0800 (PST) Received: by 10.221.24.146 with HTTP; Fri, 14 Feb 2014 06:47:58 -0800 (PST) In-Reply-To: <20140214144317.22981.55352.idtracker@ietfa.amsl.com> References: <20140214144317.22981.55352.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 22:47:58 +0800 Message-ID: From: Liu Dapeng To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=001a1134044c50da3c04f25ee4e0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/qR0j5b-6rJg8ltFz2NkC-ZTqAxk Subject: [OPSAWG] Fwd: I-D Action: draft-ietf-opsawg-capwap-extension-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: Fri, 14 Feb 2014 14:48:05 -0000 --001a1134044c50da3c04f25ee4e0 Content-Type: text/plain; charset=ISO-8859-1 Hello all, We have updated the capwap 802.11n extension draft. Any comments will be appreciated. Cheers, Dapeng Liu ---------- Forwarded message ---------- From: Date: 2014-02-14 22:43 GMT+08:00 Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-extension-02.txt To: i-d-announce@ietf.org Cc: opsawg@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : CAPWAP Extension for 802.11n and Power/channel Autoconfiguration Authors : Yifan Chen Dapeng Liu Hui Deng Lei Zhu Filename : draft-ietf-opsawg-capwap-extension-02.txt Pages : 15 Date : 2014-02-14 Abstract: CAPWAP binding for 802.11 is specified by RFC5416 and it was based on IEEE 802-11.2007 standard. After RFC5416 was published in 2009, there were several new amendments of 802.11 have been published. 802.11n is one of those amendments and it has been widely used in real deployment. This document extends the CAPWAP binding for 802.11 to support 802.11n and also defines a power and channel auto configuration extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-extension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-extension-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-extension-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/ _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg -- ------ Best Regards, Dapeng Liu --001a1134044c50da3c04f25ee4e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all,

We have updated the capwap 8= 02.11n extension draft. Any comments will be appreciated.

Cheers,
Dapeng Liu

----= ------ Forwarded message ----------
From: <internet-drafts@ietf.org>
= Date: 2014-02-14 22:43 GMT+08:00
Subject: [OPSAWG] I-D Action: draft-iet= f-opsawg-capwap-extension-02.txt
To: i-d-announce@ietf.org
C= c: opsawg@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Operations and Management Area Working = Group Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : CAPWAP Extension for 802.11n an= d Power/channel Autoconfiguration
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Yifan Chen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dapeng Liu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hui Deng
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Lei Zhu
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-opsawg-capwap-extensio= n-02.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 15
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-14

Abstract:
=A0 =A0CAPWAP binding for 802.11 is specified by RFC5416 and it was based o= n
=A0 =A0IEEE 802-11.2007 standard. =A0After RFC5416 was published in 2009, =A0 =A0there were several new amendments of 802.11 have been published.
=A0 =A0802.11n is one of those amendments and it has been widely used in =A0 =A0real deployment. =A0This document extends the CAPWAP binding for 802= .11
=A0 =A0to support 802.11n and also defines a power and channel auto
=A0 =A0configuration extension.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-= capwap-extension/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsawg-capwap-ext= ension-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-o= psawg-capwap-extension-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/

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



--

------
Best Regard= s,
Dapeng Liu
--001a1134044c50da3c04f25ee4e0-- From nobody Fri Feb 14 06:50: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 E7B3E1A022D for ; Fri, 14 Feb 2014 06:50:23 -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 Yg3wYB12LAb1 for ; Fri, 14 Feb 2014 06:50:20 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AC6571A0254 for ; Fri, 14 Feb 2014 06:50:20 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id uy5so14108022obc.33 for ; Fri, 14 Feb 2014 06:50: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=E8HSgUpY+ERr6lEGvGRctY6uYH3i32WJnXAXm+ZAqOQ=; b=dpt3nvx1JBpP26DzgkDLrhAnnaPvbvyOkxoy9Cfs8G+m7Pj4+njiZPVM0ufLS6nnSZ JLivMN7plgmsL4JCefcGOvNV/DweFkAD/27CeG21Zb3/ARy3u0PJy5o9jfyi1+t5W+HA aVfag6TzK0gxk138nNG1liEda1JBW4twpj1XKdtIpynSxpo2JHIakJ5uOtx6L+4/PYvm tjSjVxry7RGymKn3CcCIWk8WQbEEm+kMsnAtliYIi1NXAyxSdBDbFdtgGhtq5dOuV6z3 7fChjSGJ9vFH12fMxSRaJpFhgeR11kaYze14PZxkLrYIiisD2UBhJGEpfYrroTs+ITxK QP2g== MIME-Version: 1.0 X-Received: by 10.60.161.37 with SMTP id xp5mr6847679oeb.31.1392389419020; Fri, 14 Feb 2014 06:50:19 -0800 (PST) Received: by 10.221.24.146 with HTTP; Fri, 14 Feb 2014 06:50:18 -0800 (PST) In-Reply-To: <527BA53B.30507@gmail.com> References: <527BA53B.30507@gmail.com> Date: Fri, 14 Feb 2014 22:50:18 +0800 Message-ID: From: Liu Dapeng To: Tom Taylor Content-Type: multipart/alternative; boundary=089e0118475ab61aec04f25eecee Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Qe64KLbCvlS-sSQn-TCzy9g4jEc Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Review of draft-ietf-opsawg-capwap-extension-01: Section 4.2 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, 14 Feb 2014 14:50:24 -0000 --089e0118475ab61aec04f25eecee Content-Type: text/plain; charset=ISO-8859-1 Hello Tom, Thanks a lot for your review and comments. We submit a new version to address your comments. Please kind help to review.' http://tools.ietf.org/html/draft-ietf-opsawg-capwap-extension-02 Cheers, Dapeng Liu 2013-11-07 22:35 GMT+08:00 Tom Taylor : > Section 4.2 of draft-ietf-opsawg-capwap-extension-01 defines the 802.11n > Radio Configuration message element. I have some comments here: > > (1) Wouldn't this element appear in the CAPWAP Configuration Update > Response message as well as the Request? > > (2) What are A-MSDU, A-MPDU? Need a little explanation. Similarly, what is > MCS, and what is the difference between maximal supported and maximal > mandatory MCS? > > (3) Are the antennae all the same, so ordering does not matter, or do > particular bits correspond to particular uniquely identifiable antennae. > > Tom Taylor > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- ------ Best Regards, Dapeng Liu --089e0118475ab61aec04f25eecee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Tom,

Thanks a lot for your review= and comments.

We submit a new version to address = your comments. Please kind help to review.'

= http://tools.ietf.org/html/draft-ietf-opsawg-capwap-extension-02

Cheers,
Dapeng Liu


2013-11-07 22:35 GMT+0= 8:00 Tom Taylor <tom.taylor.stds@gmail.com>:
Section 4.2 of draft-ietf-opsawg-capwap-<= /u>extension-01 defines the 802.11n Radio Configuration message element. I = have some comments here:

(1) Wouldn't this element appear in the CAPWAP Configuration Update Res= ponse message as well as the Request?

(2) What are A-MSDU, A-MPDU? Need a little explanation. Similarly, what is = MCS, and what is the difference between maximal supported and maximal manda= tory MCS?

(3) Are the antennae all the same, so ordering does not matter, or do parti= cular bits correspond to particular uniquely identifiable antennae.

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



--
------
Best Regards,
Dapeng Liu
--089e0118475ab61aec04f25eecee-- From nobody Fri Feb 14 06:53: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 CF0641A0273 for ; Fri, 14 Feb 2014 06:53:27 -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 LQD5KTE302yQ for ; Fri, 14 Feb 2014 06:53:25 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DB4CA1A022D for ; Fri, 14 Feb 2014 06:53:24 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so9537811vcb.3 for ; Fri, 14 Feb 2014 06:53:23 -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=5EQVOlteIWfebhlAzzBcJQyR3gvro51/85alkvkH9Q8=; b=dz/sxZ0MiBUq/qy4CeVLr/wOOgjBDWTVm95c9AV37RwVcPa8RQGVFBU0tbfNAeeRg8 rVDGG36g6PW2FI3lTPgiKEOxMkaRuPZmqte5gkPSkWKjZweW2L58IQv0fB9CGuYe1c93 04THRK08vyK5LpM1Mcra/uEQPrmrxcyR/QTcyHuJXCSLOD+6myVXdF+jf58eFuGA3+mr cuSeJ1aXBjZMawsm0HEz2Wc+QYLRGQNS1XHcVNes+fojygeV1Kuz4aNMQANA9Pb5x6M6 di3r4pbQ4mhnsowIix6Zt+9qubpxPm9sHGC0BaV8MT5M/08og3UH/M5S+lXqEExMlB0c dDaA== MIME-Version: 1.0 X-Received: by 10.52.230.105 with SMTP id sx9mr4870890vdc.10.1392389603259; Fri, 14 Feb 2014 06:53:23 -0800 (PST) Received: by 10.221.24.146 with HTTP; Fri, 14 Feb 2014 06:53:23 -0800 (PST) In-Reply-To: <527C2211.2010005@gmail.com> References: <527C2211.2010005@gmail.com> Date: Fri, 14 Feb 2014 22:53:23 +0800 Message-ID: From: Liu Dapeng To: Tom Taylor Content-Type: multipart/alternative; boundary=089e0111da1eb0fbc404f25ef7c0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/3tUBkHxL-EVlTMBReGl4MFXs3BM Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WTP scan process in draft-ietf-opsawg-capwap-extension-01 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, 14 Feb 2014 14:53:28 -0000 --089e0111da1eb0fbc404f25ef7c0 Content-Type: text/plain; charset=ISO-8859-1 Dear Tom, We have submitted a new version of the draft and it address your comments here. Could you kind help to review it? http://tools.ietf.org/html/draft-ietf-opsawg-capwap-extension-02 Thanks, Dapeng Liu 2013-11-08 7:28 GMT+08:00 Tom Taylor : > I'm not clear on the description of scan only mode. Is it correct that the > WTP provides no service to stations when operating in this as opposed to > active mode? If so, setting PrimeChnlSrvTime to 0 makes sense, but there > should also be an explicit statement that no service is provided. If not, > it makes no sense to set PrimeChnlSrvTime to 0. > > Follow-up question: if no service is provided, is that true until the WTP > is reconfigured, or only until scanning is complete? > > Tom Taylor > -- ------ Best Regards, Dapeng Liu --089e0111da1eb0fbc404f25ef7c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Tom,

We have submitted a new versi= on of the draft and it address your comments here. Could you kind help to r= eview it?


Thanks,
Dapeng Liu


2013-11-08 7:28 GMT+08= :00 Tom Taylor <tom.taylor.stds@gmail.com>:
I'm not clear on the description of scan= only mode. Is it correct that the WTP provides no service to stations when= operating in this as opposed to active mode? If so, setting PrimeChnlSrvTi= me to 0 makes sense, but there should also be an explicit statement that no= service is provided. If not, it makes no sense to set PrimeChnlSrvTime to = 0.

Follow-up question: if no service is provided, is that true until the WTP i= s reconfigured, or only until scanning is complete?<= font color=3D"#888888">

Tom Taylor



--
------
Best Regards,
Dapeng Liu
--089e0111da1eb0fbc404f25ef7c0-- From nobody Fri Feb 14 10:02: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 384421A037C for ; Fri, 14 Feb 2014 10:02:25 -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 EDkwNuLpuV1H for ; Fri, 14 Feb 2014 10:02:23 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 652501A0373 for ; Fri, 14 Feb 2014 10:02:22 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w62so9109107wes.1 for ; Fri, 14 Feb 2014 10:02:20 -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=SP0XRoIAqqABHDnzLT452QIR4hmOjPgWBKpaoFQIYYQ=; b=HyJrhbXyw4iZhrFXEcff6ycS/2FjZrp1/l616yVLByrunP/88A0BLaa9ByIC/hXMwe WjrI6+qGYHaFGBq8Nu1s14jOAB36agjdjfg2nSH+YxUvX0Y+BLOXpDOtnCHkCFhxre0r wQDY7Lv1oViEzaCjAKcy2Clth7kzvQbwdJPmQQarN3NoJzx2egDGqTGcVLpLBd1qEC3B Xv5h5MwsIhgDImdeVjWj5d7JyzYzoeyifpQpuE/YnwzTeSQouCHqQrYAigP9JIq8X8Dd vgs23Ki23YrQwe8OXKM7SZkgQSsxTONXMDJNdX8MsBSjhgC1UeLbZhJEcuXX0Mv94zG9 VFMQ== X-Gm-Message-State: ALoCoQloPlyQllygue3dYfKBTwjA6Qm1Y9uOb5LGDhs2XfhDdfnnIKovMSvoRMrvxv2Qpz66Reg1 MIME-Version: 1.0 X-Received: by 10.194.86.130 with SMTP id p2mr726161wjz.88.1392400940298; Fri, 14 Feb 2014 10:02:20 -0800 (PST) Received: by 10.194.54.167 with HTTP; Fri, 14 Feb 2014 10:02:20 -0800 (PST) X-Originating-IP: [68.142.29.242] Date: Fri, 14 Feb 2014 13:02:20 -0500 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ZXz5s9SBjggO3fYf-gwLlXlUOoU Subject: [OPSAWG] Preliminary OPSAWG agenda. 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, 14 Feb 2014 18:02:25 -0000 Dear OpsAWG. Here is the preliminary schedule for the OpsAWG meeting at IETF 89 in London. Our meeting is currently scheduled for 1610-1840 GMT on Tuesday. Please come prepared, by having read the drafts, and armed with questions/ comments. We *do* still have a small amount of agenda time, please know if you have any issues you'd like to discuss / present, but remember -- you need to have had some (on-list!) discussions to qualify for this special, limited time offer... Thanks, Your friendly OpsAWG chairs... Joint OpsAWG / Ops-Area ====================== Ops Area, by the OpsADs -------------------------------------------- Including such things as (non-authorative!): Invited talk on operational considerations in pervasive monitoring Stephen Farrell - 20 minutes. draft-winter-opsawg-eap-metadata-00 Discuss the SNMPSet vs YANG statement. Benoit Claise. OpsAWG: ------------------ Administrivia. including Draft status updates, etc. OpsAWG chairs - 10 minutes. Update on ETSI NFV Management & Orchestration WG Ersue, Mehmet - 10 minutes Network Configuration Negotiation Problem Statement and Requirements draft-jiang-config-negotiation-ps Brian Carpenter - 15 minutes. The COMAN drafts: draft-ersue-opsawg-coman-probstate-reqs-00 draft-ersue-opsawg-coman-use-cases-00 Ersue, Mehmet - 15 minutes. The CAPWAP drafts: Comments/discussion on draft-ietf-opsawg-capwap-hybridmac Comments/discussion on draft-zhang-opsawg-capwap-cds-01 Rajesh Pazhyannur - 15 minutes. From nobody Fri Feb 14 12:20: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 1CAFE1A0354; Fri, 14 Feb 2014 12:20:03 -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 uZqEu22mqd62; Fri, 14 Feb 2014 12:20:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DC01A02C0; Fri, 14 Feb 2014 12:20:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214202000.26517.64220.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 12:20:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/c7rhF-xbYNFNLZnQHC0IAqzHBBw Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-hybridmac-02.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: Fri, 14 Feb 2014 20:20:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : IEEE 802.11 MAC Profile for CAPWAP Authors : Chunju Shao Hui Deng Rajesh S. Pazhyannur Farooq Bari Rong Zhang Satoru Matsushima Filename : draft-ietf-opsawg-capwap-hybridmac-02.txt Pages : 10 Date : 2014-02-14 Abstract: CAPWAP defines two entities Wireless Transmission Point (WTP) and Access Controller (AC). CAPWAP also defines two MAC (Medium Access Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For each MAC mode, CAPWAP describes how the MAC functionality is split between the WTP and AC. However, certain functions have not been clearly defined. For example for the Split MAC mode, the IEEE 802.11 encryption is specified as located in either the AC or the WTP with no clear way for the AC to inform the WTP where it should be. This lack of specification leads to interoperability especially when AC and WTP come from different vendors. To solve the problem, this specification defines a IEEE 802.11 MAC profile where each profile specifies an unambigous division of functionality between the WTP and AC. The IEEE 802.11 MAC profile is used as follows: The WTP informs the AC of the supported profiles during the discovery or join process and the AC configures the WTP with one of the supported profiles while configuring a WLAN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-hybridmac-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-hybridmac-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/ From nobody Fri Feb 14 13:55:01 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 5829E1A0456; Fri, 14 Feb 2014 13:54:46 -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 cx9iMNGTjcLe; Fri, 14 Feb 2014 13:54:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF171A041E; Fri, 14 Feb 2014 13:54:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214215440.20572.26481.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 13:54:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Lz_qh1gQqTUkCdv7gx_3RuZdq9g Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-coman-probstate-reqs-01.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: Fri, 14 Feb 2014 21:54:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Management of Networks with Constrained Devices: Problem Statement and Requirements Authors : Mehmet Ersue Dan Romascanu Juergen Schoenwaelder Filename : draft-ietf-opsawg-coman-probstate-reqs-01.txt Pages : 52 Date : 2014-02-14 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-coman-probstate-reqs-01 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 nobody Fri Feb 14 14:03:45 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 5467A1A0047; Fri, 14 Feb 2014 14:03:38 -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 COz-XrIoIW_I; Fri, 14 Feb 2014 14:03:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E841A0013; Fri, 14 Feb 2014 14:03:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214220334.23614.85336.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 14:03:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/HSIaT3JAuGvFoxmB5H5iO70FyHs Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-coman-use-cases-01.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: Fri, 14 Feb 2014 22:03:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Management of Networks with Constrained Devices: Use Cases Authors : Mehmet Ersue Dan Romascanu Juergen Schoenwaelder Anuj Sehgal Filename : draft-ietf-opsawg-coman-use-cases-01.txt Pages : 30 Date : 2014-02-14 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-coman-use-cases-01 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 nobody Fri Feb 14 14:08:58 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 57F431A0028 for ; Fri, 14 Feb 2014 14:08:56 -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 1Dmp5rOB-ZUU for ; Fri, 14 Feb 2014 14:08:53 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 84D321A00FA for ; Fri, 14 Feb 2014 14:08:53 -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 s1EM8n11029845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 23:08:49 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1EM8nbj026527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 23:08:49 +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; Fri, 14 Feb 2014 23:08:49 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 23:08:48 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "opsawg@ietf.org" Thread-Topic: Coman drafts for IETF #89 Thread-Index: Ac8p0VUtKVphwRZfQW++2bo3iL2dyg== Date: Fri, 14 Feb 2014 22:08:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.123] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8288E13DEMUMBX005nsnintr_" 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: 2549 X-purgate-ID: 151667::1392415729-000025D0-5903D18E/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/l3UM4jjO4WcrlRcF4KLvyFQu3zA Subject: [OPSAWG] Coman drafts for IETF #89 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, 14 Feb 2014 22:08:56 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8288E13DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, we submitted the two Coman drafts for IETF #89. Your comments are appreciated. Management of Networks with Constrained Devices: Problem Statement and Requ= irements http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-01 Management of Networks with Constrained Devices: Use Cases http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-01 Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F8288E13DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
we submitted the two Coman drafts for IETF #89.
Your comments are appreciated.
 
Management of Networks with Constrained Devices: Problem Statement and= Requirements
 
Management of Networks with Constrained Devices: Use Cases
 
Regards,
Mehmet
 
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F8288E13DEMUMBX005nsnintr_-- From nobody Fri Feb 14 17:20:52 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 452111A0015 for ; Fri, 14 Feb 2014 17:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 JfvPzdRz216P for ; Fri, 14 Feb 2014 17:20:44 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 5BACC1A0012 for ; Fri, 14 Feb 2014 17:20:44 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WETvt-0003Ez-FG; Sat, 15 Feb 2014 01:20:42 +0000 Date: Sat, 15 Feb 2014 10:20:40 +0900 Message-ID: From: Randy Bush To: Warren Kumari In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Z1nLchX0O_bVIqc50mdnWKiPL3U Cc: opsawg Subject: Re: [OPSAWG] Preliminary OPSAWG agenda. 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, 15 Feb 2014 01:20:46 -0000 warren and any other friendly opsawg chairs: i have been told that you are actually wasting air time discussing snmp write for configuration of devices. i thought we had and finished that discussion over a decade ago at ietf 51 in london. we were in a large room with many operators, and i asked all those operators who had snmp write enabled to raise their hands. zero, count them zero, hands went up. this resulted in the formation of the interminable netconf effort. and i have the tee shirt, see just because we're going to be back in london does not mean we need to replay history. randy From nobody Fri Feb 14 18:53:18 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 C47FA1A0026 for ; Fri, 14 Feb 2014 18:53:16 -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 m7ej0ymui3Hr for ; Fri, 14 Feb 2014 18:53:15 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 200601A0054 for ; Fri, 14 Feb 2014 18:53:15 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so12974760pad.41 for ; Fri, 14 Feb 2014 18:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pTXeZ4NFdkIGge8D0H51QKL8EOOI5ffKc8TK1YcOVGU=; b=b7m6Ack0rX8/0SRfk3QO3EUEggZYp2mpZfw25Ono5cwMDy1VezxQ3h/2ei8CJ3VbcG 8QpawIrm0JTuon1FBBK+uurprDhpkn+QdrMJvX4GDKiyGEenb9IUUJLY14hdsQOSOqym mIZCzRp6CrANG7Ax2WoS0lxGS1c4ILnVnc9jIBlorQJuWqDKfrFzXzhQIWeEmLcs9gP2 Iv5dGEumIEWRJjhZwumd2/eKv+IStlPfXxI5NW/3HCgI2AXUqMZmFbV1gJEYfNpKANkl BcN83EiiPs08G4KDBg+tuzYur55G1jAFhwfeavgK6mBGxIFHeR7f3l34ev+LRv9pC/fF 3ytw== X-Received: by 10.68.223.9 with SMTP id qq9mr13007963pbc.58.1392432792746; Fri, 14 Feb 2014 18:53:12 -0800 (PST) Received: from spandex.local (216-67-29-177-rb2.sol.dsl.dynamic.acsalaska.net. [216.67.29.177]) by mx.google.com with ESMTPSA id y9sm54913733pas.10.2014.02.14.18.53.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 18:53:11 -0800 (PST) Message-ID: <52FED695.4030700@gmail.com> Date: Fri, 14 Feb 2014 17:53:09 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: opsawg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/mtuJvsq0K7jh88DN-RdAbha9Pns Subject: Re: [OPSAWG] Preliminary OPSAWG agenda. 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, 15 Feb 2014 02:53:17 -0000 On 2/14/14 4:20 PM, Randy Bush wrote: > i have been told that you are actually wasting air time discussing snmp > write for configuration of devices. i thought we had and finished that > discussion over a decade ago at ietf 51 in london. My understanding of the situation (and I could be wrong) is that someone recently did develop a spec in which they used SNMP to write to devices. I believe the intent behind putting it on the agenda is to say "Don't do that" and provide a reminder of why not. Personally, I wish someone had set out those guidelines before we made the decision to use SNMP for midcom a decade ago. Melinda From nobody Fri Feb 14 19:48: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 76E3E1A0005 for ; Fri, 14 Feb 2014 19:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 5Ue1RNKT0gMy for ; Fri, 14 Feb 2014 19:48:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4BB1A0004 for ; Fri, 14 Feb 2014 19:48:51 -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 BBD64767; Sat, 15 Feb 2014 03:48:49 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 03:48:43 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 03:48:48 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 11:48:41 +0800 From: Bert Greevenbosch To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] comments resolution for draft-ietf-opsawg-coman-probstate-reqs-00 Thread-Index: Ac8ihZYGxDYxy3H1TMuOOruN9Q9BBwDf4XngAAAEY0AAEz8qwADqsbmg Date: Sat, 15 Feb 2014 03:48:41 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E3FF23A@SZXEMA510-MBX.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63E3F5121@SZXEMA510-MBX.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63E3F51F4@SZXEMA510-MBX.china.huawei.com> <9904FB1B0159DA42B0B887B7FA8119CA2E3F5DDF@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E3F5DDF@AZ-FFEXMB04.global.avaya.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/7Tw1jb9m0x_vnWrzeeSlUL2COH4 Subject: Re: [OPSAWG] comments resolution for draft-ietf-opsawg-coman-probstate-reqs-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, 15 Feb 2014 03:48:54 -0000 SGkgRGFuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2UuIFBsZWFzZSBmaW5kIG15IGFu c3dlcnMgaW5saW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQpCZXJ0DQoNCg0KPiA+ID4gKEJHMTMpIFNl Y3Rpb24gMy4zLCByZXEgNC4zLjAwMzogdGhlIGRlc2NyaXB0aW9uIHNob3VsZCBiZSBtb3JlDQo+ ID4gPiB2ZXJib3NlIGFuZCBleHBsaWNpdC4NCj4gPiA+DQo+ID4gPiBQUk9QT1NFRCBSRVNPTFVU SU9OOiByZWplY3Qg4oCTIHdoYXQgaXMgbWlzc2luZz8NCj4gPg0KPiA+IFRoZSByZWxhdGVkIHJl cXVpcmVtZW50IGN1cnJlbnRseSBoYXMgdGhlIGZvbGxvd2luZyB3b3JkaW5nOg0KPiA+DQo+ID4g IlByb3ZpZGUgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50IHdpdGggYXN5bmNocm9ub3VzIHRyYW5z YWN0aW9uDQo+IHN1cHBvcnQuDQo+ID4gQ29uZmlndXJhdGlvbiBvcGVyYXRpb25zIG11c3Qgc3Vw cG9ydCBhIHRyYW5zYWN0aW9uYWwgbW9kZWwsIHdpdGgNCj4gPiBhc3luY2hyb25vdXMgaW5kaWNh dGlvbnMgdGhhdCB0aGUgdHJhbnNhY3Rpb24gd2FzIGNvbXBsZXRlZC4iDQo+ID4NCj4gPiBJIGd1 ZXNzIG15IG1haW4gaXNzdWUgd2l0aCB0aGlzIGlzLCB0aGF0IEkgZG9uJ3QgcmVhbGx5IGtub3cg d2hhdA0KPiBleGFjdGx5IGlzDQo+ID4gbWVhbnQgYnkgYW4gImFzeW5jaHJvbm91cyB0cmFuc2Fj dGlvbiIgKGFzIGl0IGNvdWxkIGJlIHF1aXRlIGJyb2FkKS4NCj4gSXMgaXQganVzdA0KPiA+IGEg ZGVsYXllZCByZXNwb25zZS9hY2tub3dsZWRnZW1lbnQ/IE9yIGlzIGl0IHNvbWV0aGluZyBsaWtl IGEgdHJhcCwNCj4gd2hpY2gNCj4gPiBzZW5kcyBmZWVkYmFjayB3aGVuZXZlciBhbiBldmVudCBo YXBwZW5zPw0KPiA+DQo+IA0KPiBJdCBpcyB0aGUgbGF0ZXIuIFdvdWxkIGl0IGhlbHAgaWYgd2Ug Y2xhcmlmeSBieSBtYWtpbmcNCj4gDQo+IHMvYXN5bmNocm9ub3VzIHRyYW5zYWN0aW9uL2FzeW5j aHJvbm91cyAoZXZlbnQtZHJpdmVuKSB0cmFuc2FjdGlvbi8gPw0KDQpIb3cgYWJvdXQgYWRkaW5n ICIoZS5nLiB0cmFwcyBpbiBTTk1QKSI/DQoNCj4gPiA+IChCRzE0KSBTZWN0aW9uIDMuMywgcmVx IDQuMy4wMDM6IHdoeSBkb2VzIHRoZSByZXF1aXJlbWVudCBub3QgYXBwbHkNCj4gdG8NCj4gPiA+ IEMwIGRldmljZXM/IFRoZXkgbWF5IGJlIHNsZWVweSBhbmQgdGh1cyByZXF1aXJlIGFzeW5jaHJv bm91cw0KPiA+ID4gdHJhbnNhY3Rpb25zLg0KPiA+ID4NCj4gPiA+IFBST1BPU0VEIFJFU09MVVRJ T046IHJlamVjdCDigJMgd2UgZG8gbm90IGJlbGlldmUgcm9sbGJhY2sgY2FuIGJlDQo+ID4gPiBp bXBsZW1lbnRlZCBvbiBDMCBkZXZpY2VzDQoNCkhtbSwgc3RpbGwgYSBiaXQgY29uZnVzZWQuIEFz IGZhciBhcyBJIGNhbiBzZWUsIHRoZSByZXF1aXJlbWVudCBkb2Vzbid0IHNheSBhbnl0aGluZyBh Ym91dCByb2xsYmFjay4gTWF5YmUgSSBhbSBtaXNzaW5nIHRoYXQgaXQgaXMgaW1wbGllZCBzb21l d2hlcmU/DQoNCkZvciB0cmFwcywgSSB0aGluayBjb25zdHJhaW5lZCBkZXZpY2VzIHdvdWxkIGJl IHdlbGwgYWJsZSB0byBkbyB0aGlzLiBJbiB0aGUgQ29NSSBkcmFmdCB3ZSBwcm92aWRlIHN1Y2gg ZnVuY3Rpb25hbGl0eSB1c2luZyBDb0FQJ3Mgb2JzZXJ2ZSBtZWNoYW5pc20uDQoNCldoYXQgZG8g eW91IHRoaW5rPw0KDQo+ID4gUmVsYXRlZCB0byBCRzEzLiBUaGlzIHdvdWxkIGJlIG1vcmUgZXZp ZGVudCB3aGVuICJhc3luY2hyb25vdXMNCj4gPiB0cmFuc2FjdGlvbnMiIHdlcmUgcHJvcGVybHkg ZGVmaW5lZC4NCj4gPg0KPiA+ID4gKEJHMTYpIFNlY3Rpb24gMy40LCByZXEgNC40LjAwNCBpcyBt YXJrZWQgYXMgImxvdyBwcmlvcml0eSIuIElzbid0DQo+ID4gPiBuZXR3b3JrIHN0YXR1cyBtb25p dG9yaW5nIGEgbWFqb3IgdXNlLWNhc2U/DQo+ID4gPg0KPiA+ID4gUFJPUE9TRUQgUkVTT0xVVElP TjogcmVqZWN0IOKAkyB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgY29tcHV0ZWQNCj4gPiA+IG5l dHdvcmsgc3RhdHVzDQo+IA0KPiA+IFRoZSBkZXNjcmlwdGlvbiBjdXJyZW50bHkgaXMgYXMgZm9s bG93czoNCj4gPg0KPiA+ICJQcm92aWRlIGEgbW9uaXRvcmluZyBmdW5jdGlvbiB0byBjb2xsZWN0 IGFuZCBleHBvc2UgaW5mb3JtYXRpb24NCj4gcmVsYXRlZCB0bw0KPiA+IHRoZSBzdGF0dXMgb2Yg YSBuZXR3b3JrIG9yIG5ldHdvcmsgc2VnbWVudHMgY29ubmVjdGVkIHRvIHRoZQ0KPiBpbnRlcmZh Y2Ugb2YNCj4gPiB0aGUgZGV2aWNlLiINCj4gPg0KPiA+IEkgdW5kZXJzdGFuZCB0aGF0IHlvdSBt ZWFuIHRoYXQgdGhlIGluZm9ybWF0aW9uIG9mIHRoZSBuZXR3b3JrIGlzDQo+ID4gcHJvY2Vzc2Vk LCBhbmQgZXhwb3NpbmcgaW5mb3JtYXRpb24gZG9lcyBub3QgY29uY2VybiBqdXN0IHRoZSByYXcN Cj4gPiBpbmZvcm1hdGlvbj8gQXMgYW4gZXhhbXBsZTogYSBjb3VudGVyIHRoYXQgY291bnRzIHRo ZSBpbmNvbWluZyBhbmQNCj4gPiBvdXRnb2luZyBVRFAgcGFja2V0cyBzZWVtcyBzaW1wbGUgZW5v dWdoIGZvciBDMCBkZXZpY2VzLiBCdXQNCj4gY29sbGVjdGluZw0KPiA+IHRoZXNlIGNvdW50ZXJz IGZyb20gc2V2ZXJhbCBkZXZpY2VzIGFuZCB0aGVuIGNhbGN1bGF0ZSBzb21lDQo+IHN0YXRpc3Rp Y3MgbWF5DQo+ID4gaW5kZWVkIGJlIG1vcmUgY29tcGxpY2F0ZWQuDQo+ID4NCj4gPiBJZiB0aGlz IGlzIHdoYXQgaXMgbWVhbnQsIG1heWJlIHRoZSBkZXNjcmlwdGlvbiBjb3VsZCByZWZsZWN0IHRo aXMsDQo+IGUuZy4gYnkNCj4gPiBhZGRpbmcgImFuYWx5c2UiIGFzIGZvbGxvd3M6DQo+ID4NCj4g PiBORVc6DQo+ID4NCj4gPiAiUHJvdmlkZSBhIG1vbml0b3JpbmcgZnVuY3Rpb24gdG8gY29sbGVj dCwgYW5hbHlzZSBhbmQgZXhwb3NlDQo+IGluZm9ybWF0aW9uDQo+ID4gcmVsYXRlZCB0byB0aGUg c3RhdHVzIG9mIGEgbmV0d29yayBvciBuZXR3b3JrIHNlZ21lbnRzIGNvbm5lY3RlZCB0bw0KPiB0 aGUNCj4gPiBpbnRlcmZhY2Ugb2YgdGhlIGRldmljZS4iDQo+IA0KPiBGaW5lIHdpdGggbWUgd2l0 aCB0aGUgZXhjZXB0aW9uIHRoYXQgbXkgc3BlbGxlciBhc2tzIHRvIHdyaXRlIGFuYWx5emUNCj4g d2l0aCBhbiAneicuDQoNCk9LLCBwbGVhc2UgdXNlIHRoZSAneicuIDotKQ0K From nobody Fri Feb 14 23:31:56 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 783C71A009E for ; Fri, 14 Feb 2014 23:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 aD4Pets0CIpQ for ; Fri, 14 Feb 2014 23:31:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D886F1A0089 for ; Fri, 14 Feb 2014 23:31:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDP55424; Sat, 15 Feb 2014 07:31:50 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 07:31:44 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 07:31:48 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.75]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 15:31:39 +0800 From: Xiayinben To: Warren Kumari , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Preliminary OPSAWG agenda. Thread-Index: AQHPKa8fNAqqkpostUaSZF0hp8ORfZq151cQ Date: Sat, 15 Feb 2014 07:31:38 +0000 Message-ID: <5FD31D8EDBF4EC468B36D86F04FDB2E82D8471CE@nkgeml507-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.52.208] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/1TCoWiuV1_NBc5NJ04ZiWcEW2j8 Subject: [OPSAWG] =?gb2312?b?tPC4tDogIFByZWxpbWluYXJ5IE9QU0FXRyBhZ2VuZGEu?= 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, 15 Feb 2014 07:31:55 -0000 SGkgV2FycmVuIGFuZCBhbGwsDQoNCldlIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBhbiAxNSBvciAy MC1taW51dGUgc2xvdCBmb3IgaW50cm9kdWNpbmcgYW4gcHJvcG9zYWwgYWJvdXQgaG93IHRvIHNp bXBsaWZ5IHRoZSBvcGVyYXRpb24gb2YgbmV0d29yayBmcm9tIG5ldHdvcmsgc2VydmljZXMgbGF5 ZXIgYW5kIGN1c3RvbWl6ZSBvcGVyYXRpb24gaW50ZXJmYWNlcyBieSBuZXR3b3JrIGFkbWluaXN0 cmF0b3JzLg0KV2UgaGFkIHByb3Bvc2UgYSBjdXN0b21pemFibGUgTmV0d29yayBBYnN0cmFjdCBJ bnRlcmZhY2UgKE5BSSkgYXJjaGl0ZWN0dXJlIGJhc2VkIG9uIG1vZGVsaW5nIGxhbmd1YWdlIHdo aWNoIGlzIGludHJvZHVjZWQgaW4gZHJhZnQteGlhLWN1c3RvbWl6YWJsZS1uYWktYXJjaC0wMC4g VGhlIE5BSSBwcm92aWRlIGFic3RyYWN0ZWQgbmV0d29yayBpbmZvcm1hdGlvbiBhbmQgY2FwYWJp bGl0eSB0byBuZXR3b3JrIGN1c3RvbWVycyBhbmQgcmVjZWl2ZSBjdXN0b21pemVkIG9yZGVycyBm cm9tIHRoZW0uIEl0IGFsbG93cyB0aGVpciBjdXN0b21lcnMgdG8gY3VzdG9taXplIHRoZWlyIG93 biBuZXR3b3JrIHNlcnZpY2VzIGFzIHRoZXkgbmVlZC4NCg0KSXQgd2lsbCBiZSBwcmVzZW50ZWQg YnkgbXkgY28tYXV0aG9yIFNoZW5nIEppYW5nLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCllpbmJlbiBh bmQgU2hlbmcNCg0KDQrPxCDS+iDq2g0KWWluIEJlbiwgWGlhIChQaC5ELikgDQoiSW5zaWdodCAm IFZpc2lvbiIgDQoNCg0KDQpBZGRyZXNzOiBLdWlLZSBCdWlsZGluZywgTm8uOSBYaW54aSBSZC4s U2hhbmctRGkgSW5mb3JtYXRpb24gSW5kdXN0cnkgQmFzZSxIYWktRGlhbiBEaXN0cmljdA0KQmVp amluZyAxMDAwODUgUC5SLiBDaGluYQ0KVGVsOiA4NjEwNjA2MTAwMTYNCg0KDQoNCg0KLS0tLS3T yrz+1K28/i0tLS0tDQq3orz+yMs6IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYu b3JnXSC0+rHtIFdhcnJlbiBLdW1hcmkNCreiy83KsbzkOiAyMDE0xOoy1MIxNcjVIDI6MDINCsrV vP7Iyzogb3BzYXdnQGlldGYub3JnDQrW98ziOiBbT1BTQVdHXSBQcmVsaW1pbmFyeSBPUFNBV0cg YWdlbmRhLg0KDQpEZWFyIE9wc0FXRy4NCg0KSGVyZSBpcyB0aGUgcHJlbGltaW5hcnkgc2NoZWR1 bGUgZm9yIHRoZSBPcHNBV0cgbWVldGluZyBhdCBJRVRGIDg5IGluIExvbmRvbi4NCk91ciBtZWV0 aW5nIGlzIGN1cnJlbnRseSBzY2hlZHVsZWQgZm9yIDE2MTAtMTg0MCBHTVQgb24gVHVlc2RheS4N Cg0KUGxlYXNlIGNvbWUgcHJlcGFyZWQsIGJ5IGhhdmluZyByZWFkIHRoZSBkcmFmdHMsIGFuZCBh cm1lZCB3aXRoIHF1ZXN0aW9ucy8gY29tbWVudHMuDQoNCldlICpkbyogc3RpbGwgaGF2ZSBhIHNt YWxsIGFtb3VudCBvZiBhZ2VuZGEgdGltZSwgcGxlYXNlIGtub3cgaWYgeW91IGhhdmUgYW55IGlz c3VlcyB5b3UnZCBsaWtlIHRvIGRpc2N1c3MgLyBwcmVzZW50LCBidXQgcmVtZW1iZXIgLS0geW91 IG5lZWQgdG8gaGF2ZSBoYWQgc29tZSAob24tbGlzdCEpIGRpc2N1c3Npb25zIHRvIHF1YWxpZnkg Zm9yIHRoaXMgc3BlY2lhbCwgbGltaXRlZCB0aW1lIG9mZmVyLi4uDQoNClRoYW5rcywNCllvdXIg ZnJpZW5kbHkgT3BzQVdHIGNoYWlycy4uLg0KDQoNCkpvaW50IE9wc0FXRyAvIE9wcy1BcmVhDQo9 PT09PT09PT09PT09PT09PT09PT09DQpPcHMgQXJlYSwgYnkgdGhlIE9wc0FEcw0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkluY2x1ZGluZyBzdWNoIHRoaW5n cyBhcyAobm9uLWF1dGhvcmF0aXZlISk6DQpJbnZpdGVkIHRhbGsgb24gb3BlcmF0aW9uYWwgY29u c2lkZXJhdGlvbnMgaW4gcGVydmFzaXZlIG1vbml0b3JpbmcgU3RlcGhlbiBGYXJyZWxsIC0gMjAg bWludXRlcy4NCg0KZHJhZnQtd2ludGVyLW9wc2F3Zy1lYXAtbWV0YWRhdGEtMDANCg0KRGlzY3Vz cyB0aGUgU05NUFNldCB2cyBZQU5HIHN0YXRlbWVudC4NCkJlbm9pdCBDbGFpc2UuDQoNCg0KT3Bz QVdHOg0KLS0tLS0tLS0tLS0tLS0tLS0tDQpBZG1pbmlzdHJpdmlhLg0KaW5jbHVkaW5nIERyYWZ0 IHN0YXR1cyB1cGRhdGVzLCBldGMuDQpPcHNBV0cgY2hhaXJzIC0gMTAgbWludXRlcy4NCg0KVXBk YXRlIG9uIEVUU0kgTkZWIE1hbmFnZW1lbnQgJiBPcmNoZXN0cmF0aW9uIFdHIEVyc3VlLCBNZWht ZXQgLSAxMCBtaW51dGVzDQoNCk5ldHdvcmsgQ29uZmlndXJhdGlvbiBOZWdvdGlhdGlvbiBQcm9i bGVtIFN0YXRlbWVudCBhbmQgUmVxdWlyZW1lbnRzIGRyYWZ0LWppYW5nLWNvbmZpZy1uZWdvdGlh dGlvbi1wcyBCcmlhbiBDYXJwZW50ZXIgLSAxNSBtaW51dGVzLg0KDQpUaGUgQ09NQU4gZHJhZnRz Og0KZHJhZnQtZXJzdWUtb3BzYXdnLWNvbWFuLXByb2JzdGF0ZS1yZXFzLTAwDQpkcmFmdC1lcnN1 ZS1vcHNhd2ctY29tYW4tdXNlLWNhc2VzLTAwDQpFcnN1ZSwgTWVobWV0ICAtIDE1IG1pbnV0ZXMu DQoNClRoZSBDQVBXQVAgZHJhZnRzOg0KQ29tbWVudHMvZGlzY3Vzc2lvbiBvbiBkcmFmdC1pZXRm LW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjDQpDb21tZW50cy9kaXNjdXNzaW9uIG9uIGRyYWZ0LXpo YW5nLW9wc2F3Zy1jYXB3YXAtY2RzLTAxIFJhamVzaCBQYXpoeWFubnVyIC0gMTUgbWludXRlcy4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QU0FX RyBtYWlsaW5nIGxpc3QNCk9QU0FXR0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vcHNhd2cNCg== From nobody Mon Feb 17 16:53:23 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 C0A971A02BD for ; Mon, 17 Feb 2014 16:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.704 X-Spam-Level: X-Spam-Status: No, score=-6.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 zcqeqh4BTjm6 for ; Mon, 17 Feb 2014 16:53:20 -0800 (PST) Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 29BF01A0024 for ; Mon, 17 Feb 2014 16:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1107; q=dns/txt; s=iport; t=1392684798; x=1393894398; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YJ+SJCupMLoeJhT+cktHNE/PMvSavZOY4O++aK3rQ/8=; b=ZWyQXKiGQvbatXncfLE5gFav5v6e9MNjq30uuc5+vW44T6hme3Aqtsw9 HkHk6jP8oFjc8fPktbJoSCp66YH5ABgEZkelM08PjTjA9X0DcZhSpTPg1 07WkwqkMhLfv5utUnVPg8p7vNzT69BMJbszlKBd/DPV8VR1bm2s8hg09h Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFALqtAlOQ/khR/2dsb2JhbABZgwY4v1NPgRYWdIImAQEEAQEBNTYKARALIRYPCQMCAQIBFTAGAQwBBQIBAQWHfA3KXReOLQMBAU8HhDgBA5RDg2mBMoUVi1yDLjuBNQ X-IronPort-AV: E=Sophos;i="4.95,864,1384300800"; d="scan'208";a="591401" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-4.cisco.com with ESMTP; 18 Feb 2014 00:53:16 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1I0rGHq023960; Tue, 18 Feb 2014 00:53:16 GMT Message-ID: <5302AEFC.8080109@cisco.com> Date: Tue, 18 Feb 2014 01:53:16 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Randy Bush , Warren Kumari References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/nGO9aExtcKjAT8bOF5TfVlKWxV0 Cc: opsawg Subject: Re: [OPSAWG] Preliminary OPSAWG agenda. 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, 18 Feb 2014 00:53:21 -0000 Dear all, In order to avoid cross-posting, I replied to the opsarea mailer only (the discussion takes place there). Follow the discussion at http://www.ietf.org/mail-archive/web/ops-area/current/msg01150.html, if you're not subscribed to opsarea. Regards, Benoit > warren and any other friendly opsawg chairs: > > i have been told that you are actually wasting air time discussing snmp > write for configuration of devices. i thought we had and finished that > discussion over a decade ago at ietf 51 in london. we were in a large > room with many operators, and i asked all those operators who had snmp > write enabled to raise their hands. zero, count them zero, hands went > up. this resulted in the formation of the interminable netconf effort. > > and i have the tee shirt, see > > just because we're going to be back in london does not mean we need to > replay history. > > randy > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Tue Feb 18 02:58: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 A65281A032F; Tue, 18 Feb 2014 02:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.548, 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 00KW-Nd6mWTg; Tue, 18 Feb 2014 02:58:51 -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 2AA421A00DD; Tue, 18 Feb 2014 02:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18552; q=dns/txt; s=iport; t=1392721128; x=1393930728; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=xwyTrbfesVS7BObpU9JxFRX7ghNcOe2hA0Qj2Ykt6S8=; b=atnW2yfGD+fewoGu0YbXqb3CnKlZrpGYRg/JMLzaymCy7nCcZxwewUJK f9u0xa0iP/AMqn8edTDyQBA8SR4/6UHZSoZWEMvrM10uzoSiEtiJ4g+D5 vkVObNtg1enT0ioIvjnY6WsI8OPvmPR44BHuAhqNylzACrTUeT2aUMBT1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAIg8A1OQ/khM/2dsb2JhbABZgwY4iTa2cYEWFnSCJQEBAQMBeAEFCwsUDRYPCQMCAQIBRQYBDAEHAQEQh2kIDcsuF40KgSBGEQeEOASYLIEyhRWLXIMuO4Et X-IronPort-AV: E=Sophos;i="4.97,501,1389744000"; d="scan'208,217";a="4717563" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 18 Feb 2014 10:58:46 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1IAwjNg000648; Tue, 18 Feb 2014 10:58:45 GMT Message-ID: <53033CE5.2000309@cisco.com> Date: Tue, 18 Feb 2014 11:58:45 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Elwyn Davies , General Area Review Team , Tal Mizrahi References: <1358863845.28723.19076.camel@mightyatom> In-Reply-To: <1358863845.28723.19076.camel@mightyatom> Content-Type: multipart/alternative; boundary="------------080008020208000101050801" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/LXfSIzRN9EzUMBU6FaN_jFcUmeU Cc: "opsawg@ietf.org" , IETF discussion , draft-ietf-opsawg-oam-overview.all@tools.ietf.org Subject: Re: [OPSAWG] Gen-art last call review of draft-ietf-opsawg-oam-overview-08.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: Tue, 18 Feb 2014 10:58:55 -0000 This is a multi-part message in MIME format. --------------080008020208000101050801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Elwyn, Thanks for your review. I don't plan to reply for the authors (btw, not sure I've seen a reply to this), and but a few clarification questions in line, to engage the discussion. > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-opsawg-oam-overview-08.txt > Reviewer: Elwyn Davies > Review Date: 22 Jan 2013 > IETF LC End Date:25 Jan 2013 > IESG Telechat date: (if known) - > > Summary: In my opinion, this draft has serious issues as described > below. > > Major issues: > General 1: Title vs Abstract vs Section 1 vs actual content: > > Here in the UK a well-known brand of varnishes and wood preservative > paints uses the slogan 'Does what it says on the tin!'. If my > understanding and the write-up in RFC 6491, OAM covers a whole lot more > than the coverage of the specific mechanisms discussed in this > document .. and there are various other mechanisms such as SNMP and > Netconf that support the OAM constellation. Can you provide an example of what you mean here? Do you mean that SNMP (and NETCONF) can be used to monitor the OAM results? > I would take the view that > this document certainly does not 'do what it says on the tin'. > Accordingly I take issue with the title as it doesn't provide a total > overview of OAM mechanisms; the abstract closes down the scope of OAM as > compared with RFC 6491 and s1 restricts it even more - and certainly > does not summarize all the OAM tools and mechanisms defined in the IETF. > The last para of s1 claims that 'management aspects are outside the > scope of this document' - if this is really saying that this 'overview' > of OAM skips the whole M aspect of OAM then I'm afraid the document is > badly misnamed. And it significantly reduces the value of the work. Ok, the document title could be improved. > > General (2): The intended purpose of this document: Back in 2011 Stewart > Bryant summarized a review of a previous version of this document from > the routing directorate > (https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/history/ entry dated 2011-08-10 referring to version 05 of the document). IMO the initial section of that review regarding the audience of this document was well targeted and *has not been fixed*. If this is intended as an introductory overview for people wishing to see what OAM is about in the IETF then it needs further introductory text and some background. It should also state what its target audience actually is. This sentence was added: 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. And section 1.2 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. Please let the authors know what you would like to see. I let the authors/doc. shepherd answer the following points. Regards, Benoit > > General (3): I don't know if Scott Bradner has actually produced a proto > shpeherd write up, but I would be intrigued to know the level of > concensus behind this document. In particular the tool classification > in s1.1 and terminology in s2 (particularly s2.2.2) is that used > exclusively in the MPLS-TP work in the IETF which is derived from the > 802.1ag terminology. The terminology is presented as if it is common to > OAM work across the IETF. Does the IETF management community at large > concur with this expansion of the applicability of the terminology set > based on 'Management Domains' etc? > > General (4): As an overview, I think it would be advisable to point out > that one reason for the multiplicity of tools is that they support at > least four different data plane technologies (native IP, vanilla MPLS, > MPLS-TP and PWE) and note that in several cases the data plane > technologies rely on distinct (IP-based) management channels to allow > the information gleaned by the operations in the the data plane to be > reported back to the application that originated the operation. > > > Minor (or at least less major) issues: > > s1, para1: For consistency with the abstract, s1.1 .. and because I'd > expect OAM to handle it as well ... OAM deals with performance > monitoring and statistics gathering as well as dealing with degradation. > > s1.1: The section is entitled building blocks but actually only mentions > one block, i.e., the OAM protocol. Presumably this section really ought > to say something about the applications and device drivers that have to > instantiated in the MPs. In particular as introduction to the text in > the following section it should say something about classifying > applications into continuously running or proactive monitoring and > on-demand applications (since the latter are introduced without any > definition in the next section.) > > > s2.2.2/3: I am not familiar with 802.1 management issues and I was > rather confused by the logical status of MIPs . The text here seems to > indicate that they are intermediate and generally don't terminate > messages but then says in s2.2.3 that messages are 'destined to' MIPs. > Looking for some additional understanding, I fetched up at Wikipedia > (now there's a surprise) http://en.wikipedia.org/wiki/IEEE_802.1ag. > This page mentions the concept of maintenance domains and the > explanation of MIPs as internal points in the domain that generally > forward messages within the domain whereas end points (MEPs) are > effectively on the domain boundary. This makes a whole lot more sense > and seemed to be a rather better set of term definitions than we have in > this draft. > I noticed eventually that the term Management Domain (MD) had appeared > in the first line of s1.1 but does not appear in s2 at all. If we are > going to accept the Management Domain terminology set, then MD certainly > ought to be defined and discussed here. > > > s2.2.3, para1, sentence 1: >> either initiates or reacts to OAM messages. > The following sentences contradict this. Should be 'initiates and/or > reacts to OAM messages'. See comment above. > > s3, general: The level of detail regarding the various toolsets is not > very even. In particular, the MPLS-TP toolset gets significantly more > attention than others and the detail in OWAMP/TWAMP may be more than is > desirable for an overview. > > s3.1: A few words about the likely suppression of pings and traceroute > messages due to ICMP filtering is probably desirable as these limit > their usefulness in the wider Internet. > > s3.3: What about RFC6374 (MPLS packet loss measurement)? It appears in > the list in s1.4 but is not mentioned here. > > s3.4.1: Talking about what the MPLS working group 'is currently doing' > will not be helpful for an archival document. > > s3.4.3.1: The OnDemand-CV reference is for non-TP MPLS... do you mean > RFC 6426 which appears to be the TP variant? > > Nits/editorial comments: > General: For a reader who wants to go on and look at the RFCs that > define the various tools, it would probably be helpful to use reference > tags that either are or include the RFC number. > s1.3, para 2: s/in several fronts/covering several different approaches/ > > s2.2.2, last para: Need to expand 'p2mp'. > > s3.4.3.8: Should this section reference RFC6375? > > s3.5.1: It appears that the basic AC acronym (associated channel) is not > defined. > > --------------080008020208000101050801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Elwyn,

Thanks for your review.
I don't plan to reply for the authors (btw, not sure I've seen a reply to this), and but a few clarification questions in line, to engage the discussion.

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-opsawg-oam-overview-08.txt
Reviewer: Elwyn Davies
Review Date: 22 Jan 2013
IETF LC End Date:25 Jan 2013
IESG Telechat date: (if known) -

Summary: In my opinion, this draft has serious issues as described
below.

Major issues:
General 1: Title vs Abstract vs Section 1 vs actual content:

Here in the UK a well-known brand of varnishes and wood preservative
paints uses the slogan 'Does what it says on the tin!'.  If my
understanding and the write-up in RFC 6491, OAM covers a whole lot more
than the coverage of the specific mechanisms discussed in this
document .. and there are various other mechanisms such as SNMP and
Netconf that support the OAM constellation.
Can you provide an example of what you mean here?
Do you mean that SNMP (and NETCONF) can be used to monitor the OAM results?

I would take the view that
this document certainly does not 'do what it says on the tin'.
Accordingly I take issue with the title as it doesn't provide a total
overview of OAM mechanisms; the abstract closes down the scope of OAM as
compared with RFC 6491 and s1 restricts it even more - and certainly
does not summarize all the OAM tools and mechanisms defined in the IETF.
The last para of s1 claims that 'management aspects are outside the
scope of this document' - if this is really saying that this 'overview'
of OAM skips the whole M aspect of OAM then I'm afraid the document is
badly misnamed.  And it significantly reduces the value of the work.
Ok, the document title could be improved.

General (2): The intended purpose of this document: Back in 2011 Stewart
Bryant summarized a review of a previous version of this document from
the routing directorate
(https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/history/ entry dated 2011-08-10 referring to version 05 of the document).  IMO the initial section of that review regarding the audience of this document was well targeted and *has not been fixed*.  If this is intended as an introductory overview for people wishing to see what OAM is about in the IETF then it needs further introductory text and some background.  It should also state what its target audience actually is.
This sentence was added:
  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.
And section 1.2
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.

Please let the authors know what you would like to see.

I let the authors/doc. shepherd answer the following points.

Regards, Benoit 

General (3): I don't know if Scott Bradner has actually produced a proto
shpeherd write up, but I would be intrigued to know the level of
concensus behind this document.  In particular the tool classification
in s1.1 and terminology in s2 (particularly s2.2.2) is that used
exclusively in the MPLS-TP work in the IETF which is derived from the
802.1ag terminology.  The terminology is presented as if it is common to
OAM work across the IETF. Does the IETF management community at large
concur with this expansion of the applicability of the terminology set
based on 'Management Domains' etc?

General (4): As an overview, I think it would be advisable to point out
that one reason for the multiplicity of tools is that they support at
least four different data plane technologies (native IP, vanilla MPLS,
MPLS-TP and PWE) and note that in several cases the data plane
technologies rely on distinct (IP-based) management channels to allow
the information gleaned by the operations in the the data plane to be
reported back to the application that originated the operation. 


Minor (or at least less major) issues:

s1, para1: For consistency with  the abstract, s1.1 .. and because I'd 
expect OAM to handle it as well ... OAM deals with performance 
monitoring and statistics gathering as well as dealing with degradation.

s1.1: The section is entitled building blocks but actually only mentions 
one block, i.e., the OAM protocol.  Presumably this section really ought 
to say something about the applications and device drivers that have to 
instantiated in the MPs.  In particular as introduction to the text in 
the following section it should say something about classifying 
applications into continuously running or proactive monitoring and 
on-demand applications (since the latter are introduced without any 
definition in the next section.)


s2.2.2/3: I am not familiar with 802.1 management issues and I was 
rather confused by the logical status of MIPs .  The text here seems to 
indicate that they are intermediate and generally don't terminate 
messages but then says in s2.2.3 that messages are 'destined to' MIPs.  
Looking for some additional understanding, I fetched up at Wikipedia 
(now there's a surprise) http://en.wikipedia.org/wiki/IEEE_802.1ag.  
This page mentions the concept of maintenance domains and the 
explanation of MIPs as internal points in the domain that generally 
forward messages within the domain whereas end points (MEPs) are 
effectively on the domain boundary. This makes a whole lot more sense
and seemed to be a rather better set of term definitions than we have in
this draft.  
I noticed eventually that the term Management Domain (MD) had appeared
in the first line of s1.1 but does not appear in s2 at all. If we are
going to accept the Management Domain terminology set, then MD certainly
ought to be defined and discussed here.   


s2.2.3, para1, sentence 1:

  either initiates or reacts to OAM messages.

The following sentences contradict this.  Should be 'initiates and/or 
reacts to OAM messages'.  See comment above.

s3, general: The level of detail regarding the various toolsets is not
very even.  In particular, the MPLS-TP toolset gets significantly more
attention than others and the detail in OWAMP/TWAMP may be more than is
desirable for an overview.

s3.1: A few words about the likely suppression of pings and traceroute 
messages due to ICMP filtering is probably desirable as these limit
their usefulness in the wider Internet.

s3.3: What about RFC6374 (MPLS packet loss measurement)? It appears in
the list in s1.4 but is not mentioned here.

s3.4.1: Talking about what the MPLS working group 'is currently doing' 
will not be helpful for an archival document.

s3.4.3.1: The OnDemand-CV reference is for non-TP MPLS... do you mean 
RFC 6426 which appears to be the TP variant?

Nits/editorial comments:
General: For a reader who wants to go on and look at the RFCs that 
define the various tools, it would probably be helpful to use reference 
tags that  either are or include the RFC number.
s1.3, para 2: s/in several fronts/covering several different approaches/

s2.2.2, last para: Need to expand 'p2mp'.

s3.4.3.8: Should this section reference RFC6375?

s3.5.1: It appears that the basic AC acronym (associated channel) is not 
defined.

--------------080008020208000101050801-- From nobody Tue Feb 18 03:09: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 B78C41A0453; Tue, 18 Feb 2014 03:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.548, 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 Z2nIa9fyMbCR; Tue, 18 Feb 2014 03:09:19 -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 B6C611A03D0; Tue, 18 Feb 2014 03:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19630; q=dns/txt; s=iport; t=1392721755; x=1393931355; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=yxNVQbN/w0Wv35HuMiPOmBIDEc7oVTmi6uBjO778dzE=; b=I6zfaym0ubhqfVWUi3eqSzM6OW63nDj9I6o4hAps5AmRSzEYArO+XT8u K1v0JaYLoWCLmLiQCKO0OHC5Uz5CqmJDZWvQyB8FK1yWhURCTaVYwqRLT LnTo8BDKy64atCAU1Trl1VDD/kpiBlKG15L/fps0lV6oeUeGYK63qsCKE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsFANE+A1OQ/khR/2dsb2JhbABZgwY4iTa2cYEWFnSCJgEBBHgBEAsUDRYPCQMCAQIBRQYBDAEHAQEQh3ENyzMXjQqBFQsGAT8RB4Q4BJgsgTKFFYtcgy47gS0IFw X-IronPort-AV: E=Sophos;i="4.97,501,1389744000"; d="scan'208,217";a="4718286" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 18 Feb 2014 11:09:13 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1IB9D0o004703; Tue, 18 Feb 2014 11:09:13 GMT Message-ID: <53033F59.9010000@cisco.com> Date: Tue, 18 Feb 2014 12:09:13 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Elwyn Davies , General Area Review Team , Tal Mizrahi References: <1358863845.28723.19076.camel@mightyatom> <53033CE5.2000309@cisco.com> In-Reply-To: <53033CE5.2000309@cisco.com> Content-Type: multipart/alternative; boundary="------------080003090707070005040706" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/K-fB7qu4qWeUFjgEbDEX5J5qxPM Cc: "opsawg@ietf.org" , IETF discussion , draft-ietf-opsawg-oam-overview.all@tools.ietf.org Subject: Re: [OPSAWG] Gen-art last call review of draft-ietf-opsawg-oam-overview-08.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: Tue, 18 Feb 2014 11:09:22 -0000 This is a multi-part message in MIME format. --------------080003090707070005040706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Elwyn, Please disregard this email. I wrongly read the date: 22/01/2014 instead of 22/01/2013. My understanding is that the points have been addressed in the version 13. Regards, Benoit > Elwyn, > > Thanks for your review. > I don't plan to reply for the authors (btw, not sure I've seen a reply > to this), and but a few clarification questions in line, to engage the > discussion. > >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-opsawg-oam-overview-08.txt >> Reviewer: Elwyn Davies >> Review Date: 22 Jan 2013 >> IETF LC End Date:25 Jan 2013 >> IESG Telechat date: (if known) - >> >> Summary: In my opinion, this draft has serious issues as described >> below. >> >> Major issues: >> General 1: Title vs Abstract vs Section 1 vs actual content: >> >> Here in the UK a well-known brand of varnishes and wood preservative >> paints uses the slogan 'Does what it says on the tin!'. If my >> understanding and the write-up in RFC 6491, OAM covers a whole lot more >> than the coverage of the specific mechanisms discussed in this >> document .. and there are various other mechanisms such as SNMP and >> Netconf that support the OAM constellation. > Can you provide an example of what you mean here? > Do you mean that SNMP (and NETCONF) can be used to monitor the OAM > results? > >> I would take the view that >> this document certainly does not 'do what it says on the tin'. >> Accordingly I take issue with the title as it doesn't provide a total >> overview of OAM mechanisms; the abstract closes down the scope of OAM as >> compared with RFC 6491 and s1 restricts it even more - and certainly >> does not summarize all the OAM tools and mechanisms defined in the IETF. >> The last para of s1 claims that 'management aspects are outside the >> scope of this document' - if this is really saying that this 'overview' >> of OAM skips the whole M aspect of OAM then I'm afraid the document is >> badly misnamed. And it significantly reduces the value of the work. > Ok, the document title could be improved. >> General (2): The intended purpose of this document: Back in 2011 Stewart >> Bryant summarized a review of a previous version of this document from >> the routing directorate >> (https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/history/ entry dated 2011-08-10 referring to version 05 of the document). IMO the initial section of that review regarding the audience of this document was well targeted and *has not been fixed*. If this is intended as an introductory overview for people wishing to see what OAM is about in the IETF then it needs further introductory text and some background. It should also state what its target audience actually is. > This sentence was added: > > 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. > > And section 1.2 > > > 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. > > Please let the authors know what you would like to see. > > I let the authors/doc. shepherd answer the following points. > > Regards, Benoit >> General (3): I don't know if Scott Bradner has actually produced a proto >> shpeherd write up, but I would be intrigued to know the level of >> concensus behind this document. In particular the tool classification >> in s1.1 and terminology in s2 (particularly s2.2.2) is that used >> exclusively in the MPLS-TP work in the IETF which is derived from the >> 802.1ag terminology. The terminology is presented as if it is common to >> OAM work across the IETF. Does the IETF management community at large >> concur with this expansion of the applicability of the terminology set >> based on 'Management Domains' etc? >> >> General (4): As an overview, I think it would be advisable to point out >> that one reason for the multiplicity of tools is that they support at >> least four different data plane technologies (native IP, vanilla MPLS, >> MPLS-TP and PWE) and note that in several cases the data plane >> technologies rely on distinct (IP-based) management channels to allow >> the information gleaned by the operations in the the data plane to be >> reported back to the application that originated the operation. >> >> >> Minor (or at least less major) issues: >> >> s1, para1: For consistency with the abstract, s1.1 .. and because I'd >> expect OAM to handle it as well ... OAM deals with performance >> monitoring and statistics gathering as well as dealing with degradation. >> >> s1.1: The section is entitled building blocks but actually only mentions >> one block, i.e., the OAM protocol. Presumably this section really ought >> to say something about the applications and device drivers that have to >> instantiated in the MPs. In particular as introduction to the text in >> the following section it should say something about classifying >> applications into continuously running or proactive monitoring and >> on-demand applications (since the latter are introduced without any >> definition in the next section.) >> >> >> s2.2.2/3: I am not familiar with 802.1 management issues and I was >> rather confused by the logical status of MIPs . The text here seems to >> indicate that they are intermediate and generally don't terminate >> messages but then says in s2.2.3 that messages are 'destined to' MIPs. >> Looking for some additional understanding, I fetched up at Wikipedia >> (now there's a surprise)http://en.wikipedia.org/wiki/IEEE_802.1ag. >> This page mentions the concept of maintenance domains and the >> explanation of MIPs as internal points in the domain that generally >> forward messages within the domain whereas end points (MEPs) are >> effectively on the domain boundary. This makes a whole lot more sense >> and seemed to be a rather better set of term definitions than we have in >> this draft. >> I noticed eventually that the term Management Domain (MD) had appeared >> in the first line of s1.1 but does not appear in s2 at all. If we are >> going to accept the Management Domain terminology set, then MD certainly >> ought to be defined and discussed here. >> >> >> s2.2.3, para1, sentence 1: >>> either initiates or reacts to OAM messages. >> The following sentences contradict this. Should be 'initiates and/or >> reacts to OAM messages'. See comment above. >> >> s3, general: The level of detail regarding the various toolsets is not >> very even. In particular, the MPLS-TP toolset gets significantly more >> attention than others and the detail in OWAMP/TWAMP may be more than is >> desirable for an overview. >> >> s3.1: A few words about the likely suppression of pings and traceroute >> messages due to ICMP filtering is probably desirable as these limit >> their usefulness in the wider Internet. >> >> s3.3: What about RFC6374 (MPLS packet loss measurement)? It appears in >> the list in s1.4 but is not mentioned here. >> >> s3.4.1: Talking about what the MPLS working group 'is currently doing' >> will not be helpful for an archival document. >> >> s3.4.3.1: The OnDemand-CV reference is for non-TP MPLS... do you mean >> RFC 6426 which appears to be the TP variant? >> >> Nits/editorial comments: >> General: For a reader who wants to go on and look at the RFCs that >> define the various tools, it would probably be helpful to use reference >> tags that either are or include the RFC number. >> s1.3, para 2: s/in several fronts/covering several different approaches/ >> >> s2.2.2, last para: Need to expand 'p2mp'. >> >> s3.4.3.8: Should this section reference RFC6375? >> >> s3.5.1: It appears that the basic AC acronym (associated channel) is not >> defined. >> >> > --------------080003090707070005040706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Elwyn,

Please disregard this email. I wrongly read the date: 22/01/2014 instead of 22/01/2013.
My understanding is that the points have been addressed in the version 13.

Regards, Benoit
Elwyn,

Thanks for your review.
I don't plan to reply for the authors (btw, not sure I've seen a reply to this), and but a few clarification questions in line, to engage the discussion.

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-opsawg-oam-overview-08.txt
Reviewer: Elwyn Davies
Review Date: 22 Jan 2013
IETF LC End Date:25 Jan 2013
IESG Telechat date: (if known) -

Summary: In my opinion, this draft has serious issues as described
below.

Major issues:
General 1: Title vs Abstract vs Section 1 vs actual content:

Here in the UK a well-known brand of varnishes and wood preservative
paints uses the slogan 'Does what it says on the tin!'.  If my
understanding and the write-up in RFC 6491, OAM covers a whole lot more
than the coverage of the specific mechanisms discussed in this
document .. and there are various other mechanisms such as SNMP and
Netconf that support the OAM constellation.
Can you provide an example of what you mean here?
Do you mean that SNMP (and NETCONF) can be used to monitor the OAM results?

I would take the view that
this document certainly does not 'do what it says on the tin'.
Accordingly I take issue with the title as it doesn't provide a total
overview of OAM mechanisms; the abstract closes down the scope of OAM as
compared with RFC 6491 and s1 restricts it even more - and certainly
does not summarize all the OAM tools and mechanisms defined in the IETF.
The last para of s1 claims that 'management aspects are outside the
scope of this document' - if this is really saying that this 'overview'
of OAM skips the whole M aspect of OAM then I'm afraid the document is
badly misnamed.  And it significantly reduces the value of the work.
Ok, the document title could be improved.
General (2): The intended purpose of this document: Back in 2011 Stewart
Bryant summarized a review of a previous version of this document from
the routing directorate
(https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/history/ entry dated 2011-08-10 referring to version 05 of the document).  IMO the initial section of that review regarding the audience of this document was well targeted and *has not been fixed*.  If this is intended as an introductory overview for people wishing to see what OAM is about in the IETF then it needs further introductory text and some background.  It should also state what its target audience actually is.
This sentence was added:
  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.
And section 1.2
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.

Please let the authors know what you would like to see.

I let the authors/doc. shepherd answer the following points.

Regards, Benoit 
General (3): I don't know if Scott Bradner has actually produced a proto
shpeherd write up, but I would be intrigued to know the level of
concensus behind this document.  In particular the tool classification
in s1.1 and terminology in s2 (particularly s2.2.2) is that used
exclusively in the MPLS-TP work in the IETF which is derived from the
802.1ag terminology.  The terminology is presented as if it is common to
OAM work across the IETF. Does the IETF management community at large
concur with this expansion of the applicability of the terminology set
based on 'Management Domains' etc?

General (4): As an overview, I think it would be advisable to point out
that one reason for the multiplicity of tools is that they support at
least four different data plane technologies (native IP, vanilla MPLS,
MPLS-TP and PWE) and note that in several cases the data plane
technologies rely on distinct (IP-based) management channels to allow
the information gleaned by the operations in the the data plane to be
reported back to the application that originated the operation. 


Minor (or at least less major) issues:

s1, para1: For consistency with  the abstract, s1.1 .. and because I'd 
expect OAM to handle it as well ... OAM deals with performance 
monitoring and statistics gathering as well as dealing with degradation.

s1.1: The section is entitled building blocks but actually only mentions 
one block, i.e., the OAM protocol.  Presumably this section really ought 
to say something about the applications and device drivers that have to 
instantiated in the MPs.  In particular as introduction to the text in 
the following section it should say something about classifying 
applications into continuously running or proactive monitoring and 
on-demand applications (since the latter are introduced without any 
definition in the next section.)


s2.2.2/3: I am not familiar with 802.1 management issues and I was 
rather confused by the logical status of MIPs .  The text here seems to 
indicate that they are intermediate and generally don't terminate 
messages but then says in s2.2.3 that messages are 'destined to' MIPs.  
Looking for some additional understanding, I fetched up at Wikipedia 
(now there's a surprise) http://en.wikipedia.org/wiki/IEEE_802.1ag.  
This page mentions the concept of maintenance domains and the 
explanation of MIPs as internal points in the domain that generally 
forward messages within the domain whereas end points (MEPs) are 
effectively on the domain boundary. This makes a whole lot more sense
and seemed to be a rather better set of term definitions than we have in
this draft.  
I noticed eventually that the term Management Domain (MD) had appeared
in the first line of s1.1 but does not appear in s2 at all. If we are
going to accept the Management Domain terminology set, then MD certainly
ought to be defined and discussed here.   


s2.2.3, para1, sentence 1:

  either initiates or reacts to OAM messages.

The following sentences contradict this.  Should be 'initiates and/or 
reacts to OAM messages'.  See comment above.

s3, general: The level of detail regarding the various toolsets is not
very even.  In particular, the MPLS-TP toolset gets significantly more
attention than others and the detail in OWAMP/TWAMP may be more than is
desirable for an overview.

s3.1: A few words about the likely suppression of pings and traceroute 
messages due to ICMP filtering is probably desirable as these limit
their usefulness in the wider Internet.

s3.3: What about RFC6374 (MPLS packet loss measurement)? It appears in
the list in s1.4 but is not mentioned here.

s3.4.1: Talking about what the MPLS working group 'is currently doing' 
will not be helpful for an archival document.

s3.4.3.1: The OnDemand-CV reference is for non-TP MPLS... do you mean 
RFC 6426 which appears to be the TP variant?

Nits/editorial comments:
General: For a reader who wants to go on and look at the RFCs that 
define the various tools, it would probably be helpful to use reference 
tags that  either are or include the RFC number.
s1.3, para 2: s/in several fronts/covering several different approaches/

s2.2.2, last para: Need to expand 'p2mp'.

s3.4.3.8: Should this section reference RFC6375?

s3.5.1: It appears that the basic AC acronym (associated channel) is not 
defined.


--------------080003090707070005040706-- From nobody Tue Feb 18 03:13:15 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 2A3011A03D0 for ; Tue, 18 Feb 2014 03:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.964 X-Spam-Level: *** X-Spam-Status: No, score=3.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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, RDNS_NONE=0.793, SPF_PASS=-0.001, T_DKIM_INVALID=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 d1ahHDFYCpgz for ; Tue, 18 Feb 2014 03:12:57 -0800 (PST) Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9AF1A047C for ; Tue, 18 Feb 2014 03:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=602244; q=dns/txt; s=iport; t=1392721968; x=1393931568; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=HN17TtbY2sHuGpumso5At/J167+zLjbILHeUCQuomtU=; b=LhWQkCyDzppdIfF1QmZl3OGzIfXKhbffwBCAgRufB3wfvLcD1lvOcK8w Qr4zBO6LX2E/eRRfuVcH0nEOKz4EBJ+QpSKurvGot95zaY/uXzpBFHVdi FKCiri3AcVNY7xlmaJ6DOUaPtuEYQwmC8ZzpCEbzuPsAuJYXOsHle7HOv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAL0/A1OQ/khL/2dsb2JhbADFag X-IronPort-AV: E=Sophos;i="4.97,501,1389744000"; d="scan'208,217";a="630160" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-4.cisco.com with ESMTP; 18 Feb 2014 11:12:44 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1IBCeWm003676; Tue, 18 Feb 2014 11:12:40 GMT Message-ID: <53034028.1080006@cisco.com> Date: Tue, 18 Feb 2014 12:12:40 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tal Mizrahi , Thomas Nadeau 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> <74470498B659FA4687F0B0018C19A89C01D43919C2A4@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01D43919C2A4@IL-MB01.marvell.com> Content-Type: multipart/alternative; boundary="------------000401030308050104080508" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/pL_bAl6gSLYW2xlcz2gvHwmOd7s Cc: "draft-ietf-opsawg-oam-overview@tools.ietf.org" , "opsawg@ietf.org" , "opsawg-chairs@tools.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, 18 Feb 2014 11:13:12 -0000 This is a multi-part message in MIME format. --------------000401030308050104080508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tal, AFAICT, this issue below is the only one left on the draft. The draft improved much, thanks. Please post a new version with the change, and I'll put it on the IESG table. Regards, Benoit > > 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); Scott O. Bradner (sob@harvard.edu) > *Subject:* Re: Last Call: (An > Overview of Operations, Administration, and Maintenance (OAM) > Mechanisms) to Informational 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 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-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 > > 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: > > Regards, Benoit > > ============== > > 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 "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 many indirect references 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 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 "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 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... 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... 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 > > 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-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/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 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 = 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 hadhttp://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' > > 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 toiesg@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. > > > > > > > --------------000401030308050104080508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Tal,

AFAICT, this issue below is the only one left on the draft. The draft improved much, thanks.
Please post a new version with the change, and I'll put it on the IESG table.

Regards, Benoit

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); Scott O. Bradner (sob@harvard.edu)
Subject: Re: Last Call: <draft-ietf-opsawg-oam-overview-08.txt> (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational 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 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-opsawg-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

 

 

            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:

Regards, Benoit

==============

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 “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

 

   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

   (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 many indirect references 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 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 “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 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… 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… 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://tools.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/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 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 = 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
 
 
   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.
 
 
 

 

 

 

 


--------------000401030308050104080508-- From nobody Tue Feb 18 07: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 59E201A01F0 for ; Tue, 18 Feb 2014 07:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.548, 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 9Mgxb_WbwT7C for ; Tue, 18 Feb 2014 07:55:08 -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 287A11A0238 for ; Tue, 18 Feb 2014 07:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20591; q=dns/txt; s=iport; t=1392738904; x=1393948504; h=message-id:date:from:mime-version:to:cc:subject; bh=FeupTH+EHQySWO+hwsC/Pbu5gSMLZi+BPLSK84YQayQ=; b=f4bj8CIcLiHfC0rBzrOmVQ93ndnPwDyIvAHUK+3PLG1dlsPsmTQeCQux SZyDaj7WwGtmO27EDP0Psg/nIeburNbeHMTh2v4ZcwchciM8irA48u/0J NMJ3/YvndBRx9p59D4oe2mRD56qr659fyR77ttTWeLzJ7dmTi1mqCf5lB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAPCBA1OQ/khR/2dsb2JhbABZgwaJbrZxgRkWdIJTUQE8FhgDAgECAVgBBwEBiAHMDxeOFggaSYQ/BJRDg2mGR4tcgy47gS0 X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208,217";a="4736405" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 18 Feb 2014 15:55:03 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1IFt2SY017546; Tue, 18 Feb 2014 15:55:03 GMT Message-ID: <53038256.1040309@cisco.com> Date: Tue, 18 Feb 2014 16:55:02 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: draft-ietf-opsawg-large-flow-load-balancing@tools.ietf.org Content-Type: multipart/alternative; boundary="------------060305070101070405060908" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/lxKkxqDEQWkCz5aCLGNpyn2TIpE Cc: "opsawg@ietf.org" Subject: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing 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, 18 Feb 2014 15:55:13 -0000 This is a multi-part message in MIME format. --------------060305070101070405060908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Here is my AD review of draft-ietf-opsawg-large-flow-load-balancing - Section 1: Networks extensively use link aggregation groups (LAG) [802.1AX] and equal cost multi-paths (ECMP) [RFC 2991] as techniques for capacity scaling. For the problems addressed by this document, network traffic can be predominantly categorized into two traffic types: long-lived large flows and other flows. ... This draft describes mechanisms for optimal LAG/ECMP component link utilization while using hash-based techniques. The mechanisms comprise the following steps -- recognizing_large flows_ in a router; and assigning the large flows to specific LAG/ECMP component links or redistributing the small flows when a component link on the router is congested. It is useful to keep in mind that in typical use cases for this mechanism the_large flows_ are those that consume a significant amount of bandwidth on a link, e.g. greater than 5% of link bandwidth. The number of such flows would necessarily be fairly small, e.g. on the order of 10's or 100's per LAG/ECMP. In other words, the number of _ large flows_ is NOT expected to be on the order of millions of flows. Examples of such large flows would be IPsec tunnels in service provider backbone networks or storage backup traffic in data center networks. 3 instances of "large flows": do you mean "long-lived large flows"? If not, why do you make a distinction between long-lived large flows and other flows in the first paragraph? I eventually understood the source of confusion when I read the terminology section: Large flow(s): long-lived large flow(s) Either use capitalized term in the Intro section (actually throughout the doc.) so that we understand that the term is defined somewhere, or make it clear in the intro that large flow(s) = long-lived large flow(s) - This document presents improved load distribution techniques based on the large flow awareness. Improved compared to? - In several places, starting with the title and abstract, you speak about mechanisms (plural). However, looking at section 4.2, it seems that you propose a single mechanism? Or maybe you consider 4.1, 4.2, 4.3 as different mechanisms? - Step 3) On receiving the alert about the congested component link, the operator, through a central management entity, finds the large flows mapped to that component link and the LAG/ECMP group to which the component link belongs. Step 4) The operator can choose to rebalance the large flows on lightly loaded component links of the LAG/ECMP group or redistribute the small flows on the congested link to other component links of the group. The operator, through a central management entity, can choose one of the following actions: 1) Indicate specific large flows to rebalance; 2) Have the router decide the best large flows to rebalance; 3) Have the router redistribute all the small flows on the congested link to other component links in the group. "Indicate specific large flows to rebalance", "through a central management entity", what you describe is basically traffic engineering. Other the other hand, for 2) and 3), why do you need a central management entity? - A number of routers support sampling techniques such as sFlow [sFlow- v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. For the purpose of large flow identification, sampling must be enabled on all of the egress ports in the router where such measurements are desired. I don't understand the second sentence. One way to read this is: sampling must be _enabled _on all of the egress ports where such measurements are desired. Ok, this is an obvious statement. If the measurements are desired, enable them Or maybe you want to say: _sampling _must be enabled on all of the egress ports where such measurements are desired. This is a false statement: if you have the choice between sampling and non sampling, use non sampling measurements. Or maybe you want to say: sampling must be enabled on _all _of the egress ports where such measurements are desired. This is a false statement: if I have ECMP on 2 links, and only one of them can't do non sampling, then we should not force sampling on both links. You see, I'm confused. You miss a couple of key messages: - if unsampled measurements are available, use those. - egress means where LAG/ECMP are enabled (this is important for the paragraph starting with "If egress sampling is not available, ingress sampling can suffice since the central management entity use") - If egress sampling is not available, ingress sampling can suffice since the central management entity used by the sampling technique typically has multi-node visibility and can use the samples from an immediately downstream node to make measurements for egress traffic at the local node. It's not clear if "ingress" means the ingress interface of the router itself, or the ingress interface of the downstream router. A drawing is required. Both options are possible: 1. ingress interfaces on the router where LAG/ECMP is initiated flow monitoring must be enabled on all ingress interfaces flow monitoring must have a way to know the egress interfaces 2. ingress interfaces of the downstream router only work for LAG or ECMP single hop ingress interfaces = all components from LAG/ECMP (multiple ifIndex, typically) this entire section 4.3.3 needs some improvements - On one side, you wrote "Specific algorithms for placement of large flows are out of scope of this document.". On the other side, "The following parameters are required the configuration of _this_ feature". It seems contradictory. It's unclear why you need the following parameter: . Imbalance threshold: the difference between the utilization of the least utilized and most utilized component links. Expressed as a percentage of link speed. Also, does ECMP/LAG always require equivalent link speed for their components? - 5.2. System Configuration and Identification Parameters . IP address: The IP address of a specific router that the feature is being configured on, or that the large flow placement is being applied to. . LAG ID: Identifies the LAG. The LAG ID may be required when configuring this feature (to apply a specific set of large flow identification parameters to the LAG) and will be required when specifying flow placement to achieve the desired rebalancing. . Component Link ID: Identifies the component link within a LAG. This is required when specifying flow placement to achieve the desired rebalancing. Nothing regarding ECMP? - For high speed links, the etherStatsHighCapacityTable MIB [RFC 3273] can be used. Well, only for ethernet. EDITORIAL: - figure 2 OLD: +-----------+ -> +-----------+ | | -> | | | | ===> | | | (1)|--------|(1) | | | -> | | | | -> | | | (R1) | -> | (R2) | NEW: +-----------+ -> +-----------+ | | -> | | | | ===> | | | (1)|--------|(1) | | | -> | | | | -> | | | (R1) | -> | (R2) | - The indentation in section 2 is not correct - "For tunneling protocols like GRE, VXLAN, NVGRE, STT, etc.," You need to expand and provide references. - a PBR rule Expand. - OLD: +-----------+ -> +-----------+ | | -> | | | | ===> | | | (1)|--------|(1) | | | | | | | ===> | | | | -> | | | | -> | | | (R1) | -> | (R2) | | (2)|--------|(2) | NEW: +-----------+ -> +-----------+ | | -> | | | | ===> | | | (1)|--------|(1) | | | | | | | ===> | | | | -> | | | | -> | | | (R1) | -> | (R2) | | (2)|--------|(2) | - OLD: The IPFIX information model [RFC 7011] NEW: The IPFIX information model [RFC 7012] Regards, Benoit --------------060305070101070405060908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Dear authors,

Here is my AD review of draft-ietf-opsawg-large-flow-load-balancing

- Section 1:
   Networks extensively use link aggregation groups (LAG) [802.1AX] and
   equal cost multi-paths (ECMP) [RFC 2991] as techniques for capacity
   scaling. For the problems addressed by this document, network traffic
   can be predominantly categorized into two traffic types: long-lived
   large flows and other flows. 

   ...

   This draft describes mechanisms for optimal LAG/ECMP component link
   utilization while using hash-based techniques. The mechanisms
   comprise the following steps -- recognizing large flows in a router;
   and assigning the large flows to specific LAG/ECMP component links or
   redistributing the small flows when a component link on the router is
   congested.

   It is useful to keep in mind that in typical use cases for this
   mechanism the large flows are those that consume a significant amount
   of bandwidth on a link, e.g. greater than 5% of link bandwidth.  The
   number of such flows would necessarily be fairly small, e.g. on the
   order of 10's or 100's per LAG/ECMP.  In other words, the number of
   large flows is NOT expected to be on the order of millions of flows.
   Examples of such large flows would be IPsec tunnels in service
   provider backbone networks or storage backup traffic in data center
   networks.
3 instances of "large flows": do you mean "long-lived large flows"?
If not, why do you make a distinction between long-lived large flows and other flows in the first paragraph?
I eventually understood the source of confusion when I read the terminology section:
    Large flow(s): long-lived large flow(s)

Either use capitalized term in the Intro section (actually throughout the doc.) so that we understand that the term is defined somewhere, or make it clear in the intro that large flow(s) = long-lived large flow(s)

-
   This document presents improved load distribution techniques based on
   the large flow awareness.
Improved compared to?

-
In several places, starting with the title and abstract, you speak about mechanisms (plural).
However, looking at section 4.2, it seems that you propose a single mechanism? Or maybe you consider 4.1, 4.2, 4.3 as different mechanisms?

-
Step 3) On receiving the alert about the congested component link,
   the operator, through a central management entity, finds the large
   flows mapped to that component link and the LAG/ECMP group to which
   the component link belongs.

   Step 4) The operator can choose to rebalance the large flows on
   lightly loaded component links of the LAG/ECMP group or redistribute
   the small flows on the congested link to other component links of the
   group. The operator, through a central management entity, can choose
   one of the following actions:

      1) Indicate specific large flows to rebalance;

      2) Have the router decide the best large flows to rebalance;

      3) Have the router redistribute all the small flows on the
   congested link to other component links in the group.
"Indicate specific large flows to rebalance", "through a central management entity", what you describe is basically traffic engineering.
Other the other hand, for 2) and 3), why do you need a central management entity?


-
   A number of routers support sampling techniques such as sFlow [sFlow-
   v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].
   For the purpose of large flow identification, sampling must be
   enabled on all of the egress ports in the router where such
   measurements are desired.
I don't understand the second sentence.
One way to read this is:  sampling must be enabled on all of the egress ports where such measurements are desired.
    Ok, this is an obvious statement. If the measurements are desired, enable them
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if you have the choice between sampling and non sampling, use non sampling measurements.
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if I have ECMP on 2 links, and only one of them can't do non sampling, then we should not force
    sampling on both links.
You see, I'm confused.

You miss a couple of key messages:
- if unsampled measurements are available, use those.
- egress means where LAG/ECMP are enabled (this is important for the paragraph starting with "If egress sampling is not available, ingress sampling can suffice since the central management entity use")

-
   If egress sampling is not available, ingress sampling can suffice
   since the central management entity used by the sampling technique
   typically has multi-node visibility and can use the samples from an
   immediately downstream node to make measurements for egress traffic
   at the local node.
It's not clear if "ingress" means the ingress interface of the router itself, or the ingress interface of the downstream router.
A drawing is required.
Both options are possible:
    1. ingress interfaces on the router where LAG/ECMP is initiated
        flow monitoring must be enabled on all ingress interfaces
        flow monitoring must have a way to know the egress interfaces
2. ingress interfaces of the downstream router
        only work for LAG or ECMP single hop
        ingress interfaces = all components from LAG/ECMP (multiple ifIndex, typically)

this entire section 4.3.3 needs some improvements

-
On one side, you wrote "Specific algorithms for placement of large flows are out of scope of this document.". On the other side, "The following parameters are required the configuration of this feature". It seems contradictory.
It's unclear why you need the following parameter:

     .  Imbalance threshold: the difference between the utilization of
        the least utilized and most utilized component links.  Expressed
        as a percentage of link speed.

Also, does ECMP/LAG always require equivalent link speed for their components?
 
-
5.2. System Configuration and Identification Parameters

     .  IP address: The IP address of a specific router that the
        feature is being configured on, or that the large flow placement
        is being applied to.

     .  LAG ID: Identifies the LAG. The LAG ID may be required when
        configuring this feature (to apply a specific set of large flow
        identification parameters to the LAG) and will be required when
        specifying flow placement to achieve the desired rebalancing.

     .  Component Link ID: Identifies the component link within a LAG.
        This is required when specifying flow placement to achieve the
        desired rebalancing.
Nothing regarding ECMP?

-
   For high speed links, the etherStatsHighCapacityTable MIB [RFC 3273]
   can be used.

Well, only for ethernet.




EDITORIAL:
-
figure 2

OLD:
                  +-----------+ ->     +-----------+
                  |           | ->     |           |
                  |           | ===>   |           |
                  |        (1)|--------|(1)        |
                  |           | ->     |           |
                  |           | ->     |           |
                  |  (R1)    | ->     |   (R2)  |
NEW:
                  +-----------+ ->     +-----------+
                  |           | ->     |           |
                  |           | ===>   |           |
                  |        (1)|--------|(1)        |
                  |           | ->     |           |
                  |           | ->     |           |
                  |  (R1)     | ->     |   (R2)    |



-  The indentation in section 2 is not correct

- "For tunneling protocols like GRE, VXLAN, NVGRE, STT, etc.,"
You need to expand and provide references.

- a PBR rule
Expand.
-
OLD:
                  +-----------+ ->     +-----------+
                  |           | ->     |           |
                  |           | ===>   |           |
                  |        (1)|--------|(1)        |
                  |           |        |           |
                  |           | ===>   |           |
                  |           | ->     |           |
                  |           | ->     |           |
                  |  (R1)    | ->     |   (R2)  |
                  |        (2)|--------|(2)        |

NEW:
                  +-----------+ ->     +-----------+
                  |           | ->     |           |
                  |           | ===>   |           |
                  |        (1)|--------|(1)        |
                  |           |        |           |
                  |           | ===>   |           |
                  |           | ->     |           |
                  |           | ->     |           |
                  |  (R1)     | ->     |   (R2)    |
                  |        (2)|--------|(2)        |


-
OLD:
The IPFIX information model [RFC 7011] 
NEW:
The IPFIX information model [RFC 7012]  
Regards, Benoit
--------------060305070101070405060908-- From nobody Tue Feb 18 09:33:13 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 C3D571A0505; Tue, 18 Feb 2014 09:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuQjv1YkZOJM; Tue, 18 Feb 2014 09:33:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E941A03FF; Tue, 18 Feb 2014 09:33:08 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140218173307.8289.94109.idtracker@ietfa.amsl.com> Date: Tue, 18 Feb 2014 09:33:07 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/HY0C87aZlWJgl_vcVN6TclyI1cA Cc: opsawg@ietf.org Subject: [OPSAWG] I-D ACTION:draft-ietf-opsawg-oam-overview-14.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, 18 Feb 2014 17:33:10 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : An Overview of Operations, Administration, and Maintenance (OAM) Tools Author(s) : T. Mizrahi, et al Filename : draft-ietf-opsawg-oam-overview Pages : 49 Date : 2014-02-18 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-oam-overview-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsawg-oam-overview"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-18093307.I-D@ietf.org> --NextPart-- From nobody Tue Feb 18 10:57: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 2D1B11A03ED for ; Tue, 18 Feb 2014 10:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.548, 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 QZ45XznsYh4Q for ; Tue, 18 Feb 2014 10:57:45 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5B11A0438 for ; Tue, 18 Feb 2014 10:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6800; q=dns/txt; s=iport; t=1392749855; x=1393959455; h=from:to:subject:date:message-id:mime-version; bh=1EpYZefOr7eXcbhufSF8zgi5yrFXfSONAUgV3it3Mj4=; b=TUmbS/vczolXlFg1C22iIyvv7tX5tQGKymv+QfFyZ4lq4kTvLIMKw/Y3 PCD3sONFmulxTxV0vRVrYzjjoHVcglGLOyW8r8v+DKdoAHl5gMZ+HHLpo 9orheojgdszCDgOH9q7pFnzjOuZ8mZwhyhtzzlM4O53zuPnR5vvx5DnpQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQHAJCsA1OtJXG9/2dsb2JhbABZgkJEOFeqd4wGiFmBHBZ0gicBBC1BAhsBKlYmAQQbh30NmyqxGBeOLSODXIEUBJlekHGDLYIq X-IronPort-AV: E=Sophos; i="4.97,502,1389744000"; d="scan'208,217"; a="21358121" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 18 Feb 2014 18:57:35 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1IIvZSr023653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Feb 2014 18:57:35 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.22]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 12:57:34 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: "opsawg@ietf.org" Thread-Topic: draft-ietf-opsawg-capwap-hybridmac-02 Thread-Index: Ac8s2zt8cFgwdHN+RD6QIq1FO60mGg== Date: Tue, 18 Feb 2014 18:57:34 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F5A50D@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.68.135] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F5A50Dxmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/yXDsMvnX3JiZH9R24hs_-bsRdLc Subject: [OPSAWG] draft-ietf-opsawg-capwap-hybridmac-02 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, 18 Feb 2014 18:57:48 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F5A50Dxmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello I have submitted a new version of the draft IEEE 802.11 MAC Profile for CAP= WAP, http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ . Abstract: CAPWAP defines two entities Wireless Transmission Point (WTP) and Access Controller (AC). CAPWAP also defines two MAC (Medium Access Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For each MAC mode, CAPWAP describes how the MAC functionality is split between the WTP and AC. However, certain functions have not been clearly defined. For example for the Split MAC mode, the IEEE 802.11 encryption is specified as located in either the AC or the WTP with no clear way for the AC to inform the WTP where it should be. This lack of specification leads to interoperability especially when AC and WTP come from different vendors. To solve the problem, this specification defines a IEEE 802.11 MAC profile where each profile specifies an unambiguous division of functionality between the WTP and AC. The IEEE 802.11 MAC profile is used as follows: The WTP informs the AC of the supported profiles during the discovery or join process and the AC configures the WTP with one of the supported profiles while configuring a WLAN. Besides making editorial changes, it addresses suggestions made by Dorothy = Stanley: 1) Eliminate the profiles for Local MAC mode 2) Rename it along the lines of "Split MAC mode with WTP encryption...= . " 3) Editorial changes to abstract and other places in the document We are planning to ask for a WGLC in the London meeting, so we would apprec= iate hearing comments, suggestions prior to the meeting on the mailing list= . Thanks Regards Rajesh --_000_4ED2E36A22261145861BAB2C24088B4320F5A50Dxmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello
 
I have submitted a new version of the draft IEEE 802.11 MAC Profile for CAPWAP= , http://datatracker.ietf.org/doc/= draft-ietf-opsawg-capwap-hybridmac/ .
= Abstract: CAPWAP defines two entities Wireless Transmission Point (WTP) and=
=    Access Controller (AC).  CAPWAP also defines two MAC (Med= ium Access
=    Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For= each
=    MAC mode, CAPWAP describes how the MAC functionality is split = between
=    the WTP and AC.  However, certain functions have not been= clearly
=    defined.  For example for the Split MAC mode, the IEEE 80= 2.11
=    encryption is specified as located in either the AC or the WTP= with
=    no clear way for the AC to inform the WTP where it should be.&= nbsp; This
=    lack of specification leads to interoperability especially whe= n AC
=    and WTP come from different vendors.  To solve the proble= m, this
=    specification defines a IEEE 802.11 MAC profile where each pro= file
=    specifies an unambiguous division of functionality between the= WTP and
=    AC.  The IEEE 802.11 MAC profile is used as follows: The = WTP informs
=    the AC of the supported profiles during the discovery or join = process
=    and the AC configures the WTP with one of the supported profil= es
=    while configuring a WLAN.
 
 
Besides making editorial changes, it addresses suggestions made by Dor= othy Stanley:
  1. Eliminate the profiles for Local MAC mode
  2. Rename it along the l= ines of “Split MAC mode with WTP encryption…. “
  3. E= ditorial changes to abstract and other places in the document
 
 
We are planning to ask for a WGLC in the London meeting, so we would a= ppreciate hearing comments, suggestions prior to the meeting on the mailing= list.
 
Thanks
 
Regards
 
Rajesh
 
 --_000_4ED2E36A22261145861BAB2C24088B4320F5A50Dxmbalnx09ciscoc_-- From nobody Tue Feb 18 11:12:18 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 684C21A010A for ; Tue, 18 Feb 2014 11:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.548, 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 AGAI9lyg3eDV for ; Tue, 18 Feb 2014 11:12:10 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 41A1C1A0250 for ; Tue, 18 Feb 2014 11:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8699; q=dns/txt; s=iport; t=1392750724; x=1393960324; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=K9FZVzcvJE5L0AjD7BQajArwjLHmvhAYJqw5WATkAlY=; b=SVSTA8g9v0+IFrJdvjh3szWCNND6uutW3BsMx+N+PKcWr8QVLbcy2FUS SBliBc4/RAh+k2S1NiA5wIrOuQCx3D0azSZRkGow9VDohZWPi0YI5cFsI VsoWpbsNBAUGyNXY5WuKrhMPyPgofTto01610Pqxf6AZWgo6yfzblQFHK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAE6wA1OtJV2a/2dsb2JhbABZgkJEgQ/ANIEcFnSCJQEBAQQtXAIBCBEEAQELHQcyFAkIAgQBEgiHfcwbF44zNwGDJIEUBKpUgy2CKg X-IronPort-AV: E=Sophos; i="4.97,502,1389744000"; d="scan'208,217"; a="21360299" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 18 Feb 2014 19:11:59 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1IJBxqC003589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 19:11:59 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.22]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 13:11:58 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: "sarikaya@ieee.org" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] draft-ietf-opsawg-capwap-hybridmac-01 Thread-Index: AQHO9RkmCyKlChAc2kqNeov1j6h9OZq7zHAg Date: Tue, 18 Feb 2014 19:11:58 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F5A534@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.68.135] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F5A534xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ty_OaqtiG2DRGIjI5jmAHxB0UWk Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-hybridmac-01 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, 18 Feb 2014 19:12:14 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F5A534xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Behcet Thanks for your comments. Please see the latest draft as we have clarified some of the text to improv= e readability. I will address the points raised directly as well. Regards Rajesh From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Monday, December 09, 2013 11:59 AM To: opsawg@ietf.org Subject: [OPSAWG] draft-ietf-opsawg-capwap-hybridmac-01 Hi all, I was reading this draft and had a few comments: I think the abstract has this sentence which is certainly incorrect: This lack of specification leads to interoperability between AC and WTP whe= n AC and WTP come from different vendors. > As per China Mobile, this is a problem as follows: When WTP is in = Split MAC mode, some vendors expect default behavior for encryption at the = AC while some vendors expect the default behavior to be encryption at the = WTP. So if AC and WTP vendors are different, default behaviors are contrad= ictory. Further, there is no way (in existing specs) for AC to inform WTP a= bout what it should do. The hybrid MAC profile is defined to clarify encryption/decryption function= as an improvement on split MAC profile. It is not clear why? Split MAC profile has similar ambiguity for two other functions, scheduling= and fragmentation. These do not cause interoperability problems? Hybrid MAC makes specific choices for these functions but it is not explain= ed how and why. > The new draft clarifies this further. Nonetheless, clarification b= elow: > On Fragmentation: this is always done at the place where encryptio= n is done. So when the profile specifies encryption, the ambiguity around f= ragmentation is also specified (at the same place as encryption). > On Scheduling: RFC 5416 has text that indicates how scheduling is e= xpected to work: While the admission control component of IEEE 802.11 resides on th= e AC, the real-time scheduling and queuing functions are on the WTP. Note that this does not prevent the AC from providing additional policy and scheduling functionality. I am not sure if the profile exchange is a good idea. How is WTP configured before the exchange? > I am not sure I understand the question. Profile exchange is part o= f WTP configuration. We have provided some clarification in this regard via= Figure 4 in the draft. Regards, Behcet --_000_4ED2E36A22261145861BAB2C24088B4320F5A534xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Behcet
 
Thanks for your comments.
Please see the latest draft as we have clarifi= ed some of the text to improve readability. I will address the points raise= d directly as well.
 
Regards
 
Rajesh
Fr= om: OPSAWG [mailto:opsawg-bo= unces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Monday, December 09, 2013 11:59 AM
To: opsawg@ietf.org
Subject: [OPSAWG] draft-ietf-opsawg-capwap-hybridmac-01
 
Hi all,

I was reading this draft and had a few comments:

I think the abstract has this sentence which is certainly incorrect:

This lack of specification leads to interoperability between AC and WTP whe= n AC and WTP come from different vendors.
  • As per China Mobile, this is  a prob= lem as follows: When WTP is in Split MAC mode, some vendors expect default = behavior for encryption at the AC  while some vendors expect the defau= lt behavior to be encryption at the WTP. So if AC and WTP vendors are different, default behaviors are contradictory. F= urther, there is no way (in existing specs) for AC to inform WTP about what= it should do.
The hybrid MAC profile is defined to clar= ify encryption/decryption function as an improvement on split MAC profile.<= /span>
It is not clear why?
Split MAC profile has similar ambiguity for two other functions, schedu= ling and fragmentation. These do not cause interoperability problems?
Hybrid MAC makes specific choices for the= se functions but it is not explained how and why.
  • The new draft clarifies this further.&nbs= p; Nonetheless, clarification below:
  • = On Fragmentation: this is always done at the place where encryption is don= e. So when the profile specifies encryption, the ambiguity around fragmenta= tion is also specified (at the same place as encryption).
  • On Scheduling: RFC 5416 has text that indicates how s= cheduling is expected to work:
    •
=          While the admission contro= l component of IEEE 802.11 resides on the
=          AC, the real-time scheduli= ng and queuing functions are on the WTP.
=          Note that this does not prevent= the AC from providing additional
=          policy and scheduling functiona= lity.
 
I am not sure if the profile exchange is = a good idea.
How is WTP configured before the exchange?
  • I am not sure I understand the question. = Profile exchange is part of WTP configuration. We have provided some clarif= ication in this regard via Figure 4 in the draft.
Regards,
Behcet
 
 --_000_4ED2E36A22261145861BAB2C24088B4320F5A534xmbalnx09ciscoc_-- From nobody Tue Feb 18 14:10:18 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 D46D91A02B5 for ; Tue, 18 Feb 2014 14:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.548, 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 y4J_KUhagg1N for ; Tue, 18 Feb 2014 14:10:14 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6E31A026A for ; Tue, 18 Feb 2014 14:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5860; q=dns/txt; s=iport; t=1392761412; x=1393971012; h=from:to:subject:date:message-id:mime-version; bh=NjbWf8g3qeL46g1Q/XphMX9ivZyx6rIU9XWGtrAKKLs=; b=dklqUjP5T2ajJ8OpJ6p+WPoAEp3DExXWYZDDCMLHj1YefnPT7Du2N72F YOo4HYKMLPsUh2w8W2tFRRi9NCrAtOFjU/HmGMrcJ7FFaet3reHFgjMrP ZnVAG4CpnHhr93xij17dSBm2xBFzDHAgIjPZZtC7vSSYDijIP+5rCbPHM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgHAFPZA1OtJXG8/2dsb2JhbABYgkJEOFerBIxliFaBIRZ0gicBBC1BHQEaEFYXDwEEG4d8AQ2bcq9gF44zg1yBFASZYpBygy2CKg X-IronPort-AV: E=Sophos; i="4.97,503,1389744000"; d="scan'208,217"; a="21411945" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-2.cisco.com with ESMTP; 18 Feb 2014 22:10:11 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1IMABx4002829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Feb 2014 22:10:11 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.22]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 16:10:11 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: "opsawg@ietf.org" Thread-Topic: Alternate Tunnel Encapsulation for Data Frames in CAPWAP Thread-Index: Ac8s9iqhFmEpJkrATU6c31UNuMJWag== Date: Tue, 18 Feb 2014 22:10:10 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.133.56] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F5A67Cxmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/MXI5Xg_Z_oHPFwQEYgTlk-p-fJc Subject: [OPSAWG] Alternate Tunnel Encapsulation for Data Frames in CAPWAP 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, 18 Feb 2014 22:10:17 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F5A67Cxmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello We have a submitted a new version of Alternate Tunnel Encapsulation for Dat= a Frames in CAPWAP, http://datatracker.ietf.org/doc/draft-zhang-opsawg-cap= wap-cds/. Abstract In centralized IEEE 802.11 Wireless Local Area Network (WLAN) architecture, the Access Controller (AC) isn't intelligent enough actually to aggregate all the wireless frames, even the bandwidth requirement in the access point is increasing. Thus it is a general case in the existing operator's network that WTPs forward the wireless frames directly to Access Router (AR) to avoid overload on the AC. In this scenario, CAPWAP Control Channel and CAPWAP Data Channel are separated from each other. This document extends CAPWAP for applicability of CAPWAP Control and Data Channel separation. We received some questions and suggestions from Dan Romascanu and John Kaip= pallimalil on the mailing list on the previous draft. We have attempted to= address them in this draft. Specifically, 1) How does this draft address signaling, discovery mechanisms related= to setting up alternate tunnel. (ans. Tunneling protocols like L2TPv3, IP/= GRE (PMIPv6) already have a signaling mechanism. This draft focuses on spec= ifying the tunnel type and provides a container to hold message elements) 2) Need for alternate tunnel encapsulation (given the existence of def= ined mode with local bridging) We would like to get it adopted as a working group item and would like feed= back on whether we are on track. thanks Regards Rajesh --_000_4ED2E36A22261145861BAB2C24088B4320F5A67Cxmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello
 
We have a submitted a new version of Alternate Tunnel Encapsulation for Data Frames in CAPWAP, http://datatracker.ietf.org/doc/draft-zhang= -opsawg-capwap-cds/.
 
= Abstract
=  
=    In centralized IEEE 802.11 Wireless Local Area Network (WLAN)<= /span>
=    architecture, the Access Controller (AC) isn't intelligent eno= ugh
=    actually to aggregate all the wireless frames, even the bandwi= dth
=    requirement in the access point is increasing.  Thus it i= s a general
=    case in the existing operator's network that WTPs forward the<= /span>
=    wireless frames directly to Access Router (AR) to avoid overlo= ad on
=    the AC.  In this scenario, CAPWAP Control Channel and CAP= WAP Data
=    Channel are separated from each other.  This document ext= ends CAPWAP
=    for applicability of CAPWAP Control and Data Channel separatio= n.
 
 
We received some questions and suggestions from Dan Romascanu and John= Kaippallimalil on the mailing list on the previous draft. We have attempt= ed to address them in this draft. Specifically,
  1. How does this draft address signaling, discovery mechanisms related to = setting up alternate tunnel. (ans. Tunneling protocols like L2TPv3, IP/GRE = (PMIPv6) already have a signaling mechanism. This draft focuses on specifyi= ng the tunnel type and provides a container to hold message elements)
  2. Need for alternate tunnel enc= apsulation (given the existence of defined mode with local bridging)
    3.  
    We would like to get it adopted as a working group item and would like= feedback on whether we are on track.
     
     
    thanks
     
    Regards
     
    Rajesh
     
     --_000_4ED2E36A22261145861BAB2C24088B4320F5A67Cxmbalnx09ciscoc_-- From nobody Tue Feb 18 17:00:13 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 D51BE1A0216 for ; Tue, 18 Feb 2014 17:00: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 yB7uXuoXCMeO for ; Tue, 18 Feb 2014 17:00:07 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1B84B1A0426 for ; Tue, 18 Feb 2014 17:00:07 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id y10so16935091pdj.12 for ; Tue, 18 Feb 2014 17:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=KF2MSr8BL/OUQgUHFEQ8CVuuS2hRavbxpLJSZ6UPTaw=; b=lssBx7k1i5wqC4yUwMNXi9iSIAlH8ODnYsEX7PS0/BNq5EjPys8AstzB2YX9xHjfJ7 XZDvfPs7palVnMGld98UjeOTfuG+Y0Jx83+6BBJPoxKuyP6sdApdNO8Rz8IqCkRLunz0 XbSVEH5D89ir//uJNxMwfDCxmrIAZk/NroDLz+VIHAlLUa/uEo+6UJJTlwnirxQNlkuD 8oMAg63fjobsRmXjvlBkzYn2jyIn6E0B9ynEkDsmZqPhACW7N0uyun90gazFcLfrIFGW exi6G5Uy/ZtNCE6bZkm0mwUwv5taaBXGhRFKD1KPHXuO/Ns4xwNwz4fRX5d1ozRNltip Hvcw== X-Received: by 10.68.133.193 with SMTP id pe1mr36551660pbb.56.1392771604139; Tue, 18 Feb 2014 17:00:04 -0800 (PST) Received: from spandex.local (63-140-93-251.dynamic.dsl.acsalaska.net. [63.140.93.251]) by mx.google.com with ESMTPSA id yg4sm35044151pab.19.2014.02.18.17.00.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 17:00:03 -0800 (PST) Message-ID: <53040210.4090709@gmail.com> Date: Tue, 18 Feb 2014 16:00:00 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> X-Forwarded-Message-Id: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> Content-Type: multipart/mixed; boundary="------------080601040004090802000807" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/2KbGqn8_CthAv9j09KKdiJTgySQ Subject: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP 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, 19 Feb 2014 01:00:09 -0000 This is a multi-part message in MIME format. --------------080601040004090802000807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please note that Rajesh is planning to ask for working group adoption of this document. Please give it a read and provide feedback on this mailing list. Particularly interested in the question of how well it meshes with CAPWAP documents we've already adopted. Melinda -------- Original Message -------- Subject: [OPSAWG] Alternate Tunnel Encapsulation for Data Frames in CAPWAP Date: Tue, 18 Feb 2014 22:10:10 +0000 From: Rajesh Pazhyannur (rpazhyan) To: opsawg@ietf.org Hello We have a submitted a new version of Alternate Tunnel Encapsulation for Data Frames in CAPWAP,_http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/_. Abstract In centralized IEEE 802.11 Wireless Local Area Network (WLAN) architecture, the Access Controller (AC) isn't intelligent enough actually to aggregate all the wireless frames, even the bandwidth requirement in the access point is increasing. Thus it is a general case in the existing operator's network that WTPs forward the wireless frames directly to Access Router (AR) to avoid overload on the AC. In this scenario, CAPWAP Control Channel and CAPWAP Data Channel are separated from each other. This document extends CAPWAP for applicability of CAPWAP Control and Data Channel separation. We received some questions and suggestions from Dan Romascanu and John Kaippallimalil on the mailing list on the previous draft. We have attempted to address them in this draft. Specifically, 1. How does this draft address signaling, discovery mechanisms related to setting up alternate tunnel. (ans. Tunneling protocols like L2TPv3, IP/GRE (PMIPv6) already have a signaling mechanism. This draft focuses on specifying the tunnel type and provides a container to hold message elements) 2. Need for alternate tunnel encapsulation (given the existence of defined mode with local bridging) We would like to get it adopted as a working group item and would like feedback on whether we are on track. thanks Regards Rajesh --------------080601040004090802000807 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --------------080601040004090802000807-- From nobody Tue Feb 18 17:52:18 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 56D921A0522 for ; Tue, 18 Feb 2014 17:52:15 -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 DzwGi5RGoS58 for ; Tue, 18 Feb 2014 17:52:12 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6E11A051F for ; Tue, 18 Feb 2014 17:52:12 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id jw12so61627veb.12 for ; Tue, 18 Feb 2014 17:52:09 -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=eQg6e3vYjYcc0LaGQUWP9UmeMBBVPb1JmaAnGEWlSrE=; b=Oj0T78YrjC7UU+HXpuP36syOVUeNJtEIsJHgVIsxT+NZGmZ7skbuhu+/Eq41BxImCQ YvSY/LyuaNrjTt9HlUIrJmgmPxdKwX90+kOSChftS57SWmVcWZS4q4zhlb4sI5PjZqRL r/a2rFg5WqiuzuUwKBhiUPUonTqsQJBPplxpGRdYbzFfHVUFHvk272Bath2pxb7tpBHB +dnaqumpFNjhLaC7sBAs4oxplqqw3JZjjkWRwlN2OoFpvwsq4lQLXbdQGqsDW71NYZJq 6fvGPEP9IXHIgk8+GK7ovsdtD2lLcktM97lYxbIERhVuRc530vkcZnWPnynYw5Scx9a4 C3kg== MIME-Version: 1.0 X-Received: by 10.220.110.210 with SMTP id o18mr51455vcp.49.1392774728965; Tue, 18 Feb 2014 17:52:08 -0800 (PST) Received: by 10.221.24.146 with HTTP; Tue, 18 Feb 2014 17:52:08 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 09:52:08 +0800 Message-ID: From: Liu Dapeng To: Warren Kumari Content-Type: multipart/alternative; boundary=047d7b3a916af8e53704f2b8a2cf Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/CnCdfMHUAa8z7UPG45n_RwO1DEo Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Preliminary OPSAWG agenda. 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, 19 Feb 2014 01:52:15 -0000 --047d7b3a916af8e53704f2b8a2cf Content-Type: text/plain; charset=ISO-8859-1 Hi Warren, all, Regarding the CAPWAP drafts, we also update capwap 802.11n extension draft: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-extension-02. May I have 5 minutes to present it? Thanks, Dapeng Liu 2014-02-15 2:02 GMT+08:00 Warren Kumari : > Dear OpsAWG. > > Here is the preliminary schedule for the OpsAWG meeting at IETF 89 in > London. > Our meeting is currently scheduled for 1610-1840 GMT on Tuesday. > > Please come prepared, by having read the drafts, and armed with > questions/ comments. > > We *do* still have a small amount of agenda time, please know if you > have any issues you'd like to discuss / present, but remember -- you > need to have had some (on-list!) discussions to qualify for this > special, limited time offer... > > Thanks, > Your friendly OpsAWG chairs... > > > Joint OpsAWG / Ops-Area > ====================== > Ops Area, by the OpsADs > -------------------------------------------- > Including such things as (non-authorative!): > Invited talk on operational considerations in pervasive monitoring > Stephen Farrell - 20 minutes. > > draft-winter-opsawg-eap-metadata-00 > > Discuss the SNMPSet vs YANG statement. > Benoit Claise. > > > OpsAWG: > ------------------ > Administrivia. > including Draft status updates, etc. > OpsAWG chairs - 10 minutes. > > Update on ETSI NFV Management & Orchestration WG > Ersue, Mehmet - 10 minutes > > Network Configuration Negotiation Problem Statement and Requirements > draft-jiang-config-negotiation-ps > Brian Carpenter - 15 minutes. > > The COMAN drafts: > draft-ersue-opsawg-coman-probstate-reqs-00 > draft-ersue-opsawg-coman-use-cases-00 > Ersue, Mehmet - 15 minutes. > > The CAPWAP drafts: > Comments/discussion on draft-ietf-opsawg-capwap-hybridmac > Comments/discussion on draft-zhang-opsawg-capwap-cds-01 > Rajesh Pazhyannur - 15 minutes. > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- ------ Best Regards, Dapeng Liu --047d7b3a916af8e53704f2b8a2cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi Warren, all,

    Regarding the=A0CAPWAP = drafts, we also update capwap 802.11n extension draft:=A0http://tools.iet= f.org/html/draft-ietf-opsawg-capwap-extension-02.
    May I have 5 minutes to present it?

    Thank= s,
    Dapeng Liu

    2014-02-15 2:02 GMT+08:00 Warren Kumari = <warren@kumari.ne= t>:
    Dear OpsAWG.

    Here is the preliminary schedule for the OpsAWG meeting at IETF 89 in Londo= n.
    Our meeting is currently scheduled for 1610-1840 GMT on Tuesday.

    Please come prepared, by having read the drafts, and armed with
    questions/ comments.

    We *do* still have a small amount of agenda time, please know if you
    have any issues you'd like to discuss / present, but remember -- you need to have had some (on-list!) discussions to qualify for this
    special, limited time offer...

    Thanks,
    Your friendly OpsAWG chairs...


    Joint OpsAWG / Ops-Area
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Ops Area, by the OpsADs
    --------------------------------------------
    Including such things as (non-authorative!):
    Invited talk on operational considerations in pervasive monitoring
    Stephen Farrell - 20 minutes.

    draft-winter-opsawg-eap-metadata-00

    Discuss the SNMPSet vs YANG statement.
    Benoit Claise.


    OpsAWG:
    ------------------
    Administrivia.
    including Draft status updates, etc.
    OpsAWG chairs - 10 minutes.

    Update on ETSI NFV Management & Orchestration WG
    Ersue, Mehmet - 10 minutes

    Network Configuration Negotiation Problem Statement and Requirements
    draft-jiang-config-negotiation-ps
    Brian Carpenter - 15 minutes.

    The COMAN drafts:
    draft-ersue-opsawg-coman-probstate-reqs-00
    draft-ersue-opsawg-coman-use-cases-00
    Ersue, Mehmet =A0- 15 minutes.

    The CAPWAP drafts:
    Comments/discussion on draft-ietf-opsawg-capwap-hybridmac
    Comments/discussion on draft-zhang-opsawg-capwap-cds-01
    Rajesh Pazhyannur - 15 minutes.

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



    --

    ------Best Regards,
    Dapeng Liu
    --047d7b3a916af8e53704f2b8a2cf-- From nobody Fri Feb 21 03:16: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 E57A51A051B for ; Fri, 21 Feb 2014 03:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 vTIpQ5fALisE for ; Fri, 21 Feb 2014 03:16:50 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 9BF5E1A0518 for ; Fri, 21 Feb 2014 03:16:48 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15307350ead3-41ad3; Fri, 21 Feb 2014 19:14:23 +0800 (CST) X-RM-TRANSID: 2ee15307350ead3-41ad3 Received: from X6X8D79D8F49E2 (unknown[125.97.242.41]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35307350e952-3383a; Fri, 21 Feb 2014 19:14:23 +0800 (CST) X-RM-TRANSID: 2ee35307350e952-3383a From: "Fan, Peng" To: "'Melinda Shore'" , References: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> <53040210.4090709@gmail.com> In-Reply-To: <53040210.4090709@gmail.com> Date: Fri, 21 Feb 2014 19:17:13 +0800 Message-ID: <00bb01cf2ef6$78a53840$69efa8c0$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3aC2AKs8uewBpS9881CS5YCqVhwNcZo7JmtQ1uWA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/E54IXgujk7TiYFOWJ8guWMuAaqo Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP 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, 21 Feb 2014 11:16:53 -0000 Hi Melinda, This document and the other capwap drafts in opsawg serve different purposes: new Model, new air-interface support and new control function support. After reading it I believe this document has evolved into a stable version with a straightforward solution, and is ready for adoption. Regards, Peng > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Melinda Shore > Sent: Wednesday, February 19, 2014 9:00 AM > To: opsawg@ietf.org > Subject: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in > CAPWAP > > Please note that Rajesh is planning to ask for working group adoption of this > document. Please give it a read and provide feedback on this mailing list. > Particularly interested in the question of how well it meshes with CAPWAP > documents we've already adopted. > > Melinda > > > > -------- Original Message -------- > Subject: [OPSAWG] Alternate Tunnel Encapsulation for Data Frames in CAPWAP > Date: Tue, 18 Feb 2014 22:10:10 +0000 > From: Rajesh Pazhyannur (rpazhyan) > To: opsawg@ietf.org > > > > Hello > > We have a submitted a new version of Alternate Tunnel Encapsulation for Data > Frames in > CAPWAP,_http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/_. > > Abstract > > In centralized IEEE 802.11 Wireless Local Area Network (WLAN) > architecture, the Access Controller (AC) isn't intelligent enough > actually to aggregate all the wireless frames, even the bandwidth > requirement in the access point is increasing. Thus it is a general > case in the existing operator's network that WTPs forward the > wireless frames directly to Access Router (AR) to avoid overload on > the AC. In this scenario, CAPWAP Control Channel and CAPWAP Data > Channel are separated from each other. This document extends CAPWAP > for applicability of CAPWAP Control and Data Channel separation. > > > We received some questions and suggestions from Dan Romascanu and John > Kaippallimalil on the mailing list on the previous draft. We have attempted to > address them in this draft. Specifically, > > 1. How does this draft address signaling, discovery mechanisms related > to setting up alternate tunnel. (ans. Tunneling protocols like > L2TPv3, IP/GRE (PMIPv6) already have a signaling mechanism. This > draft focuses on specifying the tunnel type and provides a container > to hold message elements) > 2. Need for alternate tunnel encapsulation (given the existence of > defined mode with local bridging) > > > We would like to get it adopted as a working group item and would like feedback > on whether we are on track. > > > thanks > > Regards > > Rajesh > > From nobody Fri Feb 21 16:32:27 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 9BECD1A02B5; Fri, 21 Feb 2014 16:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 SiTWKTQACwHH; Fri, 21 Feb 2014 16:32:21 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 6615A1A01ED; Fri, 21 Feb 2014 16:32:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 50B867FC392; Fri, 21 Feb 2014 16:32:17 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140222003217.50B867FC392@rfc-editor.org> Date: Fri, 21 Feb 2014 16:32:17 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/jKGcaCtDPKxMcU35xoT1DOl7LEA Cc: drafts-update-ref@iana.org, opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper (EFMCu) Interfaces MIB 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, 22 Feb 2014 00:32:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7124 Title: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB Author: E. Beili Status: Standards Track Stream: IETF Date: February 2014 Mailbox: edward.beili@actelis.com Pages: 6 Characters: 12123 Updates: RFC 5066 I-D Tag: draft-ietf-opsawg-rfc5066bis-07.txt URL: http://www.rfc-editor.org/rfc/rfc7124.txt This document updates RFC 5066. It amends that specification by informing the Internet community about the transition of the EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group. This document is a product of the Operations and Management Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Feb 21 16:47:24 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 568C21A0302 for ; Fri, 21 Feb 2014 16:47:21 -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 8W9uf-dsNlK5 for ; Fri, 21 Feb 2014 16:47:18 -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 946431A0313 for ; Fri, 21 Feb 2014 16:47:15 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kp14so4166461pab.20 for ; Fri, 21 Feb 2014 16:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zeJN9M+7xCFmFS+segGtq6AkWvolxm/9MEMtmXOVigI=; b=UR/TbBD2W3TBvdIePMr9uKu+8dWGjRe1HKPx4Ctec9YzghsxBA06GiWBI6ZVqgDIIF wSNW0kk83ofJDVY2y0am1FQuV3EakPcXxIQVEiLSL8Uu73NJTcPyeeEQlSUmREB4KI2r dDHRwOFgMfOxblobpiTO2N+doOwLshvRgxA7vscTrjhdEBQDtoA/5zZchp9cAkmZqcqx 18JwPJy+GABMhOLw7J/wFRno6hHyNRry5IyCXFaUkYv7BprtT5zvMh0oJthCyAVMQNgk cnrHVvE+p7Hv53IlaSir/e9jmoVKlRIHixhU/oyNWQl+X8NPoeCkGKm6BHmgyINTR4pl jCsw== X-Received: by 10.66.248.227 with SMTP id yp3mr12114377pac.116.1393030031653; Fri, 21 Feb 2014 16:47:11 -0800 (PST) Received: from spandex.local (216-67-47-153-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.47.153]) by mx.google.com with ESMTPSA id js7sm25417537pbc.35.2014.02.21.16.47.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 16:47:11 -0800 (PST) Message-ID: <5307F38D.1080908@gmail.com> Date: Fri, 21 Feb 2014 15:47:09 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <20140222003217.50B867FC392@rfc-editor.org> In-Reply-To: <20140222003217.50B867FC392@rfc-editor.org> X-Forwarded-Message-Id: <20140222003217.50B867FC392@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/tSHT5oeZBDW3TpcYAhuhttT7sc0 Cc: Edward Beili Subject: [OPSAWG] Fwd: RFC 7124 on Ethernet in the First Mile Copper (EFMCu) Interfaces MIB 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, 22 Feb 2014 00:47:21 -0000 5066bis has just been published. Many thanks to Ed, and to the reviewers who put so much time into this. Melinda -------- Original Message -------- Subject: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper (EFMCu) Interfaces MIB Date: Fri, 21 Feb 2014 16:32:17 -0800 (PST) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, opsawg@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7124 Title: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB Author: E. Beili Status: Standards Track Stream: IETF Date: February 2014 Mailbox: edward.beili@actelis.com Pages: 6 Characters: 12123 Updates: RFC 5066 I-D Tag: draft-ietf-opsawg-rfc5066bis-07.txt URL: http://www.rfc-editor.org/rfc/rfc7124.txt This document updates RFC 5066. It amends that specification by informing the Internet community about the transition of the EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group. This document is a product of the Operations and Management Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Sun Feb 23 18:28:04 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 4A1F01A0242 for ; Sun, 23 Feb 2014 18:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 tJk3ls-GCqlG for ; Sun, 23 Feb 2014 18:28:00 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B98141A0251 for ; Sun, 23 Feb 2014 18:28:00 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so5219331vcb.31 for ; Sun, 23 Feb 2014 18:28:00 -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=ikI6wY5PN9Fa/72Yqz5ZnLIiAWkaN5GMyHX6wrcvMFA=; b=yemokOgNrYn8GHb/sRjX13IGc8Ebc53kQ9uuq+UwnMA65Po9iFQjU/dJG4Ap7aI1GQ g5Y565Ywioav62wryMxQjOaTMQxyyO62vyRlNcWUG5GwtaJErVOsV+Xraylg0dNdjKUY p2vVp1OSJS29oUOmtBpogIu49vE+cSQrTifvvB6IjCY4ljfyTyt9xuMvlb2pX4uVr0yy nNz6nlq5i4/tR2sDDdID698kakQHO4gq7Uof1WHzGqByBdGxgvdlRFm0oLPO0CiHfgrd p7208mjHpR8l7IUTbQkTMYvOEpEbv/ANxmSm2USQBpDlZrbUoelioNFfLAYiFuDSUteN VcCw== MIME-Version: 1.0 X-Received: by 10.220.67.18 with SMTP id p18mr11117810vci.14.1393208880196; Sun, 23 Feb 2014 18:28:00 -0800 (PST) Received: by 10.221.24.146 with HTTP; Sun, 23 Feb 2014 18:28:00 -0800 (PST) In-Reply-To: <53040210.4090709@gmail.com> References: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> <53040210.4090709@gmail.com> Date: Mon, 24 Feb 2014 10:28:00 +0800 Message-ID: From: Liu Dapeng To: Melinda Shore Content-Type: multipart/alternative; boundary=047d7b343f9a66ef5404f31db871 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/15znEYILyHqeZ4847f5LYWNvF-8 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP 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, 24 Feb 2014 02:28:03 -0000 --047d7b343f9a66ef5404f31db871 Content-Type: text/plain; charset=ISO-8859-1 Hello all, The control/data channel separation of CAPWAP is a very useful deployment use case for operators. In that sense, I support the adoption of this draft and I do not see there is overlap/conflict with the already adopted CAPWAP extension drafts. Cheers, Dapeng Liu 2014-02-19 9:00 GMT+08:00 Melinda Shore : > Please note that Rajesh is planning to ask for working > group adoption of this document. Please give it a read > and provide feedback on this mailing list. Particularly > interested in the question of how well it meshes with > CAPWAP documents we've already adopted. > > Melinda > > > > -------- Original Message -------- > Subject: [OPSAWG] Alternate Tunnel Encapsulation for Data Frames in > CAPWAP > Date: Tue, 18 Feb 2014 22:10:10 +0000 > From: Rajesh Pazhyannur (rpazhyan) > To: opsawg@ietf.org > > > > Hello > > We have a submitted a new version of Alternate Tunnel Encapsulation for > Data Frames in > CAPWAP,_http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/_. > > Abstract > > In centralized IEEE 802.11 Wireless Local Area Network (WLAN) > architecture, the Access Controller (AC) isn't intelligent enough > actually to aggregate all the wireless frames, even the bandwidth > requirement in the access point is increasing. Thus it is a general > case in the existing operator's network that WTPs forward the > wireless frames directly to Access Router (AR) to avoid overload on > the AC. In this scenario, CAPWAP Control Channel and CAPWAP Data > Channel are separated from each other. This document extends CAPWAP > for applicability of CAPWAP Control and Data Channel separation. > > > We received some questions and suggestions from Dan Romascanu and John > Kaippallimalil on the mailing list on the previous draft. We have > attempted to address them in this draft. Specifically, > > 1. How does this draft address signaling, discovery mechanisms related > to setting up alternate tunnel. (ans. Tunneling protocols like > L2TPv3, IP/GRE (PMIPv6) already have a signaling mechanism. This > draft focuses on specifying the tunnel type and provides a container > to hold message elements) > 2. Need for alternate tunnel encapsulation (given the existence of > defined mode with local bridging) > > > We would like to get it adopted as a working group item and would like > feedback on whether we are on track. > > > thanks > > Regards > > Rajesh > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > -- ------ Best Regards, Dapeng Liu --047d7b343f9a66ef5404f31db871 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hello all,

    The control/data channel sep= aration of CAPWAP is a very useful deployment use case for operators.
    =
    In that sense, I support the adoption of this draft and I do not see t= here is overlap/conflict with the already adopted CAPWAP extension drafts.<= /div>

    Cheers,
    Dapeng Liu
    2014-02-19 9:00 GMT+08:00 Melinda Shore <melinda.s= hore@gmail.com>:
    Please note that Rajesh is planning to ask f= or working
    group adoption of this document. =A0Please give it a read
    and provide feedback on this mailing list. =A0Particularly
    interested in the question of how well it meshes with
    CAPWAP documents we've already adopted.

    Melinda



    -------- Original Message --------
    Subject: =A0 =A0 =A0 =A0[OPSAWG] Alternate Tunnel Encapsulation for Data Fr= ames in CAPWAP
    Date: =A0 Tue, 18 Feb 2014 22:10:10 +0000
    From: =A0 Rajesh Pazhyannur (rpazhyan) <rpazhyan@cisco.com>
    To: =A0 =A0 opsawg@iet= f.org <opsawg@i= etf.org>



    Hello

    We have a submitted a new version of Alternate Tunnel Encapsulation for
    Data Frames in
    CAPWAP,_http://datatracker.ietf.org/doc/draft-zhan= g-opsawg-capwap-cds/_.

    Abstract

    =A0 =A0In centralized IEEE 802.11 Wireless Local Area Network (WLAN)
    =A0 =A0architecture, the Access Controller (AC) isn't intelligent enoug= h
    =A0 =A0actually to aggregate all the wireless frames, even the bandwidth =A0 =A0requirement in the access point is increasing. =A0Thus it is a gener= al
    =A0 =A0case in the existing operator's network that WTPs forward the =A0 =A0wireless frames directly to Access Router (AR) to avoid overload on<= br> =A0 =A0the AC. =A0In this scenario, CAPWAP Control Channel and CAPWAP Data<= br> =A0 =A0Channel are separated from each other. =A0This document extends CAPW= AP
    =A0 =A0for applicability of CAPWAP Control and Data Channel separation.


    We received some questions and suggestions from Dan Romascanu and John
    Kaippallimalil on the mailing list on the previous draft. We have
    attempted to address them in this draft. Specifically,

    =A01. How does this draft address signaling, discovery mechanisms rel= ated
    =A0 =A0 to setting up alternate tunnel. (ans. Tunneling protocols like=
    =A0 =A0 L2TPv3, IP/GRE (PMIPv6) already have a signaling mechanism. This =A0 =A0 draft focuses on specifying the tunnel type and provides a containe= r
    =A0 =A0 to hold message elements)
    =A02. Need for alternate tunnel encapsulation (given the existence of=
    =A0 =A0 defined mode with local bridging)


    We would like to get it adopted as a working group item and would like
    feedback on whether we are on track.


    thanks

    Regards

    Rajesh




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




    --

    ----= --
    Best Regards,
    Dapeng Liu
    --047d7b343f9a66ef5404f31db871-- From nobody Sun Feb 23 22:16:23 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 796441A031F for ; Sun, 23 Feb 2014 22:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.839 X-Spam-Level: *** X-Spam-Status: No, score=3.839 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, 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 JPdHiuHGOEd2 for ; Sun, 23 Feb 2014 22:16:18 -0800 (PST) Received: from snt0-omc1-s12.snt0.hotmail.com (snt0-omc1-s12.snt0.hotmail.com [65.55.90.23]) by ietfa.amsl.com (Postfix) with ESMTP id A1A0D1A030B for ; Sun, 23 Feb 2014 22:16:18 -0800 (PST) Received: from SNT146-DS18 ([65.55.90.9]) by snt0-omc1-s12.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 23 Feb 2014 22:16:18 -0800 X-TMN: [tQYvq/pMZXdLUUWEgCz3MWXk5bZUTwzvO9qP3L6iR68=] X-Originating-Email: [fuqiao1@outlook.com] Message-ID: From: Qiao Fu To: References: In-Reply-To: Date: Mon, 24 Feb 2014 14:18:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8tDfEbaisiQv5bTmWcBnXDPj6OYABoW06A Content-Language: zh-cn X-OriginalArrivalTime: 24 Feb 2014 06:16:18.0224 (UTC) FILETIME=[EDECD300:01CF3127] Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/rUBaK6yQVeZgFXae7jawjuKDal4 Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frame in CAPWAP 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, 24 Feb 2014 06:16:20 -0000 Hi, all. I have read through the draft and here are some comment. This draft addresses on two shortcomings of the current CAPWAP.=20 1) the current one does not allow the WTP to tunnel data frames to an endpoint other than AC; 2) it does not allow the WTP to tunnel data frames using any = encapsulation other than CAPWAP. This draft presents a case in which the WTP may have the requirement to tunnel a frame to an AR but not an AC. Moreover, when tunneling to an = AR, the choice of tunnel encapsulation may be extended to other types, such = as L2TP, L2TPv3, IP-in-IP, IP/GRE and etc.. The authors further describe = how the WTP can be configured with this alternate tunnel. The suggested procedure to establish the alternate tunnel encapsulation is also = presented. The case presented in the draft is quite clear, and the solution of alternate tunnel encapsulation in the draft is quite straightforward. Therefore, I support for working group adoption. Best regards! Qiao Fu -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: OPSAWG [mailto:opsawg-bounces@ietf.org] =B4=FA=B1=ED = opsawg-request@ietf.org =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C219=C8=D5 9:00 =CA=D5=BC=FE=C8=CB: opsawg@ietf.org =D6=F7=CC=E2: OPSAWG Digest, Vol 81, Issue 35 Send OPSAWG mailing list submissions to opsawg@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/opsawg or, via email, send a message with subject or body 'help' to opsawg-request@ietf.org You can reach the person managing the list at opsawg-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OPSAWG digest..." Today's Topics: 1. Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP (Melinda Shore) ---------------------------------------------------------------------- Message: 1 Date: Tue, 18 Feb 2014 16:00:00 -0900 From: Melinda Shore To: "opsawg@ietf.org" Subject: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP Message-ID: <53040210.4090709@gmail.com> Content-Type: text/plain; charset=3D"iso-8859-1" Please note that Rajesh is planning to ask for working group adoption of this document. Please give it a read and provide feedback on this mailing list. Particularly interested in the question of how well it meshes with CAPWAP documents we've already adopted. Melinda -------- Original Message -------- Subject: [OPSAWG] Alternate Tunnel Encapsulation for Data Frames in CAPWAP Date: Tue, 18 Feb 2014 22:10:10 +0000 From: Rajesh Pazhyannur (rpazhyan) To: opsawg@ietf.org Hello We have a submitted a new version of Alternate Tunnel Encapsulation for Data Frames in CAPWAP,_http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/_. Abstract In centralized IEEE 802.11 Wireless Local Area Network (WLAN) architecture, the Access Controller (AC) isn't intelligent enough actually to aggregate all the wireless frames, even the bandwidth requirement in the access point is increasing. Thus it is a general case in the existing operator's network that WTPs forward the wireless frames directly to Access Router (AR) to avoid overload on the AC. In this scenario, CAPWAP Control Channel and CAPWAP Data Channel are separated from each other. This document extends CAPWAP for applicability of CAPWAP Control and Data Channel separation. We received some questions and suggestions from Dan Romascanu and John Kaippallimalil on the mailing list on the previous draft. We have attempted to address them in this draft. Specifically, 1. How does this draft address signaling, discovery mechanisms related to setting up alternate tunnel. (ans. Tunneling protocols like L2TPv3, IP/GRE (PMIPv6) already have a signaling mechanism. This draft focuses on specifying the tunnel type and provides a container to hold message elements) 2. Need for alternate tunnel encapsulation (given the existence of defined mode with local bridging) We would like to get it adopted as a working group item and would like feedback on whether we are on track. thanks Regards Rajesh -------------- next part -------------- _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------------------------------ Subject: Digest Footer _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------------------------------ End of OPSAWG Digest, Vol 81, Issue 35 ************************************** From nobody Sun Feb 23 22:41: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 5D0031A0339 for ; Sun, 23 Feb 2014 22:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 uuyNDWCue7yV for ; Sun, 23 Feb 2014 22:41:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 42C491A0103 for ; Sun, 23 Feb 2014 22:41:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDX11868; Mon, 24 Feb 2014 06:41:43 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 06:41:39 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 06:41:42 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.206]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 24 Feb 2014 14:41:38 +0800 From: Sheng Jiang To: Liu Dapeng , Melinda Shore Thread-Topic: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP Thread-Index: AQHPMQgR475fkAHdo0+HxltF0idFF5rD9Log Date: Mon, 24 Feb 2014 06:41:37 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE0AF70@nkgeml512-mbx.china.huawei.com> References: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> <53040210.4090709@gmail.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AE0AF70nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/UUMuLES_fv2ujJ5XgoG40x54r9U Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP 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, 24 Feb 2014 06:41:48 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AE0AF70nkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEsIHN1cHBvcnQgYWRvcHRpb24uDQoNClNoZW5nDQoNCkZyb206IE9QU0FXRyBbbWFpbHRvOm9w c2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGl1IERhcGVuZw0KU2VudDogTW9u ZGF5LCBGZWJydWFyeSAyNCwgMjAxNCAxMDoyOCBBTQ0KVG86IE1lbGluZGEgU2hvcmUNCkNjOiBv cHNhd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT1BTQVdHXSBGd2Q6IEFsdGVybmF0ZSBUdW5u ZWwgRW5jYXBzdWxhdGlvbiBmb3IgRGF0YSBGcmFtZXMgaW4gQ0FQV0FQDQoNCkhlbGxvIGFsbCwN Cg0KVGhlIGNvbnRyb2wvZGF0YSBjaGFubmVsIHNlcGFyYXRpb24gb2YgQ0FQV0FQIGlzIGEgdmVy eSB1c2VmdWwgZGVwbG95bWVudCB1c2UgY2FzZSBmb3Igb3BlcmF0b3JzLg0KSW4gdGhhdCBzZW5z ZSwgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGFuZCBJIGRvIG5vdCBzZWUg dGhlcmUgaXMgb3ZlcmxhcC9jb25mbGljdCB3aXRoIHRoZSBhbHJlYWR5IGFkb3B0ZWQgQ0FQV0FQ IGV4dGVuc2lvbiBkcmFmdHMuDQoNCkNoZWVycywNCkRhcGVuZyBMaXUNCjIwMTQtMDItMTkgOTow MCBHTVQrMDg6MDAgTWVsaW5kYSBTaG9yZSA8bWVsaW5kYS5zaG9yZUBnbWFpbC5jb208bWFpbHRv Om1lbGluZGEuc2hvcmVAZ21haWwuY29tPj46DQpQbGVhc2Ugbm90ZSB0aGF0IFJhamVzaCBpcyBw bGFubmluZyB0byBhc2sgZm9yIHdvcmtpbmcNCmdyb3VwIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1l bnQuICBQbGVhc2UgZ2l2ZSBpdCBhIHJlYWQNCmFuZCBwcm92aWRlIGZlZWRiYWNrIG9uIHRoaXMg bWFpbGluZyBsaXN0LiAgUGFydGljdWxhcmx5DQppbnRlcmVzdGVkIGluIHRoZSBxdWVzdGlvbiBv ZiBob3cgd2VsbCBpdCBtZXNoZXMgd2l0aA0KQ0FQV0FQIGRvY3VtZW50cyB3ZSd2ZSBhbHJlYWR5 IGFkb3B0ZWQuDQoNCk1lbGluZGENCg0KDQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0tLS0NClN1YmplY3Q6ICAgICAgICBbT1BTQVdHXSBBbHRlcm5hdGUgVHVubmVsIEVuY2Fwc3Vs YXRpb24gZm9yIERhdGEgRnJhbWVzIGluIENBUFdBUA0KRGF0ZTogICBUdWUsIDE4IEZlYiAyMDE0 IDIyOjEwOjEwICswMDAwDQpGcm9tOiAgIFJhamVzaCBQYXpoeWFubnVyIChycGF6aHlhbikgPHJw YXpoeWFuQGNpc2NvLmNvbTxtYWlsdG86cnBhemh5YW5AY2lzY28uY29tPj4NClRvOiAgICAgb3Bz YXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+IDxvcHNhd2dAaWV0Zi5vcmc8bWFp bHRvOm9wc2F3Z0BpZXRmLm9yZz4+DQoNCg0KDQpIZWxsbw0KDQpXZSBoYXZlIGEgc3VibWl0dGVk IGEgbmV3IHZlcnNpb24gb2YgQWx0ZXJuYXRlIFR1bm5lbCBFbmNhcHN1bGF0aW9uIGZvcg0KRGF0 YSBGcmFtZXMgaW4NCkNBUFdBUCxfaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC16aGFuZy1vcHNhd2ctY2Fwd2FwLWNkcy9fLg0KDQpBYnN0cmFjdA0KDQogICBJbiBjZW50cmFs aXplZCBJRUVFIDgwMi4xMSBXaXJlbGVzcyBMb2NhbCBBcmVhIE5ldHdvcmsgKFdMQU4pDQogICBh cmNoaXRlY3R1cmUsIHRoZSBBY2Nlc3MgQ29udHJvbGxlciAoQUMpIGlzbid0IGludGVsbGlnZW50 IGVub3VnaA0KICAgYWN0dWFsbHkgdG8gYWdncmVnYXRlIGFsbCB0aGUgd2lyZWxlc3MgZnJhbWVz LCBldmVuIHRoZSBiYW5kd2lkdGgNCiAgIHJlcXVpcmVtZW50IGluIHRoZSBhY2Nlc3MgcG9pbnQg aXMgaW5jcmVhc2luZy4gIFRodXMgaXQgaXMgYSBnZW5lcmFsDQogICBjYXNlIGluIHRoZSBleGlz dGluZyBvcGVyYXRvcidzIG5ldHdvcmsgdGhhdCBXVFBzIGZvcndhcmQgdGhlDQogICB3aXJlbGVz cyBmcmFtZXMgZGlyZWN0bHkgdG8gQWNjZXNzIFJvdXRlciAoQVIpIHRvIGF2b2lkIG92ZXJsb2Fk IG9uDQogICB0aGUgQUMuICBJbiB0aGlzIHNjZW5hcmlvLCBDQVBXQVAgQ29udHJvbCBDaGFubmVs IGFuZCBDQVBXQVAgRGF0YQ0KICAgQ2hhbm5lbCBhcmUgc2VwYXJhdGVkIGZyb20gZWFjaCBvdGhl ci4gIFRoaXMgZG9jdW1lbnQgZXh0ZW5kcyBDQVBXQVANCiAgIGZvciBhcHBsaWNhYmlsaXR5IG9m IENBUFdBUCBDb250cm9sIGFuZCBEYXRhIENoYW5uZWwgc2VwYXJhdGlvbi4NCg0KDQpXZSByZWNl aXZlZCBzb21lIHF1ZXN0aW9ucyBhbmQgc3VnZ2VzdGlvbnMgZnJvbSBEYW4gUm9tYXNjYW51IGFu ZCBKb2huDQpLYWlwcGFsbGltYWxpbCBvbiB0aGUgbWFpbGluZyBsaXN0IG9uIHRoZSBwcmV2aW91 cyBkcmFmdC4gV2UgaGF2ZQ0KYXR0ZW1wdGVkIHRvIGFkZHJlc3MgdGhlbSBpbiB0aGlzIGRyYWZ0 LiBTcGVjaWZpY2FsbHksDQogMS4gSG93IGRvZXMgdGhpcyBkcmFmdCBhZGRyZXNzIHNpZ25hbGlu ZywgZGlzY292ZXJ5IG1lY2hhbmlzbXMgcmVsYXRlZA0KICAgIHRvIHNldHRpbmcgdXAgYWx0ZXJu YXRlIHR1bm5lbC4gKGFucy4gVHVubmVsaW5nIHByb3RvY29scyBsaWtlDQogICAgTDJUUHYzLCBJ UC9HUkUgKFBNSVB2NikgYWxyZWFkeSBoYXZlIGEgc2lnbmFsaW5nIG1lY2hhbmlzbS4gVGhpcw0K ICAgIGRyYWZ0IGZvY3VzZXMgb24gc3BlY2lmeWluZyB0aGUgdHVubmVsIHR5cGUgYW5kIHByb3Zp ZGVzIGEgY29udGFpbmVyDQogICAgdG8gaG9sZCBtZXNzYWdlIGVsZW1lbnRzKQ0KIDIuIE5lZWQg Zm9yIGFsdGVybmF0ZSB0dW5uZWwgZW5jYXBzdWxhdGlvbiAoZ2l2ZW4gdGhlIGV4aXN0ZW5jZSBv Zg0KICAgIGRlZmluZWQgbW9kZSB3aXRoIGxvY2FsIGJyaWRnaW5nKQ0KDQoNCldlIHdvdWxkIGxp a2UgdG8gZ2V0IGl0IGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0gYW5kIHdvdWxkIGxp a2UNCmZlZWRiYWNrIG9uIHdoZXRoZXIgd2UgYXJlIG9uIHRyYWNrLg0KDQoNCnRoYW5rcw0KDQpS ZWdhcmRzDQoNClJhamVzaA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FXR0BpZXRmLm9yZzxtYWls dG86T1BTQVdHQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vcHNhd2cNCg0KDQoNCi0tDQoNCi0tLS0tLQ0KQmVzdCBSZWdhcmRzLA0KRGFwZW5nIExpdQ0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AE0AF70nkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAu MHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m IzQzOzEsIHN1cHBvcnQgYWRvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9QU0FXRyBbbWFpbHRvOm9wc2F3 Zy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5MaXUgRGFwZW5nPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgMTA6MjggQU08YnI+DQo8Yj5U bzo8L2I+IE1lbGluZGEgU2hvcmU8YnI+DQo8Yj5DYzo8L2I+IG9wc2F3Z0BpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09QU0FXR10gRndkOiBBbHRlcm5hdGUgVHVubmVsIEVuY2Fw c3VsYXRpb24gZm9yIERhdGEgRnJhbWVzIGluIENBUFdBUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGNvbnRyb2wvZGF0YSBjaGFubmVsIHNlcGFyYXRpb24gb2YgQ0FQ V0FQIGlzIGEgdmVyeSB1c2VmdWwgZGVwbG95bWVudCB1c2UgY2FzZSBmb3Igb3BlcmF0b3JzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5JbiB0aGF0IHNlbnNlLCBJIHN1cHBvcnQgdGhlIGFkb3B0aW9u IG9mIHRoaXMgZHJhZnQgYW5kIEkgZG8gbm90IHNlZSB0aGVyZSBpcyBvdmVybGFwL2NvbmZsaWN0 IHdpdGggdGhlIGFscmVhZHkgYWRvcHRlZCBDQVBXQVAgZXh0ZW5zaW9uIGRyYWZ0cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoZWVycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+RGFwZW5nIExpdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjIwMTQtMDItMTkgOTowMCBHTVQmIzQzOzA4OjAwIE1lbGluZGEgU2hvcmUgJmx0OzxhIGhy ZWY9Im1haWx0bzptZWxpbmRhLnNob3JlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1lbGlu ZGEuc2hvcmVAZ21haWwuY29tPC9hPiZndDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBub3RlIHRoYXQgUmFqZXNo IGlzIHBsYW5uaW5nIHRvIGFzayBmb3Igd29ya2luZzxicj4NCmdyb3VwIGFkb3B0aW9uIG9mIHRo aXMgZG9jdW1lbnQuICZuYnNwO1BsZWFzZSBnaXZlIGl0IGEgcmVhZDxicj4NCmFuZCBwcm92aWRl IGZlZWRiYWNrIG9uIHRoaXMgbWFpbGluZyBsaXN0LiAmbmJzcDtQYXJ0aWN1bGFybHk8YnI+DQpp bnRlcmVzdGVkIGluIHRoZSBxdWVzdGlvbiBvZiBob3cgd2VsbCBpdCBtZXNoZXMgd2l0aDxicj4N CkNBUFdBUCBkb2N1bWVudHMgd2UndmUgYWxyZWFkeSBhZG9wdGVkLjxicj4NCjxicj4NCk1lbGlu ZGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0tLS08YnI+DQpTdWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbT1BT QVdHXSBBbHRlcm5hdGUgVHVubmVsIEVuY2Fwc3VsYXRpb24gZm9yIERhdGEgRnJhbWVzIGluIENB UFdBUDxicj4NCkRhdGU6ICZuYnNwOyBUdWUsIDE4IEZlYiAyMDE0IDIyOjEwOjEwICYjNDM7MDAw MDxicj4NCkZyb206ICZuYnNwOyBSYWplc2ggUGF6aHlhbm51ciAocnBhemh5YW4pICZsdDs8YSBo cmVmPSJtYWlsdG86cnBhemh5YW5AY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cnBhemh5YW5A Y2lzY28uY29tPC9hPiZndDs8YnI+DQpUbzogJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86 b3BzYXdnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3BzYXdnQGlldGYub3JnPC9hPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9wc2F3Z0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KSGVsbG88YnI+DQo8YnI+DQpX ZSBoYXZlIGEgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgQWx0ZXJuYXRlIFR1bm5lbCBFbmNh cHN1bGF0aW9uIGZvcjxicj4NCkRhdGEgRnJhbWVzIGluPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q0FQV0FQLF88 YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLW9wc2F3 Zy1jYXB3YXAtY2RzL18iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXpoYW5nLW9wc2F3Zy1jYXB3YXAtY2RzL188L2E+LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpBYnN0cmFjdDxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDtJbiBjZW50cmFsaXplZCBJRUVFIDgwMi4xMSBXaXJlbGVzcyBMb2NhbCBBcmVh IE5ldHdvcmsgKFdMQU4pPGJyPg0KJm5ic3A7ICZuYnNwO2FyY2hpdGVjdHVyZSwgdGhlIEFjY2Vz cyBDb250cm9sbGVyIChBQykgaXNuJ3QgaW50ZWxsaWdlbnQgZW5vdWdoPGJyPg0KJm5ic3A7ICZu YnNwO2FjdHVhbGx5IHRvIGFnZ3JlZ2F0ZSBhbGwgdGhlIHdpcmVsZXNzIGZyYW1lcywgZXZlbiB0 aGUgYmFuZHdpZHRoPGJyPg0KJm5ic3A7ICZuYnNwO3JlcXVpcmVtZW50IGluIHRoZSBhY2Nlc3Mg cG9pbnQgaXMgaW5jcmVhc2luZy4gJm5ic3A7VGh1cyBpdCBpcyBhIGdlbmVyYWw8YnI+DQombmJz cDsgJm5ic3A7Y2FzZSBpbiB0aGUgZXhpc3Rpbmcgb3BlcmF0b3IncyBuZXR3b3JrIHRoYXQgV1RQ cyBmb3J3YXJkIHRoZTxicj4NCiZuYnNwOyAmbmJzcDt3aXJlbGVzcyBmcmFtZXMgZGlyZWN0bHkg dG8gQWNjZXNzIFJvdXRlciAoQVIpIHRvIGF2b2lkIG92ZXJsb2FkIG9uPGJyPg0KJm5ic3A7ICZu YnNwO3RoZSBBQy4gJm5ic3A7SW4gdGhpcyBzY2VuYXJpbywgQ0FQV0FQIENvbnRyb2wgQ2hhbm5l bCBhbmQgQ0FQV0FQIERhdGE8YnI+DQombmJzcDsgJm5ic3A7Q2hhbm5lbCBhcmUgc2VwYXJhdGVk IGZyb20gZWFjaCBvdGhlci4gJm5ic3A7VGhpcyBkb2N1bWVudCBleHRlbmRzIENBUFdBUDxicj4N CiZuYnNwOyAmbmJzcDtmb3IgYXBwbGljYWJpbGl0eSBvZiBDQVBXQVAgQ29udHJvbCBhbmQgRGF0 YSBDaGFubmVsIHNlcGFyYXRpb24uPGJyPg0KPGJyPg0KPGJyPg0KV2UgcmVjZWl2ZWQgc29tZSBx dWVzdGlvbnMgYW5kIHN1Z2dlc3Rpb25zIGZyb20gRGFuIFJvbWFzY2FudSBhbmQgSm9objxicj4N CkthaXBwYWxsaW1hbGlsIG9uIHRoZSBtYWlsaW5nIGxpc3Qgb24gdGhlIHByZXZpb3VzIGRyYWZ0 LiBXZSBoYXZlPGJyPg0KYXR0ZW1wdGVkIHRvIGFkZHJlc3MgdGhlbSBpbiB0aGlzIGRyYWZ0LiBT cGVjaWZpY2FsbHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7MS4gSG93IGRvZXMgdGhpcyBkcmFmdCBh ZGRyZXNzIHNpZ25hbGluZywgZGlzY292ZXJ5IG1lY2hhbmlzbXMgcmVsYXRlZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7ICZuYnNwOyB0byBzZXR0aW5nIHVwIGFsdGVybmF0ZSB0dW5uZWwuIChhbnMuIFR1 bm5lbGluZyBwcm90b2NvbHMgbGlrZTxicj4NCiZuYnNwOyAmbmJzcDsgTDJUUHYzLCBJUC9HUkUg KFBNSVB2NikgYWxyZWFkeSBoYXZlIGEgc2lnbmFsaW5nIG1lY2hhbmlzbS4gVGhpczxicj4NCiZu YnNwOyAmbmJzcDsgZHJhZnQgZm9jdXNlcyBvbiBzcGVjaWZ5aW5nIHRoZSB0dW5uZWwgdHlwZSBh bmQgcHJvdmlkZXMgYSBjb250YWluZXI8YnI+DQombmJzcDsgJm5ic3A7IHRvIGhvbGQgbWVzc2Fn ZSBlbGVtZW50cyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsyLiBOZWVkIGZvciBhbHRlcm5hdGUgdHVu bmVsIGVuY2Fwc3VsYXRpb24gKGdpdmVuIHRoZSBleGlzdGVuY2Ugb2Y8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgZGVmaW5lZCBt b2RlIHdpdGggbG9jYWwgYnJpZGdpbmcpPGJyPg0KPGJyPg0KPGJyPg0KV2Ugd291bGQgbGlrZSB0 byBnZXQgaXQgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbSBhbmQgd291bGQgbGlrZTxi cj4NCmZlZWRiYWNrIG9uIHdoZXRoZXIgd2UgYXJlIG9uIHRyYWNrLjxicj4NCjxicj4NCjxicj4N CnRoYW5rczxicj4NCjxicj4NClJlZ2FyZHM8YnI+DQo8YnI+DQpSYWplc2g8YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpPUFNBV0cgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9QU0FXR0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPk9QU0FXR0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+LS0gPGJyPg0KPGJyPg0KLS0tLS0tPGJyPg0KQmVzdCBSZWdhcmRzLDxicj4NCkRh cGVuZyBMaXUgPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B923AE0AF70nkgeml512mbxchi_-- From nobody Sun Feb 23 22:43: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 377F51A0339 for ; Sun, 23 Feb 2014 22:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 2xhXECAvNCAY for ; Sun, 23 Feb 2014 22:43:46 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE771A0103 for ; Sun, 23 Feb 2014 22:43:46 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so5917115pdb.38 for ; Sun, 23 Feb 2014 22:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dg0n94b7T2GYutvU8htCCSu0n7bpmZQSXn/VlBfN7r8=; b=AM72jK8Bp7vaEr0MqSgumaxK4+S7TEk63UbWSyuQK0dmmFdMcv32uadAsq3KGKfgev zRrjA6aiY8GeKsGO9ICzLmazPMWVtrxmzXonHU2XY8Ne6wxHdv/1xSLtbopM4gLKPXxx 9n5rDyP4ieJRjIjBfQKv0IxDem5b8b6s6TpR5VczOdYujRoV2fRFf2CKnEt7ZIHQ6k91 1u7rhck5fM42me/XaH8JKTk2RqM4j0Tdom3I83izrkLdb5q3VZHCOlFP5rg1SMk1h+g0 6HaE1adOIBuJnB3W+a3cQXLoKFJfhWIHX2Cl6H8aNDZ6RYyq66YzGzaN0J8tPXQ2iqfF bfcw== X-Received: by 10.67.3.68 with SMTP id bu4mr23233639pad.144.1393224226353; Sun, 23 Feb 2014 22:43:46 -0800 (PST) Received: from spandex.local (63-140-68-38-rb2.sol.dsl.dynamic.acsalaska.net. [63.140.68.38]) by mx.google.com with ESMTPSA id ns7sm46506918pbc.32.2014.02.23.22.43.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Feb 2014 22:43:45 -0800 (PST) Message-ID: <530AEA1D.3000008@gmail.com> Date: Sun, 23 Feb 2014 21:43:41 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> <53040210.4090709@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AE0AF70@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AE0AF70@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/_8DJD4RVVPEk8UHQ8Vj_ax0Bfb4 Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP 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, 24 Feb 2014 06:43:48 -0000 We have not yet put out a call for adoption. At this point we're trying to get a handle on relevance and quality. To that end, discussion is very useful, statements of support less so. Melinda From nobody Mon Feb 24 01:03:04 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 8D6DB1A03DE for ; Mon, 24 Feb 2014 01:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 5KGbnR0kww13 for ; Mon, 24 Feb 2014 01:03:01 -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 0D5FD1A0834 for ; Mon, 24 Feb 2014 01:03:00 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAOAJC1OHCzIm/2dsb2JhbABZgmUhO1fAGU+BFBZ0giUBAQEBAwEBAQ8LHTEDCwwEAgEIDQQBAwEBCxQJBycLFAMGCAIEAQ0FCBqHYwEMmnerOBMEjjMxBwaDHoEUBJ8kizeDLYIq X-IronPort-AV: E=Sophos;i="4.97,533,1389762000"; d="scan'208";a="44020008" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Feb 2014 04:02:58 -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; 24 Feb 2014 03:49:50 -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.0174.001; Mon, 24 Feb 2014 10:02:55 +0100 From: "Romascanu, Dan (Dan)" To: Melinda Shore , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP Thread-Index: AQHPMQgOMcucR8J9lU6LxtXzV9nEfZrD5BqAgAAAlICAADV80A== Date: Mon, 24 Feb 2014 09:02:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E4350C1@AZ-FFEXMB04.global.avaya.com> References: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> <53040210.4090709@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AE0AF70@nkgeml512-mbx.china.huawei.com> <530AEA1D.3000008@gmail.com> In-Reply-To: <530AEA1D.3000008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/coEYwCv2yzOhu6Ow9ZgS6asUAYg Cc: "mmanig@gmail.com" , Dorothy Stanley Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP 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, 24 Feb 2014 09:03:03 -0000 Hi, I understand the need and I support discussing this work in OPSAWG.=20 This being said - the change proposed by this document looks like a signifi= cant addition to the CAPWAP architecture. I personally need to do more read= ing to understand how it fits into the current architecture, how it impacts= existing WTPs and ARs, and whether there is a need for a migration or coex= istence plans in existing deployments of CAPWAP (if such deployments exist)= . Function of the responses this may or may not represent more the usual 'i= ncremental development' we do in OPSAWG. I would like to hear also the opin= ions of IEEE 802.11 experts and of folks who were involved in the original = CAPWAP work ( I copied Dorothy and Mani, there are more) Thanks and Regards, Dan > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Melinda > Shore > Sent: Monday, February 24, 2014 8:44 AM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames > in CAPWAP >=20 > We have not yet put out a call for adoption. At this point we're trying = to get a > handle on relevance and quality. To that end, discussion is very useful, > statements of support less so. >=20 > Melinda >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Feb 24 01:15: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 E324B1A083A for ; Mon, 24 Feb 2014 01:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, WEIRD_PORT=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 At7KLAus3V0H for ; Mon, 24 Feb 2014 01:15:43 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id DAFAB1A0404 for ; Mon, 24 Feb 2014 01:15:40 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 835A910589 for ; Mon, 24 Feb 2014 10:15:39 +0100 (CET) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 670CA10584 for ; Mon, 24 Feb 2014 10:15:39 +0100 (CET) Message-ID: <530B0D9C.4060706@restena.lu> Date: Mon, 24 Feb 2014 10:15:08 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <52F8CBB6.9000005@restena.lu> In-Reply-To: <52F8CBB6.9000005@restena.lu> X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nNMTwVbu8FSUiPQm0mwSvbBXRa9Rh4kUq" X-Virus-Scanned: ClamAV Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Qjoh8EBXNBPryLNGRfLFiQ92zIg Subject: Re: [OPSAWG] EAP configuration metadata draft 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, 24 Feb 2014 09:15:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nNMTwVbu8FSUiPQm0mwSvbBXRa9Rh4kUq Content-Type: multipart/mixed; boundary="------------040501080608050900050504" This is a multi-part message in MIME format. --------------040501080608050900050504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, my draft does not involve writable MIB modules, so it seems to be hard to get some attention. So, let me just add another data point to this, hoping I can stir up some responses: Firefox OS is showing interest in a) a standard way of configuring EAP; b) our spec in particular; so there is real-world demand out there. There's a (long) bug report on the whole topic of Enterprise-Wifi-or-not; and if yes, how to do it right. https://bugzilla.mozilla.org/show_bug.cgi?id=3D775499 Greetings, Stefan Winter On 10.02.2014 13:53, Stefan Winter wrote: > Hello, >=20 > I would like to draw your attention to my submission of > draft-winter-opsawg-eap-metadata-00 ( > http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ ). >=20 > I would like to ask the community how they feel about this work - is it= > needed, are we on the right track, etc. >=20 > As a teaser for why our group thinks this piece of work is important an= d > useful, please see the beginning of the Problem Statement section, > pasted here for your convenience: >=20 > "The IETF has produced the Extensible Authentication Protocol (EAP, > [RFC3748] and numerous EAP methods (for example EAP-TTLS [RFC5281], > EAP-TLS [RFC5216] and [RFC5931]); the methods have many properties > which need to be setup on the EAP server and matched as configuratio= n > items on the EAP peer for a secure EAP deployment. >=20 > Setting up these configuration items is comparatively easy if the > end-user devices which implement the EAP peer functionality are unde= r > central administrative control, e.g. in closed enterprise > environments. Group policies or device provisioning by the IT > department can push the settings to user devices. >=20 > In other environments, for example "BYOD" scenarios where users brin= g > their own devices which are not under enterprise control, or in EAP-= > based WISP environments (see e.g. [HS20] and > [I-D.wierenga-ietf-eduroam]) where it is not desired neither for the= > ISP nor for his user that the device control is in the ISPs hands, > configuration of EAP is significantly harder as it has to be done by= > potentially very non-technical end users." >=20 > There's plenty of proprietary approaches, they all vary in richness of > expressability, most don't have complete public schemas or are even in > binary with no explanations on how to construct them as an outsider. >=20 > We find the lack of a public specification disturbing. >=20 > It leads to duplication of efforts in numerous organisations, > incompatiblities between the produced formats, and sometimes simply > leads to bad quality specs. >=20 > BTW, I have teased the list earlier (see my posting on 18 Dec 2013), an= d > already got an on-list response (as well as offline). >=20 > I believe this warrants allocation of slot time in London, and I would > at this point ask the chairs if it's possible to get 5 mins (more if yo= u > have plenty :-) ) to discuss the problem itself and the solution we've > put together in this first draft. >=20 > Greetings, >=20 > Stefan Winter >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e 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 --------------040501080608050900050504 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------040501080608050900050504-- --nNMTwVbu8FSUiPQm0mwSvbBXRa9Rh4kUq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTCw2cAAoJEMDeajWKOdxmM0sQAKocGTlPQtvrjMJjRdgO0pFn rRhpO0PTv3Jc39FCF3i1gPEVGoakw97wERohOe1q4s4m/zyHP01DJmiojKMFK6ag KYBPluKcBk+eNo3Y6AVMGF2/kIlhnJRaS5GGwjYDLKmNscVlwIv+r0zFtMzE4r57 dRgudCNtwNiuOZbHjELTEh+iy/VKaJYWcRejtOmXQXEf39JbtsIu4U2zm6MiVGPQ +cIYid5nifxKwHHhE3v7GH9lmgfVJ1xgxZqr5jD9c84PvKQM9/Gdlq/Gfyh/Ib+D Lx7EwyhGhJ0e698C4jIyA0sqIjPSuGRiX1uGB/jzEqtFOo3W6UkWN2mWHZWEtVOL FmzV0eY1Y9BFXvw6Q27xtc3wlI7KOh/dzbTQ6AGbkK83FDKiydDR/zC2MnW0gIi6 ppXAMX9aqyydxHSIJguu0L2MpntGnhDAnLBEJtCZhgJwFfcubP6GmSHuz+b9ruwL 59SPlHcTySXJCTapRtr/0UClosuWOdvWiqcPtsQw9CUcbuKML7UCs5JnypqSPwsL NXnWyYyTXVdB8ppSs4RYFSb5cOrun1BHhqPAdYziXatW3aCy3FM83zus8W0/gDTw JY/GbK/1vNQiEwRjnFhbzXmC2XqyRXt2CBbtsBJ79RmE2kOAEe6xOe7KubdL4fd5 LmBubfGICSgpf9bUmcrz =Q3Qu -----END PGP SIGNATURE----- --nNMTwVbu8FSUiPQm0mwSvbBXRa9Rh4kUq-- From nobody Mon Feb 24 14:57: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 2F1401A0320 for ; Mon, 24 Feb 2014 14:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 hfkoa24uxKm9 for ; Mon, 24 Feb 2014 14:57:30 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64D401A0313 for ; Mon, 24 Feb 2014 14:57:30 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id m1so2028940oag.17 for ; Mon, 24 Feb 2014 14:57:29 -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:content-transfer-encoding; bh=0ddcq5A2+jJWqnaNSpo1Jez+01ZjZ/PVdy0P3/JOwGo=; b=VRln3RhckF+ldcPlFeSEjAwS6PdM7kxPfke8hodAya70/UFSrhA1EjTMEGuwaQJFRy awdq1OHsCt6TQLTnYSP4r925SbIulKEBRSxjqjhb4zs1dfNyRwEfe7vrPcp2Z+xcex+j O3SgRrT0JbeyQvdQHIBdvv4w2+juoKJ7SzkYxAA0LrhrquaKdxxcBwrUJT91gLynVnnr HX22h0GZbsGoE3rDmP+7ZfS7ddU/6mYFd8VA6g5im4KmmDbX4R1ykTgTMYzilmOSC1bF kMIeTDio9J+XvnCQndW3FctYagltpBlr8zEeBBCL4qlOtEhtIvblDF27ZL9cgJ6DnSbW T3ug== X-Gm-Message-State: ALoCoQnZnhicrA+CA1sibapwGsHiYF3NPERh4hTcKPw4PUnkl6feNy7eAAGcRS06IF/eqQUKvMUH MIME-Version: 1.0 X-Received: by 10.182.28.7 with SMTP id x7mr19831191obg.43.1393282649550; Mon, 24 Feb 2014 14:57:29 -0800 (PST) Received: by 10.182.191.9 with HTTP; Mon, 24 Feb 2014 14:57:29 -0800 (PST) X-Originating-IP: [82.99.7.230] Date: Mon, 24 Feb 2014 23:57:29 +0100 Message-ID: From: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= To: opsawg@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/h84_wkfBluC719zf_vyrP3sq2-w Subject: [OPSAWG] Simplified Alternative to CAPWAP 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, 24 Feb 2014 22:57:32 -0000 Dear all, I've been following the recent CAPWAP activity on this list and thought I should share some general thoughts on the protocol, and see if there's interest in a broader approach. The CAPWAP shortcomings discussed are similar to the problems preventing us [1] from using it in our Software-Defined Networking (SDN) architecture for IEEE 802.11 [2]: 1. CAPWAP was specified before separation of data, control and management planes became the norm in networking architecture. Unsurprisingly it provides very little separation of concern, conflating everything from firmware updates to configuration of an extra SSID. 2. CAPWAP attempts to provide provisioning/management functionality that overlaps with other IETF standards track protocols, e.g. SNMP and NETCONF/YANG, as well as other established management protocols such as TR-069. 3. The separation of data and control planes that CAPWAP does provide is IMHO incorrect: 802.1X key exchange is considered part of the control plane but the derived encryption keys protect the data plane. This doesn't matter when both control and data plane terminate in the same location (the AC), but becomes a problem when they are separated (encryption keys end up in a different place than the encrypted data!). 4. CAPWAP leaves many options open to the implementer and is therefore less interoperable than desired. To some extent this can be solved with run-time negotiation, but such negotiation of security critical aspects (such as where encryption keys are derived and kept) makes it impossible to reason about the security of the system. This is less than ideal IMHO. 5. CAPWAP (partly due to 1 and 2 above) depends excessively on details in the IEEE 802.11 standard, with each amendment threatening to impact the protocol. We would be interested in specifying a simplified tunneling protocol for IEEE 802.11 similar to Geneve [3], avoiding the above problems: A. The protocol should mandate a single well-defined partitioning of the IEEE 802.11 stack, with 802.1X authentication, key management and encryption all implemented at the tunnel termination point for security reasons. B. The protocol should mandate a single well-defined frame format relying only on a PHY-independent stable subset of IEEE 802.11, ensuring compatibility with 11n/ac and (most likely) beyond. C. Like Geneve the protocol should not provide any provisioning/management functionality, instead relying on SNMP, NETCONF/YANG, TR-069 and similar. D. Like Geneve the protocol should not provide any control plane functionality, instead remaining compatible with several Software-Defined Networking (SDN) protocols for IEEE 802.11. E. Each virtual access point in a multi-BSSID (and/or multi-radio) access point should be treated as a separate entity associated with a separate tunnel. We see strong benefits to such a protocol from an extensibility [4], flexibility [5] and security [6] perspective. If there is interest in exploring this further please let me know. Best regards, Bj=C3=B6rn Smedman 1. http://www.anyfinetworks.com 2. http://anyfi.net and http://www.anyfinetworks.com/products 3. http://tools.ietf.org/html/draft-gross-geneve-00 4. http://anyfi.net/documentation#architecture 5. http://anyfi.net/documentation#a_how_it_all_fits_together 6. http://anyfi.net/documentation#i_security_model From nobody Mon Feb 24 16:13:32 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 2E4171A034F for ; Mon, 24 Feb 2014 16:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 vaQVKE7wnv-U for ; Mon, 24 Feb 2014 16:13:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC3771A0234 for ; Mon, 24 Feb 2014 16:13:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDX91614; Tue, 25 Feb 2014 00:13:27 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 00:13:19 +0000 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 00:13:24 +0000 Received: from DFWEML703-CHM.china.huawei.com ([169.254.5.106]) by dfweml704-chm.china.huawei.com ([169.254.6.2]) with mapi id 14.03.0158.001; Mon, 24 Feb 2014 16:13:18 -0800 From: John Kaippallimalil To: Melinda Shore , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP Thread-Index: AQHPLQ31ubFI9PwG20+wNxD4YKErPJrDcyOg Date: Tue, 25 Feb 2014 00:13:17 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171D9BD827@dfweml703-chm.china.huawei.com> References: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com> <53040210.4090709@gmail.com> In-Reply-To: <53040210.4090709@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.65] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Pi31Sk3EAEA4wr4I0UUdJqIOZXM Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP 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, 25 Feb 2014 00:13:31 -0000 Hi, The problem this draft solves is described clearly, and I think that it fil= ls a gap in the existing stds. My questions on the previous version of the draft wrt tunnel failure, acces= s router address, etc are all clarified here.=20 I like the approach in 2.2 and 2.3 with respect to specifying the tunnel ty= pe/specification since it is simple enough and while providing sufficient f= lexibility. Section 2.1 - the figure and text help, but it would be good as the draft p= rogresses to have a bit more of detail/clarity in the description.=20 Best Regards, John=20 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Melinda > Shore > Sent: Tuesday, February 18, 2014 7:00 PM > To: opsawg@ietf.org > Subject: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames > in CAPWAP >=20 > Please note that Rajesh is planning to ask for working group adoption > of this document. Please give it a read and provide feedback on this > mailing list. Particularly interested in the question of how well it > meshes with CAPWAP documents we've already adopted. >=20 > Melinda >=20 >=20 >=20 > -------- Original Message -------- > Subject: [OPSAWG] Alternate Tunnel Encapsulation for Data Frames in > CAPWAP > Date: Tue, 18 Feb 2014 22:10:10 +0000 > From: Rajesh Pazhyannur (rpazhyan) > To: opsawg@ietf.org >=20 >=20 >=20 > Hello >=20 > We have a submitted a new version of Alternate Tunnel Encapsulation for > Data Frames in CAPWAP,_http://datatracker.ietf.org/doc/draft-zhang- > opsawg-capwap-cds/_. >=20 > Abstract >=20 > In centralized IEEE 802.11 Wireless Local Area Network (WLAN) > architecture, the Access Controller (AC) isn't intelligent enough > actually to aggregate all the wireless frames, even the bandwidth > requirement in the access point is increasing. Thus it is a general > case in the existing operator's network that WTPs forward the > wireless frames directly to Access Router (AR) to avoid overload on > the AC. In this scenario, CAPWAP Control Channel and CAPWAP Data > Channel are separated from each other. This document extends CAPWAP > for applicability of CAPWAP Control and Data Channel separation. >=20 >=20 > We received some questions and suggestions from Dan Romascanu and John > Kaippallimalil on the mailing list on the previous draft. We have > attempted to address them in this draft. Specifically, >=20 > 1. How does this draft address signaling, discovery mechanisms related > to setting up alternate tunnel. (ans. Tunneling protocols like > L2TPv3, IP/GRE (PMIPv6) already have a signaling mechanism. This > draft focuses on specifying the tunnel type and provides a > container > to hold message elements) > 2. Need for alternate tunnel encapsulation (given the existence of > defined mode with local bridging) >=20 >=20 > We would like to get it adopted as a working group item and would like > feedback on whether we are on track. >=20 >=20 > thanks >=20 > Regards >=20 > Rajesh >=20 >=20 From nobody Mon Feb 24 16:29:15 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 B8D1D1A0313 for ; Mon, 24 Feb 2014 16:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.047 X-Spam-Level: X-Spam-Status: No, score=-12.047 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 Y7oATqmdYBGp for ; Mon, 24 Feb 2014 16:29:07 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9EE1A0200 for ; Mon, 24 Feb 2014 16:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22262; q=dns/txt; s=iport; t=1393288147; x=1394497747; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=iqSvHqPZEseuWHfeHHINMiX2w75mBsswaae/8VNfPOo=; b=K2Z2Nvjd6Ciam61yP6CGxlKSAGkIydjW+caOpBNcsEUj84RuoGZFU+Uz 4UcO+roXNVFkEuTRX2bK+uGks+u2CiCQBNltY227ApgXd+9SWFdvpZ0Ij jIhYGv1vzmD/7ksPe5Rzvh0KW8zOJsa1NOraTWZmwfIARb1aaMmsPx3o0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUFABHjC1OtJV2d/2dsb2JhbABZgkJEO1eDA7VXhGmDIE8YgQIWdIIlAQEBAwEBAQEgCigZEAcEAgEIEQEDAQELHQMCAgIlCxQDBggCBAESCId1CA2lWaBJF44CEQEfLQsGgmk1gRQEmWaLMIVFgy2BcTk X-IronPort-AV: E=Sophos;i="4.97,537,1389744000"; d="scan'208,217";a="306315242" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 25 Feb 2014 00:29:05 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1P0T5gN021351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 00:29:05 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.22]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 18:29:05 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: =?utf-8?B?QmrDtnJuIFNtZWRtYW4=?= , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Simplified Alternative to CAPWAP Thread-Index: AQHPMbPgQtd3dWdjMUewmYg0xTSiXZrFGNzw Date: Tue, 25 Feb 2014 00:29:04 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F5D75F@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.68.69] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F5D75Fxmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/wYvp1Sit9Atlc5FOTTDfDYbPyPw Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP 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, 25 Feb 2014 00:29:14 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F5D75Fxmbalnx09ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQmpvcm4NCg0KV2Ugc2VlIHN0cm9uZyBiZW5lZml0cyB0byBzdWNoIGEgcHJvdG9jb2wg ZnJvbSBhbiBleHRlbnNpYmlsaXR5IFs0XSwgZmxleGliaWxpdHkgWzVdIGFuZCBzZWN1cml0eSBb Nl0gcGVyc3BlY3RpdmUuIElmIHRoZXJlIGlzIGludGVyZXN0IGluIGV4cGxvcmluZyB0aGlzIGZ1 cnRoZXIgcGxlYXNlIGxldCBtZSBrbm93DQoNClRoYW5rcyBmb3IgdGhlIHdlbGwgY2FwdHVyZWQg ZW1haWwuICBXb3VsZCBsaWtlIHRvIGV4cGxvcmUgbW9yZSBhYm91dCB3aGF0IHlvdSBhcmUgc3Vn Z2VzdGluZy4NCkkgaGF2ZSBub3QgcmVhZCB0aGUgZGV0YWlscyBwcm92aWRlZCBpbiB5b3VyIGxp bmsuDQoNCkluIHRoZSBtZWFud2hpbGUsDQoNCjMuIFRoZSBzZXBhcmF0aW9uIG9mIGRhdGEgYW5k IGNvbnRyb2wgcGxhbmVzIHRoYXQgQ0FQV0FQIGRvZXMgcHJvdmlkZSBpcyBJTUhPIGluY29ycmVj dDogODAyLjFYIGtleSBleGNoYW5nZSBpcyBjb25zaWRlcmVkIHBhcnQgb2YgdGhlIGNvbnRyb2wg cGxhbmUgYnV0IHRoZSBkZXJpdmVkIGVuY3J5cHRpb24ga2V5cyBwcm90ZWN0IHRoZSBkYXRhIHBs YW5lLg0KVGhpcyBkb2Vzbid0IG1hdHRlciB3aGVuIGJvdGggY29udHJvbCBhbmQgZGF0YSBwbGFu ZSB0ZXJtaW5hdGUgaW4gdGhlIHNhbWUgbG9jYXRpb24gKHRoZSBBQyksIGJ1dCBiZWNvbWVzIGEg cHJvYmxlbSB3aGVuIHRoZXkgYXJlIHNlcGFyYXRlZCAoZW5jcnlwdGlvbiBrZXlzIGVuZCB1cCBp biBhIGRpZmZlcmVudCBwbGFjZSB0aGFuIHRoZSBlbmNyeXB0ZWQgZGF0YSEpLg0KDQo+ICAgICAg ICBUZWNobmljYWxseSBzcGVha2luZywgODAyLjFYIHByb3RlY3RzIHRoZSA4MDIuMTEgZnJhbWVz IGFuZCBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIHRvIGRvIENBUFdBUCBEYXRhIGNoYW5uZWwuIFRo ZSBEYXRhIGNoYW5uZWwgaXMgcHJvdGVjdGVkIHVzaW5nIERUTFMuIEl0IGlzIGNvbmNlaXZhYmxl IHRoYXQgMSkgdGhlIHR1bm5lbCBtb2RlIGlzIGVuY2Fwc3VsYXRpbmcgODAyLjExIGZyYW1lcyAo aW5zdGVhZCBvZiA4MDIuMyBmcmFtZXMpIGFuZCAyKSBDQVBXQVAtRGF0YSBpcyBub3QgZW5jcnlw dGVkIGFuZCAzKSA4MDIuMTEgZW5jcnlwdGlvbiBpcyBoYXBwZW5pbmcgYXQgdGhlIEFDIGluc3Rl YWQgb2YgQVAuIFdoZW4gYWxsIHRocmVlIGNvbmRpdGlvbnMgaG9sZCwgIHdoYXQgeW91IGFyZSBz YXlpbmcgaXMgdHJ1ZTogODAyLjFYIGlzIGluZGVlZCBwcm90ZWN0aW5nIHRoZSBkYXRhIHBsYW5l Lg0KDQo1LiBDQVBXQVAgKHBhcnRseSBkdWUgdG8gMSBhbmQgMiBhYm92ZSkgZGVwZW5kcyBleGNl c3NpdmVseSBvbiBkZXRhaWxzIGluIHRoZSBJRUVFIDgwMi4xMSBzdGFuZGFyZCwgd2l0aCBlYWNo IGFtZW5kbWVudCB0aHJlYXRlbmluZyB0byBpbXBhY3QgdGhlIHByb3RvY29sLg0KDQo+ICBZZXMs IGl0IGlzIHRydWUsIHRoYXQgd2lyZWxlc3MgYmluZGluZyAoUkZDIDU0MTYpIG9mIENBUFdBUCBh cmUgZGVwZW5kZW50IG9uIDgwMi4xMSBhbmQgbmVlZHMgdXBkYXRlcyB3aXRoIDExbiwgMTFhYyBh bmQgc28gb24uIEJ1dCBpbiBzb21lIHNlbnNlIGl0IGFwcGVhcnMgdGhhdCB0aGUgcHJvYmxlbSBk b2VzIG5vdCBnbyBhd2F5LiBZb3UgYXJlIHNpbXBseSBwdXNoaW5nIHRoZSBwcm9ibGVtIHRvIFNO TVAgb3IgVFItNjkgb3Igc29tZXRoaW5nIGxpa2UgdGhhdC4gIFdlIGNhbiBkZWJhdGUgd2hldGhl ciB0aG9zZSBhcmUgYmV0dGVyIHRoYW4gQ0FQV0FQIGluIGNvbmZpZ3VyaW5nIGEgV0ktRkkgQVAu DQoNCkEuIFRoZSBwcm90b2NvbCBzaG91bGQgbWFuZGF0ZSBhIHNpbmdsZSB3ZWxsLWRlZmluZWQg cGFydGl0aW9uaW5nIG9mIHRoZSBJRUVFIDgwMi4xMSBzdGFjaywgd2l0aCA4MDIuMVggYXV0aGVu dGljYXRpb24sIGtleSBtYW5hZ2VtZW50IGFuZCBlbmNyeXB0aW9uIGFsbCBpbXBsZW1lbnRlZCBh dCB0aGUgdHVubmVsIHRlcm1pbmF0aW9uIHBvaW50IGZvciBzZWN1cml0eSByZWFzb25zLg0KDQo+ ICAgICAgIEJ5IHRoaXMgSSBhbSBhc3N1bWluZyB0aGF0IHlvdSB3YW50IGVuY3J5cHRpb24gYXQg dGhlIFR1bm5lbCB0ZXJtaW5hdGlvbiBwb2ludCByYXRoZXIgdGhhbiB0aGUgQVAuICBXaGF0IGlz IG1vdGl2YXRpbmcgdGhpcywgZ2l2ZW4gdGhhdCBhbGwgQVBzICh0aGF0IEkga25vdyBvZikgaW1w bGVtZW50IDgwMi4xMSBlbmNyeXB0aW9uIGFuZCBpZiBzZWN1cml0eSBpcyBuZWVkZWQgYmV0d2Vl biBBUCBhbmQgVHVubmVsIHRlcm1pbmF0aW9uIHBvaW50IHRoZW4gb25lIGNvdWxkIHVzZSBJUFNF QyBvciBEVExTLg0KDQpSZWdhcmRzDQoNClJhamVzaA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogT1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBCasO2cm4gU21lZG1hbg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCAy OjU3IFBNDQpUbzogb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBbT1BTQVdHXSBTaW1wbGlmaWVk IEFsdGVybmF0aXZlIHRvIENBUFdBUA0KDQpEZWFyIGFsbCwNCg0KSSd2ZSBiZWVuIGZvbGxvd2lu ZyB0aGUgcmVjZW50IENBUFdBUCBhY3Rpdml0eSBvbiB0aGlzIGxpc3QgYW5kIHRob3VnaHQgSSBz aG91bGQgc2hhcmUgc29tZSBnZW5lcmFsIHRob3VnaHRzIG9uIHRoZSBwcm90b2NvbCwgYW5kIHNl ZSBpZiB0aGVyZSdzIGludGVyZXN0IGluIGEgYnJvYWRlciBhcHByb2FjaC4NCg0KVGhlIENBUFdB UCBzaG9ydGNvbWluZ3MgZGlzY3Vzc2VkIGFyZSBzaW1pbGFyIHRvIHRoZSBwcm9ibGVtcyBwcmV2 ZW50aW5nIHVzIFsxXSBmcm9tIHVzaW5nIGl0IGluIG91ciBTb2Z0d2FyZS1EZWZpbmVkIE5ldHdv cmtpbmcNCihTRE4pIGFyY2hpdGVjdHVyZSBmb3IgSUVFRSA4MDIuMTEgWzJdOg0KDQoxLiBDQVBX QVAgd2FzIHNwZWNpZmllZCBiZWZvcmUgc2VwYXJhdGlvbiBvZiBkYXRhLCBjb250cm9sIGFuZCBt YW5hZ2VtZW50IHBsYW5lcyBiZWNhbWUgdGhlIG5vcm0gaW4gbmV0d29ya2luZyBhcmNoaXRlY3R1 cmUuDQpVbnN1cnByaXNpbmdseSBpdCBwcm92aWRlcyB2ZXJ5IGxpdHRsZSBzZXBhcmF0aW9uIG9m IGNvbmNlcm4sIGNvbmZsYXRpbmcgZXZlcnl0aGluZyBmcm9tIGZpcm13YXJlIHVwZGF0ZXMgdG8g Y29uZmlndXJhdGlvbiBvZiBhbiBleHRyYSBTU0lELg0KDQoyLiBDQVBXQVAgYXR0ZW1wdHMgdG8g cHJvdmlkZSBwcm92aXNpb25pbmcvbWFuYWdlbWVudCBmdW5jdGlvbmFsaXR5IHRoYXQgb3Zlcmxh cHMgd2l0aCBvdGhlciBJRVRGIHN0YW5kYXJkcyB0cmFjayBwcm90b2NvbHMsIGUuZy4gU05NUCBh bmQgTkVUQ09ORi9ZQU5HLCBhcyB3ZWxsIGFzIG90aGVyIGVzdGFibGlzaGVkIG1hbmFnZW1lbnQg cHJvdG9jb2xzIHN1Y2ggYXMgVFItMDY5Lg0KDQozLiBUaGUgc2VwYXJhdGlvbiBvZiBkYXRhIGFu ZCBjb250cm9sIHBsYW5lcyB0aGF0IENBUFdBUCBkb2VzIHByb3ZpZGUgaXMgSU1ITyBpbmNvcnJl Y3Q6IDgwMi4xWCBrZXkgZXhjaGFuZ2UgaXMgY29uc2lkZXJlZCBwYXJ0IG9mIHRoZSBjb250cm9s IHBsYW5lIGJ1dCB0aGUgZGVyaXZlZCBlbmNyeXB0aW9uIGtleXMgcHJvdGVjdCB0aGUgZGF0YSBw bGFuZS4NClRoaXMgZG9lc24ndCBtYXR0ZXIgd2hlbiBib3RoIGNvbnRyb2wgYW5kIGRhdGEgcGxh bmUgdGVybWluYXRlIGluIHRoZSBzYW1lIGxvY2F0aW9uICh0aGUgQUMpLCBidXQgYmVjb21lcyBh IHByb2JsZW0gd2hlbiB0aGV5IGFyZSBzZXBhcmF0ZWQgKGVuY3J5cHRpb24ga2V5cyBlbmQgdXAg aW4gYSBkaWZmZXJlbnQgcGxhY2UgdGhhbiB0aGUgZW5jcnlwdGVkIGRhdGEhKS4NCg0KNC4gQ0FQ V0FQIGxlYXZlcyBtYW55IG9wdGlvbnMgb3BlbiB0byB0aGUgaW1wbGVtZW50ZXIgYW5kIGlzIHRo ZXJlZm9yZSBsZXNzIGludGVyb3BlcmFibGUgdGhhbiBkZXNpcmVkLiBUbyBzb21lIGV4dGVudCB0 aGlzIGNhbiBiZSBzb2x2ZWQgd2l0aCBydW4tdGltZSBuZWdvdGlhdGlvbiwgYnV0IHN1Y2ggbmVn b3RpYXRpb24gb2Ygc2VjdXJpdHkgY3JpdGljYWwgYXNwZWN0cyAoc3VjaCBhcyB3aGVyZSBlbmNy eXB0aW9uIGtleXMgYXJlIGRlcml2ZWQgYW5kIGtlcHQpIG1ha2VzIGl0IGltcG9zc2libGUgdG8g cmVhc29uIGFib3V0IHRoZSBzZWN1cml0eSBvZiB0aGUgc3lzdGVtLiBUaGlzIGlzIGxlc3MgdGhh biBpZGVhbCBJTUhPLg0KDQo1LiBDQVBXQVAgKHBhcnRseSBkdWUgdG8gMSBhbmQgMiBhYm92ZSkg ZGVwZW5kcyBleGNlc3NpdmVseSBvbiBkZXRhaWxzIGluIHRoZSBJRUVFIDgwMi4xMSBzdGFuZGFy ZCwgd2l0aCBlYWNoIGFtZW5kbWVudCB0aHJlYXRlbmluZyB0byBpbXBhY3QgdGhlIHByb3RvY29s Lg0KDQoNCldlIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gc3BlY2lmeWluZyBhIHNpbXBsaWZpZWQg dHVubmVsaW5nIHByb3RvY29sIGZvciBJRUVFIDgwMi4xMSBzaW1pbGFyIHRvIEdlbmV2ZSBbM10s IGF2b2lkaW5nIHRoZSBhYm92ZSBwcm9ibGVtczoNCg0KQS4gVGhlIHByb3RvY29sIHNob3VsZCBt YW5kYXRlIGEgc2luZ2xlIHdlbGwtZGVmaW5lZCBwYXJ0aXRpb25pbmcgb2YgdGhlIElFRUUgODAy LjExIHN0YWNrLCB3aXRoIDgwMi4xWCBhdXRoZW50aWNhdGlvbiwga2V5IG1hbmFnZW1lbnQgYW5k IGVuY3J5cHRpb24gYWxsIGltcGxlbWVudGVkIGF0IHRoZSB0dW5uZWwgdGVybWluYXRpb24gcG9p bnQgZm9yIHNlY3VyaXR5IHJlYXNvbnMuDQoNCkIuIFRoZSBwcm90b2NvbCBzaG91bGQgbWFuZGF0 ZSBhIHNpbmdsZSB3ZWxsLWRlZmluZWQgZnJhbWUgZm9ybWF0IHJlbHlpbmcgb25seSBvbiBhIFBI WS1pbmRlcGVuZGVudCBzdGFibGUgc3Vic2V0IG9mIElFRUUgODAyLjExLCBlbnN1cmluZyBjb21w YXRpYmlsaXR5IHdpdGggMTFuL2FjIGFuZCAobW9zdCBsaWtlbHkpIGJleW9uZC4NCg0KQy4gTGlr ZSBHZW5ldmUgdGhlIHByb3RvY29sIHNob3VsZCBub3QgcHJvdmlkZSBhbnkgcHJvdmlzaW9uaW5n L21hbmFnZW1lbnQgZnVuY3Rpb25hbGl0eSwgaW5zdGVhZCByZWx5aW5nIG9uIFNOTVAsIE5FVENP TkYvWUFORywgVFItMDY5IGFuZCBzaW1pbGFyLg0KDQpELiBMaWtlIEdlbmV2ZSB0aGUgcHJvdG9j b2wgc2hvdWxkIG5vdCBwcm92aWRlIGFueSBjb250cm9sIHBsYW5lIGZ1bmN0aW9uYWxpdHksIGlu c3RlYWQgcmVtYWluaW5nIGNvbXBhdGlibGUgd2l0aCBzZXZlcmFsIFNvZnR3YXJlLURlZmluZWQg TmV0d29ya2luZyAoU0ROKSBwcm90b2NvbHMgZm9yIElFRUUgODAyLjExLg0KDQpFLiBFYWNoIHZp cnR1YWwgYWNjZXNzIHBvaW50IGluIGEgbXVsdGktQlNTSUQgKGFuZC9vciBtdWx0aS1yYWRpbykg YWNjZXNzIHBvaW50IHNob3VsZCBiZSB0cmVhdGVkIGFzIGEgc2VwYXJhdGUgZW50aXR5IGFzc29j aWF0ZWQgd2l0aCBhIHNlcGFyYXRlIHR1bm5lbC4NCg0KDQpXZSBzZWUgc3Ryb25nIGJlbmVmaXRz IHRvIHN1Y2ggYSBwcm90b2NvbCBmcm9tIGFuIGV4dGVuc2liaWxpdHkgWzRdLCBmbGV4aWJpbGl0 eSBbNV0gYW5kIHNlY3VyaXR5IFs2XSBwZXJzcGVjdGl2ZS4gSWYgdGhlcmUgaXMgaW50ZXJlc3Qg aW4gZXhwbG9yaW5nIHRoaXMgZnVydGhlciBwbGVhc2UgbGV0IG1lIGtub3cuDQoNCkJlc3QgcmVn YXJkcywNCg0KQmrDtnJuIFNtZWRtYW4NCg0KMS4gaHR0cDovL3d3dy5hbnlmaW5ldHdvcmtzLmNv bQ0KDQoyLiBodHRwOi8vYW55ZmkubmV0IGFuZCBodHRwOi8vd3d3LmFueWZpbmV0d29ya3MuY29t L3Byb2R1Y3RzDQoNCjMuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdyb3NzLWdl bmV2ZS0wMA0KDQo0LiBodHRwOi8vYW55ZmkubmV0L2RvY3VtZW50YXRpb24jYXJjaGl0ZWN0dXJl DQoNCjUuIGh0dHA6Ly9hbnlmaS5uZXQvZG9jdW1lbnRhdGlvbiNhX2hvd19pdF9hbGxfZml0c190 b2dldGhlcg0KDQo2LiBodHRwOi8vYW55ZmkubmV0L2RvY3VtZW50YXRpb24jaV9zZWN1cml0eV9t b2RlbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T1BTQVdHIG1haWxpbmcgbGlzdA0KT1BTQVdHQGlldGYub3JnPG1haWx0bzpPUFNBV0dAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0KDQo= --_000_4ED2E36A22261145861BAB2C24088B4320F5D75Fxmbalnx09ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSI0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE2cHQ7Ij4NCjxkaXY+SGVsbG8gQmpvcm48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PldlIHNlZSBz dHJvbmcgYmVuZWZpdHMgdG8gc3VjaCBhIHByb3RvY29sIGZyb20gYW4gZXh0ZW5zaWJpbGl0eSBb NF0sIGZsZXhpYmlsaXR5IFs1XSBhbmQgc2VjdXJpdHkgWzZdIHBlcnNwZWN0aXZlLiBJZiB0aGVy ZSBpcyBpbnRlcmVzdCBpbiBleHBsb3JpbmcgdGhpcyBmdXJ0aGVyIHBsZWFzZSBsZXQgbWUga25v dzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiM3MDMwQTAiPlRoYW5rcyBmb3IgdGhlIHdlbGwgY2Fw dHVyZWQgZW1haWwuJm5ic3A7IFdvdWxkIGxpa2UgdG8gZXhwbG9yZSBtb3JlIGFib3V0IHdoYXQg eW91IGFyZSBzdWdnZXN0aW5nLiA8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjNzAz MEEwIj5JIGhhdmUgbm90IHJlYWQgdGhlIGRldGFpbHMgcHJvdmlkZWQgaW4geW91ciBsaW5rLiA8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9IiM3 MDMwQTAiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiM3MDMwQTAiPklu IHRoZSBtZWFud2hpbGUsIDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PjMuIFRoZSBzZXBhcmF0aW9uIG9mIGRh dGEgYW5kIGNvbnRyb2wgcGxhbmVzIHRoYXQgQ0FQV0FQIGRvZXMgcHJvdmlkZSBpcyBJTUhPIGlu Y29ycmVjdDogODAyLjFYIGtleSBleGNoYW5nZSBpcyBjb25zaWRlcmVkIHBhcnQgb2YgdGhlIGNv bnRyb2wgcGxhbmUgYnV0IHRoZSBkZXJpdmVkIGVuY3J5cHRpb24ga2V5cyBwcm90ZWN0IHRoZSBk YXRhIHBsYW5lLjwvZGl2Pg0KPGRpdj5UaGlzIGRvZXNuJ3QgbWF0dGVyIHdoZW4gYm90aCBjb250 cm9sIGFuZCBkYXRhIHBsYW5lIHRlcm1pbmF0ZSBpbiB0aGUgc2FtZSBsb2NhdGlvbiAodGhlIEFD KSwgYnV0IGJlY29tZXMgYSBwcm9ibGVtIHdoZW4gdGhleSBhcmUgc2VwYXJhdGVkIChlbmNyeXB0 aW9uIGtleXMgZW5kIHVwIGluIGEgZGlmZmVyZW50IHBsYWNlIHRoYW4gdGhlIGVuY3J5cHRlZCBk YXRhISkuPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m b250PjwvZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW46MDtwYWRkaW5nLWxlZnQ6MzZwdDsiPg0KPGxp PiA8Zm9udCBjb2xvcj0iIzcwMzBBMCI+VGVjaG5pY2FsbHkgc3BlYWtpbmcsIDgwMi4xWCBwcm90 ZWN0cyA8L2ZvbnQ+PGZvbnQgY29sb3I9IiM3MDMwQTAiPnRoZTwvZm9udD48Zm9udCBjb2xvcj0i IzcwMzBBMCI+IDwvZm9udD48Zm9udCBjb2xvcj0iIzcwMzBBMCI+ODAyLjExIGZyYW1lcyBhbmQg ZG9lcyBub3QgaGF2ZSBhbnl0aGluZyB0byBkbyBDQVBXQVAgRGF0YSBjaGFubmVsLiBUaGUgRGF0 YSBjaGFubmVsIGlzIHByb3RlY3RlZCB1c2luZw0KRFRMUy48L2ZvbnQ+PGZvbnQgY29sb3I9IiM3 MDMwQTAiPiBJdCBpcyBjb25jZWl2YWJsZSB0aGF0IDwvZm9udD48Zm9udCBjb2xvcj0iIzcwMzBB MCI+MSkgPC9mb250Pjxmb250IGNvbG9yPSIjNzAzMEEwIj50aGUgdHVubmVsIG1vZGUgaXMgZW5j YXBzdWxhdGluZyA4MDIuMTEgZnJhbWVzIChpbnN0ZWFkIG9mIDgwMi4zIGZyYW1lcykgYW5kIDwv Zm9udD48Zm9udCBjb2xvcj0iIzcwMzBBMCI+Mik8L2ZvbnQ+PGZvbnQgY29sb3I9IiM3MDMwQTAi Pg0KQ0FQV0FQLURhdGEgaXMgbm90IGVuY3J5cHRlZDwvZm9udD48Zm9udCBjb2xvcj0iIzcwMzBB MCI+IGFuZCA8L2ZvbnQ+PGZvbnQgY29sb3I9IiM3MDMwQTAiPjMpIDwvZm9udD48Zm9udCBjb2xv cj0iIzcwMzBBMCI+ODAyLjExIGVuY3J5cHRpb24gaXMgaGFwcGVuaW5nIGF0IHRoZSBBQyBpbnN0 ZWFkIG9mIEFQLiBXaGVuIGFsbCB0aHJlZSBjb25kaXRpb25zIGhvbGQsIDwvZm9udD48Zm9udCBj b2xvcj0iIzcwMzBBMCI+IHdoYXQgeW91IGFyZSBzYXlpbmcNCjwvZm9udD48Zm9udCBjb2xvcj0i IzcwMzBBMCI+aXMgdHJ1ZTwvZm9udD48Zm9udCBjb2xvcj0iIzcwMzBBMCI+OiA4MDIuMVggaXMg aW5kZWVkIDwvZm9udD48Zm9udCBjb2xvcj0iIzcwMzBBMCI+cHJvdGVjdGluZzwvZm9udD48Zm9u dCBjb2xvcj0iIzcwMzBBMCI+IDwvZm9udD48Zm9udCBjb2xvcj0iIzcwMzBBMCI+dGhlIGRhdGEg cGxhbmUuIDwvZm9udD48Zm9udCBjb2xvcj0iIzcwMzBBMCI+IDwvZm9udD48L2xpPjwvdWw+DQo8 ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRp dj41LiBDQVBXQVAgKHBhcnRseSBkdWUgdG8gMSBhbmQgMiBhYm92ZSkgZGVwZW5kcyBleGNlc3Np dmVseSBvbiBkZXRhaWxzIGluIHRoZSBJRUVFIDgwMi4xMSBzdGFuZGFyZCwgd2l0aCBlYWNoIGFt ZW5kbWVudCB0aHJlYXRlbmluZyB0byBpbXBhY3QgdGhlIHByb3RvY29sLjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+Jmd0 OyAgPGZvbnQgY29sb3I9IiM3MDMwQTAiPlllcywgaXQgaXMgdHJ1ZSwgdGhhdCB3aXJlbGVzcyBi aW5kaW5nIChSRkMgNTQxNikgb2YgQ0FQV0FQIGFyZSBkZXBlbmRlbnQgb24gODAyLjExIGFuZCBu ZWVkcyB1cGRhdGVzIHdpdGggMTFuLCAxMWFjIGFuZCBzbyBvbi4gQnV0IGluIHNvbWUgc2Vuc2Ug aXQgYXBwZWFycyB0aGF0IHRoZSBwcm9ibGVtIGRvZXMgbm90IGdvIGF3YXkuIFlvdSBhcmUgc2lt cGx5IHB1c2hpbmcgdGhlIHByb2JsZW0NCnRvIFNOTVAgb3IgVFItNjkgb3Igc29tZXRoaW5nIGxp a2UgdGhhdC4gPC9mb250Pjxmb250IGNvbG9yPSIjNzAzMEEwIj4gV2UgY2FuIGRlYmF0ZSB3aGV0 aGVyIHRob3NlIGFyZSBiZXR0ZXIgdGhhbiBDQVBXQVAgaW4gY29uZmlndXJpbmcgYSBXSS1GSSBB UC48L2ZvbnQ+IDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QS4gVGhlIHByb3RvY29s IHNob3VsZCBtYW5kYXRlIGEgc2luZ2xlIHdlbGwtZGVmaW5lZCBwYXJ0aXRpb25pbmcgb2YgdGhl IElFRUUgODAyLjExIHN0YWNrLCB3aXRoIDgwMi4xWCBhdXRoZW50aWNhdGlvbiwga2V5IG1hbmFn ZW1lbnQgYW5kIGVuY3J5cHRpb24gYWxsIGltcGxlbWVudGVkIGF0IHRoZSB0dW5uZWwgdGVybWlu YXRpb24gcG9pbnQgZm9yIHNlY3VyaXR5IHJlYXNvbnMuPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW46 MDtwYWRkaW5nLWxlZnQ6MzZwdDsiPg0KPGZvbnQgY29sb3I9IiM3MDMwQTAiPg0KPGxpPkJ5IHRo aXMgSSBhbSBhc3N1bWluZyB0aGF0IHlvdSB3YW50IGVuY3J5cHRpb24gYXQgdGhlIFR1bm5lbCB0 ZXJtaW5hdGlvbiBwb2ludCByYXRoZXIgdGhhbiB0aGUgQVAuICBXaGF0IGlzIG1vdGl2YXRpbmcg dGhpcywgZ2l2ZW4gdGhhdCBhbGwgQVBzICh0aGF0IEkga25vdyBvZikgaW1wbGVtZW50IDgwMi4x MSBlbmNyeXB0aW9uIGFuZCBpZiBzZWN1cml0eSBpcyBuZWVkZWQgYmV0d2VlbiBBUCBhbmQgVHVu bmVsIHRlcm1pbmF0aW9uIHBvaW50DQp0aGVuIG9uZSBjb3VsZCB1c2UgSVBTRUMgb3IgRFRMUy48 L2xpPjwvZm9udD4NCjwvdWw+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29s b3I9IiM3MDMwQTAiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiM3MDMw QTAiPlJlZ2FyZHM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjNzAzMEEwIj4mbmJz cDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjNzAzMEEwIj5SYWplc2g8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9IiM3MDMwQTAi PiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQoNCkZyb206IE9QU0FXRyBbPGEgaHJlZj0ibWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3Jn Ij5tYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQmrDtnJu IFNtZWRtYW48YnI+DQoNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgMjo1NyBQTTxi cj4NCg0KVG86IG9wc2F3Z0BpZXRmLm9yZzxicj4NCg0KU3ViamVjdDogW09QU0FXR10gU2ltcGxp ZmllZCBBbHRlcm5hdGl2ZSB0byBDQVBXQVA8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PkRlYXIgYWxsLDwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+SSd2ZSBiZWVuIGZvbGxvd2luZyB0aGUgcmVjZW50IENBUFdB UCBhY3Rpdml0eSBvbiB0aGlzIGxpc3QgYW5kIHRob3VnaHQgSSBzaG91bGQgc2hhcmUgc29tZSBn ZW5lcmFsIHRob3VnaHRzIG9uIHRoZSBwcm90b2NvbCwgYW5kIHNlZSBpZiB0aGVyZSdzIGludGVy ZXN0IGluIGEgYnJvYWRlciBhcHByb2FjaC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 PlRoZSBDQVBXQVAgc2hvcnRjb21pbmdzIGRpc2N1c3NlZCBhcmUgc2ltaWxhciB0byB0aGUgcHJv YmxlbXMgcHJldmVudGluZyB1cyBbMV0gZnJvbSB1c2luZyBpdCBpbiBvdXIgU29mdHdhcmUtRGVm aW5lZCBOZXR3b3JraW5nPC9kaXY+DQo8ZGl2PihTRE4pIGFyY2hpdGVjdHVyZSBmb3IgSUVFRSA4 MDIuMTEgWzJdOjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+MS4gQ0FQV0FQIHdhcyBz cGVjaWZpZWQgYmVmb3JlIHNlcGFyYXRpb24gb2YgZGF0YSwgY29udHJvbCBhbmQgbWFuYWdlbWVu dCBwbGFuZXMgYmVjYW1lIHRoZSBub3JtIGluIG5ldHdvcmtpbmcgYXJjaGl0ZWN0dXJlLjwvZGl2 Pg0KPGRpdj5VbnN1cnByaXNpbmdseSBpdCBwcm92aWRlcyB2ZXJ5IGxpdHRsZSBzZXBhcmF0aW9u IG9mIGNvbmNlcm4sIGNvbmZsYXRpbmcgZXZlcnl0aGluZyBmcm9tIGZpcm13YXJlIHVwZGF0ZXMg dG8gY29uZmlndXJhdGlvbiBvZiBhbiBleHRyYSBTU0lELjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+Mi4gQ0FQV0FQIGF0dGVtcHRzIHRvIHByb3ZpZGUgcHJvdmlzaW9uaW5nL21hbmFn ZW1lbnQgZnVuY3Rpb25hbGl0eSB0aGF0IG92ZXJsYXBzIHdpdGggb3RoZXIgSUVURiBzdGFuZGFy ZHMgdHJhY2sgcHJvdG9jb2xzLCBlLmcuIFNOTVAgYW5kIE5FVENPTkYvWUFORywgYXMgd2VsbCBh cyBvdGhlciBlc3RhYmxpc2hlZCBtYW5hZ2VtZW50IHByb3RvY29scyBzdWNoIGFzIFRSLTA2OS48 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjMuIFRoZSBzZXBhcmF0aW9uIG9mIGRhdGEg YW5kIGNvbnRyb2wgcGxhbmVzIHRoYXQgQ0FQV0FQIGRvZXMgcHJvdmlkZSBpcyBJTUhPIGluY29y cmVjdDogODAyLjFYIGtleSBleGNoYW5nZSBpcyBjb25zaWRlcmVkIHBhcnQgb2YgdGhlIGNvbnRy b2wgcGxhbmUgYnV0IHRoZSBkZXJpdmVkIGVuY3J5cHRpb24ga2V5cyBwcm90ZWN0IHRoZSBkYXRh IHBsYW5lLjwvZGl2Pg0KPGRpdj5UaGlzIGRvZXNuJ3QgbWF0dGVyIHdoZW4gYm90aCBjb250cm9s IGFuZCBkYXRhIHBsYW5lIHRlcm1pbmF0ZSBpbiB0aGUgc2FtZSBsb2NhdGlvbiAodGhlIEFDKSwg YnV0IGJlY29tZXMgYSBwcm9ibGVtIHdoZW4gdGhleSBhcmUgc2VwYXJhdGVkIChlbmNyeXB0aW9u IGtleXMgZW5kIHVwIGluIGEgZGlmZmVyZW50IHBsYWNlIHRoYW4gdGhlIGVuY3J5cHRlZCBkYXRh ISkuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj40LiBDQVBXQVAgbGVhdmVzIG1hbnkg b3B0aW9ucyBvcGVuIHRvIHRoZSBpbXBsZW1lbnRlciBhbmQgaXMgdGhlcmVmb3JlIGxlc3MgaW50 ZXJvcGVyYWJsZSB0aGFuIGRlc2lyZWQuIFRvIHNvbWUgZXh0ZW50IHRoaXMgY2FuIGJlIHNvbHZl ZCB3aXRoIHJ1bi10aW1lIG5lZ290aWF0aW9uLCBidXQgc3VjaCBuZWdvdGlhdGlvbiBvZiBzZWN1 cml0eSBjcml0aWNhbCBhc3BlY3RzIChzdWNoIGFzIHdoZXJlIGVuY3J5cHRpb24ga2V5cyBhcmUg ZGVyaXZlZA0KYW5kIGtlcHQpIG1ha2VzIGl0IGltcG9zc2libGUgdG8gcmVhc29uIGFib3V0IHRo ZSBzZWN1cml0eSBvZiB0aGUgc3lzdGVtLiBUaGlzIGlzIGxlc3MgdGhhbiBpZGVhbCBJTUhPLjwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+NS4gQ0FQV0FQIChwYXJ0bHkgZHVlIHRvIDEg YW5kIDIgYWJvdmUpIGRlcGVuZHMgZXhjZXNzaXZlbHkgb24gZGV0YWlscyBpbiB0aGUgSUVFRSA4 MDIuMTEgc3RhbmRhcmQsIHdpdGggZWFjaCBhbWVuZG1lbnQgdGhyZWF0ZW5pbmcgdG8gaW1wYWN0 IHRoZSBwcm90b2NvbC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5XZSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIHNwZWNpZnlpbmcgYSBzaW1wbGlmaWVk IHR1bm5lbGluZyBwcm90b2NvbCBmb3IgSUVFRSA4MDIuMTEgc2ltaWxhciB0byBHZW5ldmUgWzNd LCBhdm9pZGluZyB0aGUgYWJvdmUgcHJvYmxlbXM6PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj5BLiBUaGUgcHJvdG9jb2wgc2hvdWxkIG1hbmRhdGUgYSBzaW5nbGUgd2VsbC1kZWZpbmVk IHBhcnRpdGlvbmluZyBvZiB0aGUgSUVFRSA4MDIuMTEgc3RhY2ssIHdpdGggODAyLjFYIGF1dGhl bnRpY2F0aW9uLCBrZXkgbWFuYWdlbWVudCBhbmQgZW5jcnlwdGlvbiBhbGwgaW1wbGVtZW50ZWQg YXQgdGhlIHR1bm5lbCB0ZXJtaW5hdGlvbiBwb2ludCBmb3Igc2VjdXJpdHkgcmVhc29ucy48L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkIuIFRoZSBwcm90b2NvbCBzaG91bGQgbWFuZGF0 ZSBhIHNpbmdsZSB3ZWxsLWRlZmluZWQgZnJhbWUgZm9ybWF0IHJlbHlpbmcgb25seSBvbiBhIFBI WS1pbmRlcGVuZGVudCBzdGFibGUgc3Vic2V0IG9mIElFRUUgODAyLjExLCBlbnN1cmluZyBjb21w YXRpYmlsaXR5IHdpdGggMTFuL2FjIGFuZCAobW9zdCBsaWtlbHkpIGJleW9uZC48L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkMuIExpa2UgR2VuZXZlIHRoZSBwcm90b2NvbCBzaG91bGQg bm90IHByb3ZpZGUgYW55IHByb3Zpc2lvbmluZy9tYW5hZ2VtZW50IGZ1bmN0aW9uYWxpdHksIGlu c3RlYWQgcmVseWluZyBvbiBTTk1QLCBORVRDT05GL1lBTkcsIFRSLTA2OSBhbmQgc2ltaWxhci48 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkQuIExpa2UgR2VuZXZlIHRoZSBwcm90b2Nv bCBzaG91bGQgbm90IHByb3ZpZGUgYW55IGNvbnRyb2wgcGxhbmUgZnVuY3Rpb25hbGl0eSwgaW5z dGVhZCByZW1haW5pbmcgY29tcGF0aWJsZSB3aXRoIHNldmVyYWwgU29mdHdhcmUtRGVmaW5lZCBO ZXR3b3JraW5nIChTRE4pIHByb3RvY29scyBmb3IgSUVFRSA4MDIuMTEuPC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj5FLiBFYWNoIHZpcnR1YWwgYWNjZXNzIHBvaW50IGluIGEgbXVsdGkt QlNTSUQgKGFuZC9vciBtdWx0aS1yYWRpbykgYWNjZXNzIHBvaW50IHNob3VsZCBiZSB0cmVhdGVk IGFzIGEgc2VwYXJhdGUgZW50aXR5IGFzc29jaWF0ZWQgd2l0aCBhIHNlcGFyYXRlIHR1bm5lbC48 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5XZSBzZWUg c3Ryb25nIGJlbmVmaXRzIHRvIHN1Y2ggYSBwcm90b2NvbCBmcm9tIGFuIGV4dGVuc2liaWxpdHkg WzRdLCBmbGV4aWJpbGl0eSBbNV0gYW5kIHNlY3VyaXR5IFs2XSBwZXJzcGVjdGl2ZS4gSWYgdGhl cmUgaXMgaW50ZXJlc3QgaW4gZXhwbG9yaW5nIHRoaXMgZnVydGhlciBwbGVhc2UgbGV0IG1lIGtu b3cuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5CasO2cm4gU21lZG1hbjwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+MS4gPGEgaHJlZj0iaHR0cDovL3d3dy5hbnlmaW5ldHdvcmtzLmNvbSI+aHR0 cDovL3d3dy5hbnlmaW5ldHdvcmtzLmNvbTwvYT48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PjIuIDxhIGhyZWY9Imh0dHA6 Ly9hbnlmaS5uZXQiPmh0dHA6Ly9hbnlmaS5uZXQ8L2E+IGFuZCA8YSBocmVmPSJodHRwOi8vd3d3 LmFueWZpbmV0d29ya3MuY29tL3Byb2R1Y3RzIj5odHRwOi8vd3d3LmFueWZpbmV0d29ya3MuY29t L3Byb2R1Y3RzPC9hPjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZu YnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+My4gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZ3Jvc3MtZ2VuZXZlLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1ncm9zcy1nZW5ldmUtMDA8L2E+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj40LiA8YSBocmVmPSJodHRwOi8vYW55 ZmkubmV0L2RvY3VtZW50YXRpb24jYXJjaGl0ZWN0dXJlIj5odHRwOi8vYW55ZmkubmV0L2RvY3Vt ZW50YXRpb24jYXJjaGl0ZWN0dXJlPC9hPjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+NS4gPGEgaHJlZj0iaHR0cDovL2Fu eWZpLm5ldC9kb2N1bWVudGF0aW9uI2FfaG93X2l0X2FsbF9maXRzX3RvZ2V0aGVyIj5odHRwOi8v YW55ZmkubmV0L2RvY3VtZW50YXRpb24jYV9ob3dfaXRfYWxsX2ZpdHNfdG9nZXRoZXI8L2E+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2 Pg0KPGRpdj42LiA8YSBocmVmPSJodHRwOi8vYW55ZmkubmV0L2RvY3VtZW50YXRpb24jaV9zZWN1 cml0eV9tb2RlbCI+aHR0cDovL2FueWZpLm5ldC9kb2N1bWVudGF0aW9uI2lfc2VjdXJpdHlfbW9k ZWw8L2E+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m b250PjwvZGl2Pg0KPGRpdj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvZGl2Pg0KPGRpdj5PUFNBV0cgbWFpbGluZyBsaXN0PC9kaXY+DQo8ZGl2Pjxmb250 IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGEgaHJlZj0ibWFpbHRvOk9QU0FXR0BpZXRmLm9yZyI+ PGZvbnQgZmFjZT0iQ2FsaWJyaSI+T1BTQVdHQGlldGYub3JnPC9mb250PjwvYT48L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2ciPjxmb250IGZhY2U9IkNhbGlicmki Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnPC9mb250PjwvYT48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m b250PjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4ED2E36A22261145861BAB2C24088B4320F5D75Fxmbalnx09ciscoc_-- From nobody Mon Feb 24 17:53: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 EF4C71A0393 for ; Mon, 24 Feb 2014 17:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 79RQPMZebL2l for ; Mon, 24 Feb 2014 17:53:46 -0800 (PST) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA091A0224 for ; Mon, 24 Feb 2014 17:53:46 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id wp18so8019003obc.36 for ; Mon, 24 Feb 2014 17:53:45 -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 :content-transfer-encoding; bh=v54qb7hQwts7gZJ3+wWXI0eejYqSLywXhOmVO9SiC2Q=; b=RuckPON6wDzeL21QAg4VXVjeNhn5rWXZNbdBJcUeM5PBJTnODL/7HldexfSJBV3pk0 58vevc4AzMYeCewUAoty6NJ5gFBNB8TncTyxET6TH7Jvqq3LU5EGSDOGi2fwk8zo4644 m16vAVhMtwihKP6ZWJiHkbWkpyoe8UnK6PifGEVlbfO9z8VAN5yBOOwrRMdRdNKwV32S FZnvEsVRsl3cngHk7iV4MssQOmXIK1UnQA0oMkABCLaurISqBkXH2qTPSnpa8m78q70P umcKhA8vDx789iBIkHD9rLia4t4bWhfrwoZt0JU0L2BjkbwJUCOTjbR/85cNaBt5F7hz jJkg== X-Gm-Message-State: ALoCoQnRlbDUdpEeIt8+HceVuCIeKQmoZcAGsC9zXjHOFu2IzbfH0g3ShOqsZB6DIRDVKXKlWnta MIME-Version: 1.0 X-Received: by 10.60.115.68 with SMTP id jm4mr19004362oeb.45.1393293225736; Mon, 24 Feb 2014 17:53:45 -0800 (PST) Received: by 10.182.191.9 with HTTP; Mon, 24 Feb 2014 17:53:45 -0800 (PST) X-Originating-IP: [109.124.181.146] In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320F5D75F@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320F5D75F@xmb-aln-x09.cisco.com> Date: Tue, 25 Feb 2014 02:53:45 +0100 Message-ID: From: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= To: "Rajesh Pazhyannur (rpazhyan)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/oGmMIVJDQ-n3ImISW0UAtv4jHq0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP 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, 25 Feb 2014 01:53:49 -0000 Hi Rajesh, On Tue, Feb 25, 2014 at 1:29 AM, Rajesh Pazhyannur (rpazhyan) wrote: > > Thanks for the well captured email. Would like to explore more about wha= t > you are suggesting. Thanks, it's much appreciated. > In the meanwhile, > > > 3. The separation of data and control planes that CAPWAP does provide i= s > > IMHO incorrect: 802.1X key exchange is considered part of the control p= lane > > but the derived encryption keys protect the data plane. > > This doesn't matter when both control and data plane terminate in the s= ame > > location (the AC), but becomes a problem when they are separated (encry= ption > > keys end up in a different place than the encrypted data!). > > Technically speaking, 802.1X protects the 802.11 frames and does not have > anything to do CAPWAP Data channel. The Data channel is protected using > DTLS. It is conceivable that 1) the tunnel mode is encapsulating 802.11 > frames (instead of 802.3 frames) and 2) CAPWAP-Data is not encrypted and = 3) > 802.11 encryption is happening at the AC instead of AP. When all three > conditions hold, what you are saying is true: 802.1X is indeed protecting > the data plane. True, in CAPWAP it's a border case that 802.1X key exchange and 802.11 encryption protects the user data plane all the way from the mobile STA to the AC. But I think there are strong reasons to make this the default: * DTLS cannot protect the user data plane inside the WTP. If 802.11 encryption keys and clear-text user data is available inside the WTP and the WTP is not physically protected then (at least from a theoretical perspective) the integrity and confidentiality of the data plane cannot be trusted. * DTLS encryption is also wasteful: encrypted 802.11 data frames come in over the air, are unencrypted in the WTP and then encrypted again with DTLS. * DTLS also provides authentication, but to me it makes little sense to authenticate an untrusted party. If the WTP can be under the physical control of an attacker, then there is no point in authenticating it against a digital certificate stored in the WTP. IMHO encrypting the CAPWAP-Data channel with DTLS and authenticating the WTP is borderline "security by obscurity" in that it relies on an attacker not being able to gain access to WTP memory. This assumption may have been relatively true in the corporate WLAN environment that CAPWAP was designed for, but it's less and less true for carrier Wi-Fi deployments. When on the other hand the 802.11 encryption is relied upon to protect the user data plane the WTP is simply excluded from the security equation: Even an attacker in complete control of the WTP is no threat to the integrity or confidentiality of the user data plane (since they have access to nothing more than the encrypted 802.11 frames which are also available from the air). That also means there's no real need to authenticate the WTP, and the security model is greatly simplified. > > A. The protocol should mandate a single well-defined partitioning of th= e > > IEEE 802.11 stack, with 802.1X authentication, key management and encry= ption > > all implemented at the tunnel termination point for security reasons. > > By this I am assuming that you want encryption at the Tunnel termination > point rather than the AP. What is motivating this, given that all APs (th= at > I know of) implement 802.11 encryption and if security is needed between = AP > and Tunnel termination point then one could use IPSEC or DTLS. Yes, if piecewise security is sufficient then there are a multitude of IETF protocols to chose from. But if end-to-end 802.11 encryption all the way from the mobile STA to a trusted location (e.g. a service/access router in the network core) is desired then there is nothing in the IETF playbook except a border case of CAPWAP, which comes with an entangled control and provisioning/management plane. Best regards, Bj=C3=B6rn > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Bj=C3=B6rn Sme= dman > Sent: Monday, February 24, 2014 2:57 PM > To: opsawg@ietf.org > Subject: [OPSAWG] Simplified Alternative to CAPWAP > > Dear all, > > I've been following the recent CAPWAP activity on this list and thought I > should share some general thoughts on the protocol, and see if there's > interest in a broader approach. > > The CAPWAP shortcomings discussed are similar to the problems preventing = us > [1] from using it in our Software-Defined Networking > (SDN) architecture for IEEE 802.11 [2]: > > 1. CAPWAP was specified before separation of data, control and management > planes became the norm in networking architecture. > Unsurprisingly it provides very little separation of concern, conflating > everything from firmware updates to configuration of an extra SSID. > > 2. CAPWAP attempts to provide provisioning/management functionality that > overlaps with other IETF standards track protocols, e.g. SNMP and > NETCONF/YANG, as well as other established management protocols such as > TR-069. > > 3. The separation of data and control planes that CAPWAP does provide is > IMHO incorrect: 802.1X key exchange is considered part of the control pla= ne > but the derived encryption keys protect the data plane. > This doesn't matter when both control and data plane terminate in the sam= e > location (the AC), but becomes a problem when they are separated (encrypt= ion > keys end up in a different place than the encrypted data!). > > 4. CAPWAP leaves many options open to the implementer and is therefore le= ss > interoperable than desired. To some extent this can be solved with run-ti= me > negotiation, but such negotiation of security critical aspects (such as > where encryption keys are derived and kept) makes it impossible to reason > about the security of the system. This is less than ideal IMHO. > > 5. CAPWAP (partly due to 1 and 2 above) depends excessively on details in > the IEEE 802.11 standard, with each amendment threatening to impact the > protocol. > > > We would be interested in specifying a simplified tunneling protocol for > IEEE 802.11 similar to Geneve [3], avoiding the above problems: > > A. The protocol should mandate a single well-defined partitioning of the > IEEE 802.11 stack, with 802.1X authentication, key management and encrypt= ion > all implemented at the tunnel termination point for security reasons. > > B. The protocol should mandate a single well-defined frame format relying > only on a PHY-independent stable subset of IEEE 802.11, ensuring > compatibility with 11n/ac and (most likely) beyond. > > C. Like Geneve the protocol should not provide any provisioning/managemen= t > functionality, instead relying on SNMP, NETCONF/YANG, TR-069 and similar. > > D. Like Geneve the protocol should not provide any control plane > functionality, instead remaining compatible with several Software-Defined > Networking (SDN) protocols for IEEE 802.11. > > E. Each virtual access point in a multi-BSSID (and/or multi-radio) access > point should be treated as a separate entity associated with a separate > tunnel. > > > We see strong benefits to such a protocol from an extensibility [4], > flexibility [5] and security [6] perspective. If there is interest in > exploring this further please let me know. > > Best regards, > > Bj=C3=B6rn Smedman > > 1. http://www.anyfinetworks.com > > 2. http://anyfi.net and http://www.anyfinetworks.com/products > > 3. http://tools.ietf.org/html/draft-gross-geneve-00 > > 4. http://anyfi.net/documentation#architecture > > 5. http://anyfi.net/documentation#a_how_it_all_fits_together > > 6. http://anyfi.net/documentation#i_security_model > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Mon Feb 24 22:29: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 ACAD21A023F for ; Mon, 24 Feb 2014 22:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.747 X-Spam-Level: X-Spam-Status: No, score=-9.747 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, 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 KisxioYL1zsf for ; Mon, 24 Feb 2014 22:29:38 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 163A91A0318 for ; Mon, 24 Feb 2014 22:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30128; q=dns/txt; s=iport; t=1393309777; x=1394519377; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GtqncUx4Qukb1FXCiYFKs7vZGyGYLhSIYwHrcmqx3LQ=; b=MCHejwb5zB5oCpQYz3dPJlALclkvPYJGyrKjgWlZGexu/gulAQhEdVdm aBpNsnI4TWx34iJrntCdTKaGLkMYh/ZdZ6xpeN605lrhLDKkjdFeZHM5T SbkNkz+PuPW9HcmWe07c69doGmn5hII3JIJSWMxhcuArxUxjCaxxjKU0/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYFAO83DFOtJV2Z/2dsb2JhbABYgkJEO1eDA7VyhGmDIE8YfhZ0giUBAQEDAQEBASAKKBIFAggDBQcEAgEIEQEDAQEBCh0DAgICJQsUAwYIAgQOBQiHdQgNphOgUheOAhEBHy0EBwYDgmY1gRQEmWaLMIVFgy2BcTk X-IronPort-AV: E=Sophos; i="4.97,538,1389744000"; d="scan'208,217"; a="22941595" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 25 Feb 2014 06:29:36 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1P6TbM8013341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 06:29:37 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.22]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 00:29:36 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: =?utf-8?B?QmrDtnJuIFNtZWRtYW4=?= Thread-Topic: [OPSAWG] Simplified Alternative to CAPWAP Thread-Index: AQHPMbPgQtd3dWdjMUewmYg0xTSiXZrFGNzwgACBJoD//+SwAA== Date: Tue, 25 Feb 2014 06:29:35 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F5D8F1@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320F5D75F@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.73.146] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F5D8F1xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/nfn92h9O1qCQ_jxDVjptVfwHjas Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP 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, 25 Feb 2014 06:29:42 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F5D8F1xmbalnx09ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQmpvcm4NCg0KPiAgICAgICBZZXMsIGlmIHBpZWNld2lzZSBzZWN1cml0eSBpcyBzdWZm aWNpZW50IHRoZW4gdGhlcmUgYXJlIGEgbXVsdGl0dWRlIG9mIElFVEYgcHJvdG9jb2xzIHRvIGNo b3NlIGZyb20uIEJ1dCBpZiBlbmQtdG8tZW5kIDgwMi4xMSBlbmNyeXB0aW9uIGFsbCB0aGUgd2F5 IGZyb20gdGhlIG1vYmlsZSBTVEEgdG8gYSB0cnVzdGVkIGxvY2F0aW9uIChlLmcuIGEgc2Vydmlj ZS9hY2Nlc3Mgcm91dGVyIGluIHRoZSBuZXR3b3JrIGNvcmUpIGlzIGRlc2lyZWQgdGhlbiB0aGVy ZSBpcyBub3RoaW5nIGluIHRoZSBJRVRGIHBsYXlib29rIGV4Y2VwdCBhIGJvcmRlciBjYXNlIG9m IENBUFdBUCwgd2hpY2ggY29tZXMgd2l0aCBhbiBlbnRhbmdsZWQgY29udHJvbCBhbmQgcHJvdmlz aW9uaW5nL21hbmFnZW1lbnQgcGxhbmUuDQoNCk9rYXksIEkgdW5kZXJzdGFuZCB0aGUgcHJvYmxl bSBzdGF0ZW1lbnQgbXVjaCBiZXR0ZXIuDQpDYW4geW91IGV4cGxhaW4gdGhlIHBhcnQgYWJvdXQg 4oCcZW50YW5nbGVkIGNvbnRyb2zigJ0uICBJcyB0aGlzIGJlY2F1c2UgaW4gdGhlIGV4aXN0aW5n IENBUFdBUCBtb2RlbCwgODAyLjFYIGlzIGFsd2F5cyBoYW5kbGVkIGJ5IHRoZSBBQyAoZXZlbiBp ZiB0aGUgZGF0YSBjaGFubmVsIGlzIHR1bm5lbGVkIHRvIGFub3RoZXIgQVIpIGFuZCB5b3Ugd2Fu dCA4MDIuMVggdG8gYmUgaGFuZGxlZCBieSB0aGUgVHVubmVsIFRlcm1pbmF0aW9uIEdhdGV3YXku DQoNClJlZ2FyZHMNCg0KUmFqZXNoDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog QmrDtnJuIFNtZWRtYW4gW21haWx0bzpiam9ybi5zbWVkbWFuQGFueWZpbmV0d29ya3MuY29tXQ0K U2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCA1OjU0IFBNDQpUbzogUmFqZXNoIFBhemh5 YW5udXIgKHJwYXpoeWFuKQ0KQ2M6IG9wc2F3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPUFNB V0ddIFNpbXBsaWZpZWQgQWx0ZXJuYXRpdmUgdG8gQ0FQV0FQDQoNCkhpIFJhamVzaCwNCg0KT24g VHVlLCBGZWIgMjUsIDIwMTQgYXQgMToyOSBBTSwgUmFqZXNoIFBhemh5YW5udXIgKHJwYXpoeWFu KSA8cnBhemh5YW5AY2lzY28uY29tPG1haWx0bzpycGF6aHlhbkBjaXNjby5jb20+PiB3cm90ZToN Cj4NCj4gVGhhbmtzIGZvciB0aGUgd2VsbCBjYXB0dXJlZCBlbWFpbC4gIFdvdWxkIGxpa2UgdG8g ZXhwbG9yZSBtb3JlIGFib3V0DQo+IHdoYXQgeW91IGFyZSBzdWdnZXN0aW5nLg0KDQpUaGFua3Ms IGl0J3MgbXVjaCBhcHByZWNpYXRlZC4NCg0KPiBJbiB0aGUgbWVhbndoaWxlLA0KPg0KPiA+IDMu IFRoZSBzZXBhcmF0aW9uIG9mIGRhdGEgYW5kIGNvbnRyb2wgcGxhbmVzIHRoYXQgQ0FQV0FQIGRv ZXMNCj4gPiBwcm92aWRlIGlzIElNSE8gaW5jb3JyZWN0OiA4MDIuMVgga2V5IGV4Y2hhbmdlIGlz IGNvbnNpZGVyZWQgcGFydCBvZg0KPiA+IHRoZSBjb250cm9sIHBsYW5lIGJ1dCB0aGUgZGVyaXZl ZCBlbmNyeXB0aW9uIGtleXMgcHJvdGVjdCB0aGUgZGF0YSBwbGFuZS4NCj4gPiBUaGlzIGRvZXNu J3QgbWF0dGVyIHdoZW4gYm90aCBjb250cm9sIGFuZCBkYXRhIHBsYW5lIHRlcm1pbmF0ZSBpbg0K PiA+IHRoZSBzYW1lIGxvY2F0aW9uICh0aGUgQUMpLCBidXQgYmVjb21lcyBhIHByb2JsZW0gd2hl biB0aGV5IGFyZQ0KPiA+IHNlcGFyYXRlZCAoZW5jcnlwdGlvbiBrZXlzIGVuZCB1cCBpbiBhIGRp ZmZlcmVudCBwbGFjZSB0aGFuIHRoZSBlbmNyeXB0ZWQgZGF0YSEpLg0KPg0KPiBUZWNobmljYWxs eSBzcGVha2luZywgODAyLjFYIHByb3RlY3RzIHRoZSA4MDIuMTEgZnJhbWVzIGFuZCBkb2VzIG5v dA0KPiBoYXZlIGFueXRoaW5nIHRvIGRvIENBUFdBUCBEYXRhIGNoYW5uZWwuIFRoZSBEYXRhIGNo YW5uZWwgaXMgcHJvdGVjdGVkDQo+IHVzaW5nIERUTFMuIEl0IGlzIGNvbmNlaXZhYmxlIHRoYXQg MSkgdGhlIHR1bm5lbCBtb2RlIGlzIGVuY2Fwc3VsYXRpbmcNCj4gODAyLjExIGZyYW1lcyAoaW5z dGVhZCBvZiA4MDIuMyBmcmFtZXMpIGFuZCAyKSBDQVBXQVAtRGF0YSBpcyBub3QNCj4gZW5jcnlw dGVkIGFuZCAzKQ0KPiA4MDIuMTEgZW5jcnlwdGlvbiBpcyBoYXBwZW5pbmcgYXQgdGhlIEFDIGlu c3RlYWQgb2YgQVAuIFdoZW4gYWxsIHRocmVlDQo+IGNvbmRpdGlvbnMgaG9sZCwgd2hhdCB5b3Ug YXJlIHNheWluZyBpcyB0cnVlOiA4MDIuMVggaXMgaW5kZWVkDQo+IHByb3RlY3RpbmcgdGhlIGRh dGEgcGxhbmUuDQoNClRydWUsIGluIENBUFdBUCBpdCdzIGEgYm9yZGVyIGNhc2UgdGhhdCA4MDIu MVgga2V5IGV4Y2hhbmdlIGFuZCA4MDIuMTEgZW5jcnlwdGlvbiBwcm90ZWN0cyB0aGUgdXNlciBk YXRhIHBsYW5lIGFsbCB0aGUgd2F5IGZyb20gdGhlIG1vYmlsZSBTVEEgdG8gdGhlIEFDLiBCdXQg SSB0aGluayB0aGVyZSBhcmUgc3Ryb25nIHJlYXNvbnMgdG8gbWFrZSB0aGlzIHRoZQ0KZGVmYXVs dDoNCg0KKiBEVExTIGNhbm5vdCBwcm90ZWN0IHRoZSB1c2VyIGRhdGEgcGxhbmUgaW5zaWRlIHRo ZSBXVFAuIElmIDgwMi4xMSBlbmNyeXB0aW9uIGtleXMgYW5kIGNsZWFyLXRleHQgdXNlciBkYXRh IGlzIGF2YWlsYWJsZSBpbnNpZGUgdGhlIFdUUCBhbmQgdGhlIFdUUCBpcyBub3QgcGh5c2ljYWxs eSBwcm90ZWN0ZWQgdGhlbiAoYXQgbGVhc3QgZnJvbSBhIHRoZW9yZXRpY2FsIHBlcnNwZWN0aXZl KSB0aGUgaW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHkgb2YgdGhlIGRhdGEgcGxhbmUgY2Fu bm90IGJlIHRydXN0ZWQuDQoNCiogRFRMUyBlbmNyeXB0aW9uIGlzIGFsc28gd2FzdGVmdWw6IGVu Y3J5cHRlZCA4MDIuMTEgZGF0YSBmcmFtZXMgY29tZSBpbiBvdmVyIHRoZSBhaXIsIGFyZSB1bmVu Y3J5cHRlZCBpbiB0aGUgV1RQIGFuZCB0aGVuIGVuY3J5cHRlZCBhZ2FpbiB3aXRoIERUTFMuDQoN CiogRFRMUyBhbHNvIHByb3ZpZGVzIGF1dGhlbnRpY2F0aW9uLCBidXQgdG8gbWUgaXQgbWFrZXMg bGl0dGxlIHNlbnNlIHRvIGF1dGhlbnRpY2F0ZSBhbiB1bnRydXN0ZWQgcGFydHkuIElmIHRoZSBX VFAgY2FuIGJlIHVuZGVyIHRoZSBwaHlzaWNhbCBjb250cm9sIG9mIGFuIGF0dGFja2VyLCB0aGVu IHRoZXJlIGlzIG5vIHBvaW50IGluIGF1dGhlbnRpY2F0aW5nIGl0IGFnYWluc3QgYSBkaWdpdGFs IGNlcnRpZmljYXRlIHN0b3JlZCBpbiB0aGUgV1RQLg0KDQpJTUhPIGVuY3J5cHRpbmcgdGhlIENB UFdBUC1EYXRhIGNoYW5uZWwgd2l0aCBEVExTIGFuZCBhdXRoZW50aWNhdGluZyB0aGUgV1RQIGlz IGJvcmRlcmxpbmUgInNlY3VyaXR5IGJ5IG9ic2N1cml0eSIgaW4gdGhhdCBpdCByZWxpZXMgb24g YW4gYXR0YWNrZXIgbm90IGJlaW5nIGFibGUgdG8gZ2FpbiBhY2Nlc3MgdG8gV1RQIG1lbW9yeS4g VGhpcyBhc3N1bXB0aW9uIG1heSBoYXZlIGJlZW4gcmVsYXRpdmVseSB0cnVlIGluIHRoZSBjb3Jw b3JhdGUgV0xBTiBlbnZpcm9ubWVudCB0aGF0IENBUFdBUCB3YXMgZGVzaWduZWQgZm9yLCBidXQg aXQncyBsZXNzIGFuZCBsZXNzIHRydWUgZm9yIGNhcnJpZXIgV2ktRmkgZGVwbG95bWVudHMuDQoN CldoZW4gb24gdGhlIG90aGVyIGhhbmQgdGhlIDgwMi4xMSBlbmNyeXB0aW9uIGlzIHJlbGllZCB1 cG9uIHRvIHByb3RlY3QgdGhlIHVzZXIgZGF0YSBwbGFuZSB0aGUgV1RQIGlzIHNpbXBseSBleGNs dWRlZCBmcm9tIHRoZSBzZWN1cml0eQ0KZXF1YXRpb246IEV2ZW4gYW4gYXR0YWNrZXIgaW4gY29t cGxldGUgY29udHJvbCBvZiB0aGUgV1RQIGlzIG5vIHRocmVhdCB0byB0aGUgaW50ZWdyaXR5IG9y IGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgdXNlciBkYXRhIHBsYW5lIChzaW5jZSB0aGV5IGhhdmUg YWNjZXNzIHRvIG5vdGhpbmcgbW9yZSB0aGFuIHRoZSBlbmNyeXB0ZWQgODAyLjExIGZyYW1lcyB3 aGljaCBhcmUgYWxzbyBhdmFpbGFibGUgZnJvbSB0aGUgYWlyKS4gVGhhdCBhbHNvIG1lYW5zIHRo ZXJlJ3Mgbm8gcmVhbCBuZWVkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgV1RQLCBhbmQgdGhlIHNlY3Vy aXR5IG1vZGVsIGlzIGdyZWF0bHkgc2ltcGxpZmllZC4NCg0KPiA+IEEuIFRoZSBwcm90b2NvbCBz aG91bGQgbWFuZGF0ZSBhIHNpbmdsZSB3ZWxsLWRlZmluZWQgcGFydGl0aW9uaW5nIG9mDQo+ID4g dGhlIElFRUUgODAyLjExIHN0YWNrLCB3aXRoIDgwMi4xWCBhdXRoZW50aWNhdGlvbiwga2V5IG1h bmFnZW1lbnQNCj4gPiBhbmQgZW5jcnlwdGlvbiBhbGwgaW1wbGVtZW50ZWQgYXQgdGhlIHR1bm5l bCB0ZXJtaW5hdGlvbiBwb2ludCBmb3Igc2VjdXJpdHkgcmVhc29ucy4NCj4NCj4gQnkgdGhpcyBJ IGFtIGFzc3VtaW5nIHRoYXQgeW91IHdhbnQgZW5jcnlwdGlvbiBhdCB0aGUgVHVubmVsDQo+IHRl cm1pbmF0aW9uIHBvaW50IHJhdGhlciB0aGFuIHRoZSBBUC4gV2hhdCBpcyBtb3RpdmF0aW5nIHRo aXMsIGdpdmVuDQo+IHRoYXQgYWxsIEFQcyAodGhhdCBJIGtub3cgb2YpIGltcGxlbWVudCA4MDIu MTEgZW5jcnlwdGlvbiBhbmQgaWYNCj4gc2VjdXJpdHkgaXMgbmVlZGVkIGJldHdlZW4gQVAgYW5k IFR1bm5lbCB0ZXJtaW5hdGlvbiBwb2ludCB0aGVuIG9uZSBjb3VsZCB1c2UgSVBTRUMgb3IgRFRM Uy4NCg0KWWVzLCBpZiBwaWVjZXdpc2Ugc2VjdXJpdHkgaXMgc3VmZmljaWVudCB0aGVuIHRoZXJl IGFyZSBhIG11bHRpdHVkZSBvZiBJRVRGIHByb3RvY29scyB0byBjaG9zZSBmcm9tLiBCdXQgaWYg ZW5kLXRvLWVuZCA4MDIuMTEgZW5jcnlwdGlvbiBhbGwgdGhlIHdheSBmcm9tIHRoZSBtb2JpbGUg U1RBIHRvIGEgdHJ1c3RlZCBsb2NhdGlvbiAoZS5nLiBhIHNlcnZpY2UvYWNjZXNzIHJvdXRlciBp biB0aGUgbmV0d29yayBjb3JlKSBpcyBkZXNpcmVkIHRoZW4gdGhlcmUgaXMgbm90aGluZyBpbiB0 aGUgSUVURiBwbGF5Ym9vayBleGNlcHQgYSBib3JkZXIgY2FzZSBvZiBDQVBXQVAsIHdoaWNoIGNv bWVzIHdpdGggYW4gZW50YW5nbGVkIGNvbnRyb2wgYW5kIHByb3Zpc2lvbmluZy9tYW5hZ2VtZW50 IHBsYW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkJqw7Zybg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQmrDtnJuDQo+IFNtZWRtYW4NCj4gU2VudDogTW9uZGF5LCBGZWJydWFy eSAyNCwgMjAxNCAyOjU3IFBNDQo+IFRvOiBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0Bp ZXRmLm9yZz4NCj4gU3ViamVjdDogW09QU0FXR10gU2ltcGxpZmllZCBBbHRlcm5hdGl2ZSB0byBD QVBXQVANCj4NCj4gRGVhciBhbGwsDQo+DQo+IEkndmUgYmVlbiBmb2xsb3dpbmcgdGhlIHJlY2Vu dCBDQVBXQVAgYWN0aXZpdHkgb24gdGhpcyBsaXN0IGFuZA0KPiB0aG91Z2h0IEkgc2hvdWxkIHNo YXJlIHNvbWUgZ2VuZXJhbCB0aG91Z2h0cyBvbiB0aGUgcHJvdG9jb2wsIGFuZCBzZWUNCj4gaWYg dGhlcmUncyBpbnRlcmVzdCBpbiBhIGJyb2FkZXIgYXBwcm9hY2guDQo+DQo+IFRoZSBDQVBXQVAg c2hvcnRjb21pbmdzIGRpc2N1c3NlZCBhcmUgc2ltaWxhciB0byB0aGUgcHJvYmxlbXMNCj4gcHJl dmVudGluZyB1cyBbMV0gZnJvbSB1c2luZyBpdCBpbiBvdXIgU29mdHdhcmUtRGVmaW5lZCBOZXR3 b3JraW5nDQo+IChTRE4pIGFyY2hpdGVjdHVyZSBmb3IgSUVFRSA4MDIuMTEgWzJdOg0KPg0KPiAx LiBDQVBXQVAgd2FzIHNwZWNpZmllZCBiZWZvcmUgc2VwYXJhdGlvbiBvZiBkYXRhLCBjb250cm9s IGFuZA0KPiBtYW5hZ2VtZW50IHBsYW5lcyBiZWNhbWUgdGhlIG5vcm0gaW4gbmV0d29ya2luZyBh cmNoaXRlY3R1cmUuDQo+IFVuc3VycHJpc2luZ2x5IGl0IHByb3ZpZGVzIHZlcnkgbGl0dGxlIHNl cGFyYXRpb24gb2YgY29uY2VybiwNCj4gY29uZmxhdGluZyBldmVyeXRoaW5nIGZyb20gZmlybXdh cmUgdXBkYXRlcyB0byBjb25maWd1cmF0aW9uIG9mIGFuIGV4dHJhIFNTSUQuDQo+DQo+IDIuIENB UFdBUCBhdHRlbXB0cyB0byBwcm92aWRlIHByb3Zpc2lvbmluZy9tYW5hZ2VtZW50IGZ1bmN0aW9u YWxpdHkNCj4gdGhhdCBvdmVybGFwcyB3aXRoIG90aGVyIElFVEYgc3RhbmRhcmRzIHRyYWNrIHBy b3RvY29scywgZS5nLiBTTk1QIGFuZA0KPiBORVRDT05GL1lBTkcsIGFzIHdlbGwgYXMgb3RoZXIg ZXN0YWJsaXNoZWQgbWFuYWdlbWVudCBwcm90b2NvbHMgc3VjaA0KPiBhcyBUUi0wNjkuDQo+DQo+ IDMuIFRoZSBzZXBhcmF0aW9uIG9mIGRhdGEgYW5kIGNvbnRyb2wgcGxhbmVzIHRoYXQgQ0FQV0FQ IGRvZXMgcHJvdmlkZQ0KPiBpcyBJTUhPIGluY29ycmVjdDogODAyLjFYIGtleSBleGNoYW5nZSBp cyBjb25zaWRlcmVkIHBhcnQgb2YgdGhlDQo+IGNvbnRyb2wgcGxhbmUgYnV0IHRoZSBkZXJpdmVk IGVuY3J5cHRpb24ga2V5cyBwcm90ZWN0IHRoZSBkYXRhIHBsYW5lLg0KPiBUaGlzIGRvZXNuJ3Qg bWF0dGVyIHdoZW4gYm90aCBjb250cm9sIGFuZCBkYXRhIHBsYW5lIHRlcm1pbmF0ZSBpbiB0aGUN Cj4gc2FtZSBsb2NhdGlvbiAodGhlIEFDKSwgYnV0IGJlY29tZXMgYSBwcm9ibGVtIHdoZW4gdGhl eSBhcmUgc2VwYXJhdGVkDQo+IChlbmNyeXB0aW9uIGtleXMgZW5kIHVwIGluIGEgZGlmZmVyZW50 IHBsYWNlIHRoYW4gdGhlIGVuY3J5cHRlZCBkYXRhISkuDQo+DQo+IDQuIENBUFdBUCBsZWF2ZXMg bWFueSBvcHRpb25zIG9wZW4gdG8gdGhlIGltcGxlbWVudGVyIGFuZCBpcyB0aGVyZWZvcmUNCj4g bGVzcyBpbnRlcm9wZXJhYmxlIHRoYW4gZGVzaXJlZC4gVG8gc29tZSBleHRlbnQgdGhpcyBjYW4g YmUgc29sdmVkDQo+IHdpdGggcnVuLXRpbWUgbmVnb3RpYXRpb24sIGJ1dCBzdWNoIG5lZ290aWF0 aW9uIG9mIHNlY3VyaXR5IGNyaXRpY2FsDQo+IGFzcGVjdHMgKHN1Y2ggYXMgd2hlcmUgZW5jcnlw dGlvbiBrZXlzIGFyZSBkZXJpdmVkIGFuZCBrZXB0KSBtYWtlcyBpdA0KPiBpbXBvc3NpYmxlIHRv IHJlYXNvbiBhYm91dCB0aGUgc2VjdXJpdHkgb2YgdGhlIHN5c3RlbS4gVGhpcyBpcyBsZXNzIHRo YW4gaWRlYWwgSU1ITy4NCj4NCj4gNS4gQ0FQV0FQIChwYXJ0bHkgZHVlIHRvIDEgYW5kIDIgYWJv dmUpIGRlcGVuZHMgZXhjZXNzaXZlbHkgb24gZGV0YWlscw0KPiBpbiB0aGUgSUVFRSA4MDIuMTEg c3RhbmRhcmQsIHdpdGggZWFjaCBhbWVuZG1lbnQgdGhyZWF0ZW5pbmcgdG8gaW1wYWN0DQo+IHRo ZSBwcm90b2NvbC4NCj4NCj4NCj4gV2Ugd291bGQgYmUgaW50ZXJlc3RlZCBpbiBzcGVjaWZ5aW5n IGEgc2ltcGxpZmllZCB0dW5uZWxpbmcgcHJvdG9jb2wNCj4gZm9yIElFRUUgODAyLjExIHNpbWls YXIgdG8gR2VuZXZlIFszXSwgYXZvaWRpbmcgdGhlIGFib3ZlIHByb2JsZW1zOg0KPg0KPiBBLiBU aGUgcHJvdG9jb2wgc2hvdWxkIG1hbmRhdGUgYSBzaW5nbGUgd2VsbC1kZWZpbmVkIHBhcnRpdGlv bmluZyBvZg0KPiB0aGUgSUVFRSA4MDIuMTEgc3RhY2ssIHdpdGggODAyLjFYIGF1dGhlbnRpY2F0 aW9uLCBrZXkgbWFuYWdlbWVudCBhbmQNCj4gZW5jcnlwdGlvbiBhbGwgaW1wbGVtZW50ZWQgYXQg dGhlIHR1bm5lbCB0ZXJtaW5hdGlvbiBwb2ludCBmb3Igc2VjdXJpdHkgcmVhc29ucy4NCj4NCj4g Qi4gVGhlIHByb3RvY29sIHNob3VsZCBtYW5kYXRlIGEgc2luZ2xlIHdlbGwtZGVmaW5lZCBmcmFt ZSBmb3JtYXQNCj4gcmVseWluZyBvbmx5IG9uIGEgUEhZLWluZGVwZW5kZW50IHN0YWJsZSBzdWJz ZXQgb2YgSUVFRSA4MDIuMTEsDQo+IGVuc3VyaW5nIGNvbXBhdGliaWxpdHkgd2l0aCAxMW4vYWMg YW5kIChtb3N0IGxpa2VseSkgYmV5b25kLg0KPg0KPiBDLiBMaWtlIEdlbmV2ZSB0aGUgcHJvdG9j b2wgc2hvdWxkIG5vdCBwcm92aWRlIGFueQ0KPiBwcm92aXNpb25pbmcvbWFuYWdlbWVudCBmdW5j dGlvbmFsaXR5LCBpbnN0ZWFkIHJlbHlpbmcgb24gU05NUCwgTkVUQ09ORi9ZQU5HLCBUUi0wNjkg YW5kIHNpbWlsYXIuDQo+DQo+IEQuIExpa2UgR2VuZXZlIHRoZSBwcm90b2NvbCBzaG91bGQgbm90 IHByb3ZpZGUgYW55IGNvbnRyb2wgcGxhbmUNCj4gZnVuY3Rpb25hbGl0eSwgaW5zdGVhZCByZW1h aW5pbmcgY29tcGF0aWJsZSB3aXRoIHNldmVyYWwNCj4gU29mdHdhcmUtRGVmaW5lZCBOZXR3b3Jr aW5nIChTRE4pIHByb3RvY29scyBmb3IgSUVFRSA4MDIuMTEuDQo+DQo+IEUuIEVhY2ggdmlydHVh bCBhY2Nlc3MgcG9pbnQgaW4gYSBtdWx0aS1CU1NJRCAoYW5kL29yIG11bHRpLXJhZGlvKQ0KPiBh Y2Nlc3MgcG9pbnQgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgYSBzZXBhcmF0ZSBlbnRpdHkgYXNzb2Np YXRlZCB3aXRoIGENCj4gc2VwYXJhdGUgdHVubmVsLg0KPg0KPg0KPiBXZSBzZWUgc3Ryb25nIGJl bmVmaXRzIHRvIHN1Y2ggYSBwcm90b2NvbCBmcm9tIGFuIGV4dGVuc2liaWxpdHkgWzRdLA0KPiBm bGV4aWJpbGl0eSBbNV0gYW5kIHNlY3VyaXR5IFs2XSBwZXJzcGVjdGl2ZS4gSWYgdGhlcmUgaXMg aW50ZXJlc3QgaW4NCj4gZXhwbG9yaW5nIHRoaXMgZnVydGhlciBwbGVhc2UgbGV0IG1lIGtub3cu DQo+DQo+IEJlc3QgcmVnYXJkcywNCj4NCj4gQmrDtnJuIFNtZWRtYW4NCj4NCj4gMS4gaHR0cDov L3d3dy5hbnlmaW5ldHdvcmtzLmNvbQ0KPg0KPiAyLiBodHRwOi8vYW55ZmkubmV0IGFuZCBodHRw Oi8vd3d3LmFueWZpbmV0d29ya3MuY29tL3Byb2R1Y3RzDQo+DQo+IDMuIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWdyb3NzLWdlbmV2ZS0wMA0KPg0KPiA0LiBodHRwOi8vYW55Zmku bmV0L2RvY3VtZW50YXRpb24jYXJjaGl0ZWN0dXJlDQo+DQo+IDUuIGh0dHA6Ly9hbnlmaS5uZXQv ZG9jdW1lbnRhdGlvbiNhX2hvd19pdF9hbGxfZml0c190b2dldGhlcg0KPg0KPiA2LiBodHRwOi8v YW55ZmkubmV0L2RvY3VtZW50YXRpb24jaV9zZWN1cml0eV9tb2RlbA0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPUFNBV0cgbWFpbGluZyBs aXN0DQo+IE9QU0FXR0BpZXRmLm9yZzxtYWlsdG86T1BTQVdHQGlldGYub3JnPg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0KPg0KDQo= --_000_4ED2E36A22261145861BAB2C24088B4320F5D8F1xmbalnx09ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSI0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE2cHQ7Ij4NCjxkaXY+PGZvbnQgY29sb3I9IiM3MDMwQTAiPkhlbGxvIEJq b3JuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNw OzwvZm9udD48L2Rpdj4NCjx1bCBzdHlsZT0ibWFyZ2luOjA7cGFkZGluZy1sZWZ0OjM2cHQ7Ij4N CjxsaT5ZZXMsIGlmIHBpZWNld2lzZSBzZWN1cml0eSBpcyBzdWZmaWNpZW50IHRoZW4gdGhlcmUg YXJlIGEgbXVsdGl0dWRlIG9mIElFVEYgcHJvdG9jb2xzIHRvIGNob3NlIGZyb20uIEJ1dCBpZiBl bmQtdG8tZW5kIDgwMi4xMSBlbmNyeXB0aW9uIGFsbCB0aGUgd2F5IGZyb20gdGhlIG1vYmlsZSBT VEEgdG8gYSB0cnVzdGVkIGxvY2F0aW9uIChlLmcuIGEgc2VydmljZS9hY2Nlc3Mgcm91dGVyIGlu IHRoZSBuZXR3b3JrIGNvcmUpIGlzIGRlc2lyZWQNCnRoZW4gdGhlcmUgaXMgbm90aGluZyBpbiB0 aGUgSUVURiBwbGF5Ym9vayBleGNlcHQgYSBib3JkZXIgY2FzZSBvZiBDQVBXQVAsIHdoaWNoIGNv bWVzIHdpdGggYW4gZW50YW5nbGVkIGNvbnRyb2wgYW5kIHByb3Zpc2lvbmluZy9tYW5hZ2VtZW50 IHBsYW5lLjwvbGk+PC91bD4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJz cDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjNzAzMEEwIj5Pa2F5LCBJIHVuZGVy c3RhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IG11Y2ggYmV0dGVyLiA8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGNvbG9yPSIjNzAzMEEwIj5DYW4geW91IGV4cGxhaW4gdGhlIHBhcnQgYWJvdXQg 4oCcZW50YW5nbGVkIGNvbnRyb2zigJ0uJm5ic3A7IElzIHRoaXMgYmVjYXVzZSBpbiB0aGUgZXhp c3RpbmcgQ0FQV0FQIG1vZGVsLCA4MDIuMVggaXMgYWx3YXlzIGhhbmRsZWQgYnkgdGhlIEFDIChl dmVuIGlmIHRoZSBkYXRhIGNoYW5uZWwgaXMgdHVubmVsZWQgdG8gYW5vdGhlciBBUikgYW5kIHlv dSB3YW50IDgwMi4xWCB0byBiZSBoYW5kbGVkIGJ5IHRoZSBUdW5uZWwNClRlcm1pbmF0aW9uIEdh dGV3YXkuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzcwMzBBMCI+Jm5ic3A7PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzcwMzBBMCI+UmVnYXJkczwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgY29sb3I9IiM3MDMwQTAiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgY29sb3I9IiM3MDMwQTAiPlJhamVzaDwvZm9udD48L2Rpdj4NCjxkaXY+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQoNCkZyb206IEJqw7ZybiBTbWVkbWFuIFs8YSBocmVmPSJt YWlsdG86Ympvcm4uc21lZG1hbkBhbnlmaW5ldHdvcmtzLmNvbSI+bWFpbHRvOmJqb3JuLnNtZWRt YW5AYW55ZmluZXR3b3Jrcy5jb208L2E+XQ0KPGJyPg0KDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5 IDI0LCAyMDE0IDU6NTQgUE08YnI+DQoNClRvOiBSYWplc2ggUGF6aHlhbm51ciAocnBhemh5YW4p PGJyPg0KDQpDYzogb3BzYXdnQGlldGYub3JnPGJyPg0KDQpTdWJqZWN0OiBSZTogW09QU0FXR10g U2ltcGxpZmllZCBBbHRlcm5hdGl2ZSB0byBDQVBXQVA8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PkhpIFJhamVzaCw8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk9uIFR1ZSwgRmViIDI1LCAyMDE0IGF0IDE6Mjkg QU0sIFJhamVzaCBQYXpoeWFubnVyIChycGF6aHlhbikgJmx0OzxhIGhyZWY9Im1haWx0bzpycGF6 aHlhbkBjaXNjby5jb20iPnJwYXpoeWFuQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgVGhhbmtzIGZvciB0aGUgd2VsbCBjYXB0dXJlZCBl bWFpbC4mbmJzcDsgV291bGQgbGlrZSB0byBleHBsb3JlIG1vcmUgYWJvdXQgPC9kaXY+DQo8ZGl2 PiZndDsgd2hhdCB5b3UgYXJlIHN1Z2dlc3RpbmcuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj5UaGFua3MsIGl0J3MgbXVjaCBhcHByZWNpYXRlZC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8ZGl2PiZndDsgSW4gdGhlIG1lYW53aGlsZSw8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0K PGRpdj4mZ3Q7ICZndDsgMy4gVGhlIHNlcGFyYXRpb24gb2YgZGF0YSBhbmQgY29udHJvbCBwbGFu ZXMgdGhhdCBDQVBXQVAgZG9lcyA8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IHByb3ZpZGUgaXMgSU1I TyBpbmNvcnJlY3Q6IDgwMi4xWCBrZXkgZXhjaGFuZ2UgaXMgY29uc2lkZXJlZCBwYXJ0IG9mIDwv ZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgdGhlIGNvbnRyb2wgcGxhbmUgYnV0IHRoZSBkZXJpdmVkIGVu Y3J5cHRpb24ga2V5cyBwcm90ZWN0IHRoZSBkYXRhIHBsYW5lLjwvZGl2Pg0KPGRpdj4mZ3Q7ICZn dDsgVGhpcyBkb2Vzbid0IG1hdHRlciB3aGVuIGJvdGggY29udHJvbCBhbmQgZGF0YSBwbGFuZSB0 ZXJtaW5hdGUgaW4gPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyB0aGUgc2FtZSBsb2NhdGlvbiAodGhl IEFDKSwgYnV0IGJlY29tZXMgYSBwcm9ibGVtIHdoZW4gdGhleSBhcmUgPC9kaXY+DQo8ZGl2PiZn dDsgJmd0OyBzZXBhcmF0ZWQgKGVuY3J5cHRpb24ga2V5cyBlbmQgdXAgaW4gYSBkaWZmZXJlbnQg cGxhY2UgdGhhbiB0aGUgZW5jcnlwdGVkIGRhdGEhKS48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0K PGRpdj4mZ3Q7IFRlY2huaWNhbGx5IHNwZWFraW5nLCA4MDIuMVggcHJvdGVjdHMgdGhlIDgwMi4x MSBmcmFtZXMgYW5kIGRvZXMgbm90IDwvZGl2Pg0KPGRpdj4mZ3Q7IGhhdmUgYW55dGhpbmcgdG8g ZG8gQ0FQV0FQIERhdGEgY2hhbm5lbC4gVGhlIERhdGEgY2hhbm5lbCBpcyBwcm90ZWN0ZWQgPC9k aXY+DQo8ZGl2PiZndDsgdXNpbmcgRFRMUy4gSXQgaXMgY29uY2VpdmFibGUgdGhhdCAxKSB0aGUg dHVubmVsIG1vZGUgaXMgZW5jYXBzdWxhdGluZyA8L2Rpdj4NCjxkaXY+Jmd0OyA4MDIuMTEgZnJh bWVzIChpbnN0ZWFkIG9mIDgwMi4zIGZyYW1lcykgYW5kIDIpIENBUFdBUC1EYXRhIGlzIG5vdCA8 L2Rpdj4NCjxkaXY+Jmd0OyBlbmNyeXB0ZWQgYW5kIDMpPC9kaXY+DQo8ZGl2PiZndDsgODAyLjEx IGVuY3J5cHRpb24gaXMgaGFwcGVuaW5nIGF0IHRoZSBBQyBpbnN0ZWFkIG9mIEFQLiBXaGVuIGFs bCB0aHJlZSA8L2Rpdj4NCjxkaXY+Jmd0OyBjb25kaXRpb25zIGhvbGQsIHdoYXQgeW91IGFyZSBz YXlpbmcgaXMgdHJ1ZTogODAyLjFYIGlzIGluZGVlZCA8L2Rpdj4NCjxkaXY+Jmd0OyBwcm90ZWN0 aW5nIHRoZSBkYXRhIHBsYW5lLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VHJ1ZSwg aW4gQ0FQV0FQIGl0J3MgYSBib3JkZXIgY2FzZSB0aGF0IDgwMi4xWCBrZXkgZXhjaGFuZ2UgYW5k IDgwMi4xMSBlbmNyeXB0aW9uIHByb3RlY3RzIHRoZSB1c2VyIGRhdGEgcGxhbmUgYWxsIHRoZSB3 YXkgZnJvbSB0aGUgbW9iaWxlIFNUQSB0byB0aGUgQUMuIEJ1dCBJIHRoaW5rIHRoZXJlIGFyZSBz dHJvbmcgcmVhc29ucyB0byBtYWtlIHRoaXMgdGhlPC9kaXY+DQo8ZGl2PmRlZmF1bHQ6PC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4qIERUTFMgY2Fubm90IHByb3RlY3QgdGhlIHVzZXIg ZGF0YSBwbGFuZSBpbnNpZGUgdGhlIFdUUC4gSWYgODAyLjExIGVuY3J5cHRpb24ga2V5cyBhbmQg Y2xlYXItdGV4dCB1c2VyIGRhdGEgaXMgYXZhaWxhYmxlIGluc2lkZSB0aGUgV1RQIGFuZCB0aGUg V1RQIGlzIG5vdCBwaHlzaWNhbGx5IHByb3RlY3RlZCB0aGVuIChhdCBsZWFzdCBmcm9tIGEgdGhl b3JldGljYWwgcGVyc3BlY3RpdmUpIHRoZSBpbnRlZ3JpdHkgYW5kIGNvbmZpZGVudGlhbGl0eQ0K b2YgdGhlIGRhdGEgcGxhbmUgY2Fubm90IGJlIHRydXN0ZWQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj4qIERUTFMgZW5jcnlwdGlvbiBpcyBhbHNvIHdhc3RlZnVsOiBlbmNyeXB0ZWQg ODAyLjExIGRhdGEgZnJhbWVzIGNvbWUgaW4gb3ZlciB0aGUgYWlyLCBhcmUgdW5lbmNyeXB0ZWQg aW4gdGhlIFdUUCBhbmQgdGhlbiBlbmNyeXB0ZWQgYWdhaW4gd2l0aCBEVExTLjwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+KiBEVExTIGFsc28gcHJvdmlkZXMgYXV0aGVudGljYXRpb24s IGJ1dCB0byBtZSBpdCBtYWtlcyBsaXR0bGUgc2Vuc2UgdG8gYXV0aGVudGljYXRlIGFuIHVudHJ1 c3RlZCBwYXJ0eS4gSWYgdGhlIFdUUCBjYW4gYmUgdW5kZXIgdGhlIHBoeXNpY2FsIGNvbnRyb2wg b2YgYW4gYXR0YWNrZXIsIHRoZW4gdGhlcmUgaXMgbm8gcG9pbnQgaW4gYXV0aGVudGljYXRpbmcg aXQgYWdhaW5zdCBhIGRpZ2l0YWwgY2VydGlmaWNhdGUgc3RvcmVkIGluIHRoZQ0KV1RQLjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SU1ITyBlbmNyeXB0aW5nIHRoZSBDQVBXQVAtRGF0 YSBjaGFubmVsIHdpdGggRFRMUyBhbmQgYXV0aGVudGljYXRpbmcgdGhlIFdUUCBpcyBib3JkZXJs aW5lICZxdW90O3NlY3VyaXR5IGJ5IG9ic2N1cml0eSZxdW90OyBpbiB0aGF0IGl0IHJlbGllcyBv biBhbiBhdHRhY2tlciBub3QgYmVpbmcgYWJsZSB0byBnYWluIGFjY2VzcyB0byBXVFAgbWVtb3J5 LiBUaGlzIGFzc3VtcHRpb24gbWF5IGhhdmUgYmVlbiByZWxhdGl2ZWx5IHRydWUgaW4gdGhlIGNv cnBvcmF0ZQ0KV0xBTiBlbnZpcm9ubWVudCB0aGF0IENBUFdBUCB3YXMgZGVzaWduZWQgZm9yLCBi dXQgaXQncyBsZXNzIGFuZCBsZXNzIHRydWUgZm9yIGNhcnJpZXIgV2ktRmkgZGVwbG95bWVudHMu PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5XaGVuIG9uIHRoZSBvdGhlciBoYW5kIHRo ZSA4MDIuMTEgZW5jcnlwdGlvbiBpcyByZWxpZWQgdXBvbiB0byBwcm90ZWN0IHRoZSB1c2VyIGRh dGEgcGxhbmUgdGhlIFdUUCBpcyBzaW1wbHkgZXhjbHVkZWQgZnJvbSB0aGUgc2VjdXJpdHk8L2Rp dj4NCjxkaXY+ZXF1YXRpb246IEV2ZW4gYW4gYXR0YWNrZXIgaW4gY29tcGxldGUgY29udHJvbCBv ZiB0aGUgV1RQIGlzIG5vIHRocmVhdCB0byB0aGUgaW50ZWdyaXR5IG9yIGNvbmZpZGVudGlhbGl0 eSBvZiB0aGUgdXNlciBkYXRhIHBsYW5lIChzaW5jZSB0aGV5IGhhdmUgYWNjZXNzIHRvIG5vdGhp bmcgbW9yZSB0aGFuIHRoZSBlbmNyeXB0ZWQgODAyLjExIGZyYW1lcyB3aGljaCBhcmUgYWxzbyBh dmFpbGFibGUgZnJvbSB0aGUgYWlyKS4gVGhhdCBhbHNvDQptZWFucyB0aGVyZSdzIG5vIHJlYWwg bmVlZCB0byBhdXRoZW50aWNhdGUgdGhlIFdUUCwgYW5kIHRoZSBzZWN1cml0eSBtb2RlbCBpcyBn cmVhdGx5IHNpbXBsaWZpZWQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7ICZn dDsgQS4gVGhlIHByb3RvY29sIHNob3VsZCBtYW5kYXRlIGEgc2luZ2xlIHdlbGwtZGVmaW5lZCBw YXJ0aXRpb25pbmcgb2YgPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyB0aGUgSUVFRSA4MDIuMTEgc3Rh Y2ssIHdpdGggODAyLjFYIGF1dGhlbnRpY2F0aW9uLCBrZXkgbWFuYWdlbWVudCA8L2Rpdj4NCjxk aXY+Jmd0OyAmZ3Q7IGFuZCBlbmNyeXB0aW9uIGFsbCBpbXBsZW1lbnRlZCBhdCB0aGUgdHVubmVs IHRlcm1pbmF0aW9uIHBvaW50IGZvciBzZWN1cml0eSByZWFzb25zLjwvZGl2Pg0KPGRpdj4mZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsgQnkgdGhpcyBJIGFtIGFzc3VtaW5nIHRoYXQgeW91IHdhbnQgZW5j cnlwdGlvbiBhdCB0aGUgVHVubmVsIDwvZGl2Pg0KPGRpdj4mZ3Q7IHRlcm1pbmF0aW9uIHBvaW50 IHJhdGhlciB0aGFuIHRoZSBBUC4gV2hhdCBpcyBtb3RpdmF0aW5nIHRoaXMsIGdpdmVuIDwvZGl2 Pg0KPGRpdj4mZ3Q7IHRoYXQgYWxsIEFQcyAodGhhdCBJIGtub3cgb2YpIGltcGxlbWVudCA4MDIu MTEgZW5jcnlwdGlvbiBhbmQgaWYgPC9kaXY+DQo8ZGl2PiZndDsgc2VjdXJpdHkgaXMgbmVlZGVk IGJldHdlZW4gQVAgYW5kIFR1bm5lbCB0ZXJtaW5hdGlvbiBwb2ludCB0aGVuIG9uZSBjb3VsZCB1 c2UgSVBTRUMgb3IgRFRMUy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlllcywgaWYg cGllY2V3aXNlIHNlY3VyaXR5IGlzIHN1ZmZpY2llbnQgdGhlbiB0aGVyZSBhcmUgYSBtdWx0aXR1 ZGUgb2YgSUVURiBwcm90b2NvbHMgdG8gY2hvc2UgZnJvbS4gQnV0IGlmIGVuZC10by1lbmQgODAy LjExIGVuY3J5cHRpb24gYWxsIHRoZSB3YXkgZnJvbSB0aGUgbW9iaWxlIFNUQSB0byBhIHRydXN0 ZWQgbG9jYXRpb24gKGUuZy4gYSBzZXJ2aWNlL2FjY2VzcyByb3V0ZXIgaW4gdGhlIG5ldHdvcmsg Y29yZSkgaXMgZGVzaXJlZA0KdGhlbiB0aGVyZSBpcyBub3RoaW5nIGluIHRoZSBJRVRGIHBsYXli b29rIGV4Y2VwdCBhIGJvcmRlciBjYXNlIG9mIENBUFdBUCwgd2hpY2ggY29tZXMgd2l0aCBhbiBl bnRhbmdsZWQgY29udHJvbCBhbmQgcHJvdmlzaW9uaW5nL21hbmFnZW1lbnQgcGxhbmUuPC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj5CasO2cm48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+Jmd0OyBGcm9tOiBPUFNBV0cg WzxhIGhyZWY9Im1haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9wc2F3Zy1i b3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEJqw7ZybiA8L2Rpdj4NCjxkaXY+Jmd0 OyBTbWVkbWFuPC9kaXY+DQo8ZGl2PiZndDsgU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAx NCAyOjU3IFBNPC9kaXY+DQo8ZGl2PiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0 Zi5vcmciPm9wc2F3Z0BpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+Jmd0OyBTdWJqZWN0OiBbT1BT QVdHXSBTaW1wbGlmaWVkIEFsdGVybmF0aXZlIHRvIENBUFdBUDwvZGl2Pg0KPGRpdj4mZ3Q7PC9k aXY+DQo8ZGl2PiZndDsgRGVhciBhbGwsPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyBJJ3ZlIGJlZW4gZm9sbG93aW5nIHRoZSByZWNlbnQgQ0FQV0FQIGFjdGl2aXR5IG9uIHRoaXMg bGlzdCBhbmQgPC9kaXY+DQo8ZGl2PiZndDsgdGhvdWdodCBJIHNob3VsZCBzaGFyZSBzb21lIGdl bmVyYWwgdGhvdWdodHMgb24gdGhlIHByb3RvY29sLCBhbmQgc2VlIDwvZGl2Pg0KPGRpdj4mZ3Q7 IGlmIHRoZXJlJ3MgaW50ZXJlc3QgaW4gYSBicm9hZGVyIGFwcHJvYWNoLjwvZGl2Pg0KPGRpdj4m Z3Q7PC9kaXY+DQo8ZGl2PiZndDsgVGhlIENBUFdBUCBzaG9ydGNvbWluZ3MgZGlzY3Vzc2VkIGFy ZSBzaW1pbGFyIHRvIHRoZSBwcm9ibGVtcyA8L2Rpdj4NCjxkaXY+Jmd0OyBwcmV2ZW50aW5nIHVz IFsxXSBmcm9tIHVzaW5nIGl0IGluIG91ciBTb2Z0d2FyZS1EZWZpbmVkIE5ldHdvcmtpbmc8L2Rp dj4NCjxkaXY+Jmd0OyAoU0ROKSBhcmNoaXRlY3R1cmUgZm9yIElFRUUgODAyLjExIFsyXTo8L2Rp dj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IDEuIENBUFdBUCB3YXMgc3BlY2lmaWVkIGJl Zm9yZSBzZXBhcmF0aW9uIG9mIGRhdGEsIGNvbnRyb2wgYW5kIDwvZGl2Pg0KPGRpdj4mZ3Q7IG1h bmFnZW1lbnQgcGxhbmVzIGJlY2FtZSB0aGUgbm9ybSBpbiBuZXR3b3JraW5nIGFyY2hpdGVjdHVy ZS48L2Rpdj4NCjxkaXY+Jmd0OyBVbnN1cnByaXNpbmdseSBpdCBwcm92aWRlcyB2ZXJ5IGxpdHRs ZSBzZXBhcmF0aW9uIG9mIGNvbmNlcm4sIDwvZGl2Pg0KPGRpdj4mZ3Q7IGNvbmZsYXRpbmcgZXZl cnl0aGluZyBmcm9tIGZpcm13YXJlIHVwZGF0ZXMgdG8gY29uZmlndXJhdGlvbiBvZiBhbiBleHRy YSBTU0lELjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgMi4gQ0FQV0FQIGF0dGVt cHRzIHRvIHByb3ZpZGUgcHJvdmlzaW9uaW5nL21hbmFnZW1lbnQgZnVuY3Rpb25hbGl0eSA8L2Rp dj4NCjxkaXY+Jmd0OyB0aGF0IG92ZXJsYXBzIHdpdGggb3RoZXIgSUVURiBzdGFuZGFyZHMgdHJh Y2sgcHJvdG9jb2xzLCBlLmcuIFNOTVAgYW5kIDwvZGl2Pg0KPGRpdj4mZ3Q7IE5FVENPTkYvWUFO RywgYXMgd2VsbCBhcyBvdGhlciBlc3RhYmxpc2hlZCBtYW5hZ2VtZW50IHByb3RvY29scyBzdWNo IDwvZGl2Pg0KPGRpdj4mZ3Q7IGFzIFRSLTA2OS48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRp dj4mZ3Q7IDMuIFRoZSBzZXBhcmF0aW9uIG9mIGRhdGEgYW5kIGNvbnRyb2wgcGxhbmVzIHRoYXQg Q0FQV0FQIGRvZXMgcHJvdmlkZSA8L2Rpdj4NCjxkaXY+Jmd0OyBpcyBJTUhPIGluY29ycmVjdDog ODAyLjFYIGtleSBleGNoYW5nZSBpcyBjb25zaWRlcmVkIHBhcnQgb2YgdGhlIDwvZGl2Pg0KPGRp dj4mZ3Q7IGNvbnRyb2wgcGxhbmUgYnV0IHRoZSBkZXJpdmVkIGVuY3J5cHRpb24ga2V5cyBwcm90 ZWN0IHRoZSBkYXRhIHBsYW5lLjwvZGl2Pg0KPGRpdj4mZ3Q7IFRoaXMgZG9lc24ndCBtYXR0ZXIg d2hlbiBib3RoIGNvbnRyb2wgYW5kIGRhdGEgcGxhbmUgdGVybWluYXRlIGluIHRoZSA8L2Rpdj4N CjxkaXY+Jmd0OyBzYW1lIGxvY2F0aW9uICh0aGUgQUMpLCBidXQgYmVjb21lcyBhIHByb2JsZW0g d2hlbiB0aGV5IGFyZSBzZXBhcmF0ZWQgPC9kaXY+DQo8ZGl2PiZndDsgKGVuY3J5cHRpb24ga2V5 cyBlbmQgdXAgaW4gYSBkaWZmZXJlbnQgcGxhY2UgdGhhbiB0aGUgZW5jcnlwdGVkIGRhdGEhKS48 L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IDQuIENBUFdBUCBsZWF2ZXMgbWFueSBv cHRpb25zIG9wZW4gdG8gdGhlIGltcGxlbWVudGVyIGFuZCBpcyB0aGVyZWZvcmUgPC9kaXY+DQo8 ZGl2PiZndDsgbGVzcyBpbnRlcm9wZXJhYmxlIHRoYW4gZGVzaXJlZC4gVG8gc29tZSBleHRlbnQg dGhpcyBjYW4gYmUgc29sdmVkIDwvZGl2Pg0KPGRpdj4mZ3Q7IHdpdGggcnVuLXRpbWUgbmVnb3Rp YXRpb24sIGJ1dCBzdWNoIG5lZ290aWF0aW9uIG9mIHNlY3VyaXR5IGNyaXRpY2FsIDwvZGl2Pg0K PGRpdj4mZ3Q7IGFzcGVjdHMgKHN1Y2ggYXMgd2hlcmUgZW5jcnlwdGlvbiBrZXlzIGFyZSBkZXJp dmVkIGFuZCBrZXB0KSBtYWtlcyBpdCA8L2Rpdj4NCjxkaXY+Jmd0OyBpbXBvc3NpYmxlIHRvIHJl YXNvbiBhYm91dCB0aGUgc2VjdXJpdHkgb2YgdGhlIHN5c3RlbS4gVGhpcyBpcyBsZXNzIHRoYW4g aWRlYWwgSU1ITy48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IDUuIENBUFdBUCAo cGFydGx5IGR1ZSB0byAxIGFuZCAyIGFib3ZlKSBkZXBlbmRzIGV4Y2Vzc2l2ZWx5IG9uIGRldGFp bHMgPC9kaXY+DQo8ZGl2PiZndDsgaW4gdGhlIElFRUUgODAyLjExIHN0YW5kYXJkLCB3aXRoIGVh Y2ggYW1lbmRtZW50IHRocmVhdGVuaW5nIHRvIGltcGFjdCA8L2Rpdj4NCjxkaXY+Jmd0OyB0aGUg cHJvdG9jb2wuPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4m Z3Q7IFdlIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gc3BlY2lmeWluZyBhIHNpbXBsaWZpZWQgdHVu bmVsaW5nIHByb3RvY29sIDwvZGl2Pg0KPGRpdj4mZ3Q7IGZvciBJRUVFIDgwMi4xMSBzaW1pbGFy IHRvIEdlbmV2ZSBbM10sIGF2b2lkaW5nIHRoZSBhYm92ZSBwcm9ibGVtczo8L2Rpdj4NCjxkaXY+ Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IEEuIFRoZSBwcm90b2NvbCBzaG91bGQgbWFuZGF0ZSBhIHNp bmdsZSB3ZWxsLWRlZmluZWQgcGFydGl0aW9uaW5nIG9mIDwvZGl2Pg0KPGRpdj4mZ3Q7IHRoZSBJ RUVFIDgwMi4xMSBzdGFjaywgd2l0aCA4MDIuMVggYXV0aGVudGljYXRpb24sIGtleSBtYW5hZ2Vt ZW50IGFuZCA8L2Rpdj4NCjxkaXY+Jmd0OyBlbmNyeXB0aW9uIGFsbCBpbXBsZW1lbnRlZCBhdCB0 aGUgdHVubmVsIHRlcm1pbmF0aW9uIHBvaW50IGZvciBzZWN1cml0eSByZWFzb25zLjwvZGl2Pg0K PGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgQi4gVGhlIHByb3RvY29sIHNob3VsZCBtYW5kYXRl IGEgc2luZ2xlIHdlbGwtZGVmaW5lZCBmcmFtZSBmb3JtYXQgPC9kaXY+DQo8ZGl2PiZndDsgcmVs eWluZyBvbmx5IG9uIGEgUEhZLWluZGVwZW5kZW50IHN0YWJsZSBzdWJzZXQgb2YgSUVFRSA4MDIu MTEsIDwvZGl2Pg0KPGRpdj4mZ3Q7IGVuc3VyaW5nIGNvbXBhdGliaWxpdHkgd2l0aCAxMW4vYWMg YW5kIChtb3N0IGxpa2VseSkgYmV5b25kLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZn dDsgQy4gTGlrZSBHZW5ldmUgdGhlIHByb3RvY29sIHNob3VsZCBub3QgcHJvdmlkZSBhbnkgPC9k aXY+DQo8ZGl2PiZndDsgcHJvdmlzaW9uaW5nL21hbmFnZW1lbnQgZnVuY3Rpb25hbGl0eSwgaW5z dGVhZCByZWx5aW5nIG9uIFNOTVAsIE5FVENPTkYvWUFORywgVFItMDY5IGFuZCBzaW1pbGFyLjwv ZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgRC4gTGlrZSBHZW5ldmUgdGhlIHByb3Rv Y29sIHNob3VsZCBub3QgcHJvdmlkZSBhbnkgY29udHJvbCBwbGFuZSA8L2Rpdj4NCjxkaXY+Jmd0 OyBmdW5jdGlvbmFsaXR5LCBpbnN0ZWFkIHJlbWFpbmluZyBjb21wYXRpYmxlIHdpdGggc2V2ZXJh bCA8L2Rpdj4NCjxkaXY+Jmd0OyBTb2Z0d2FyZS1EZWZpbmVkIE5ldHdvcmtpbmcgKFNETikgcHJv dG9jb2xzIGZvciBJRUVFIDgwMi4xMS48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 IEUuIEVhY2ggdmlydHVhbCBhY2Nlc3MgcG9pbnQgaW4gYSBtdWx0aS1CU1NJRCAoYW5kL29yIG11 bHRpLXJhZGlvKSA8L2Rpdj4NCjxkaXY+Jmd0OyBhY2Nlc3MgcG9pbnQgc2hvdWxkIGJlIHRyZWF0 ZWQgYXMgYSBzZXBhcmF0ZSBlbnRpdHkgYXNzb2NpYXRlZCB3aXRoIGEgPC9kaXY+DQo8ZGl2PiZn dDsgc2VwYXJhdGUgdHVubmVsLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDs8L2Rp dj4NCjxkaXY+Jmd0OyBXZSBzZWUgc3Ryb25nIGJlbmVmaXRzIHRvIHN1Y2ggYSBwcm90b2NvbCBm cm9tIGFuIGV4dGVuc2liaWxpdHkgWzRdLCA8L2Rpdj4NCjxkaXY+Jmd0OyBmbGV4aWJpbGl0eSBb NV0gYW5kIHNlY3VyaXR5IFs2XSBwZXJzcGVjdGl2ZS4gSWYgdGhlcmUgaXMgaW50ZXJlc3QgaW4g PC9kaXY+DQo8ZGl2PiZndDsgZXhwbG9yaW5nIHRoaXMgZnVydGhlciBwbGVhc2UgbGV0IG1lIGtu b3cuPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBCZXN0IHJlZ2FyZHMsPC9kaXY+ DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBCasO2cm4gU21lZG1hbjwvZGl2Pg0KPGRpdj4m Z3Q7PC9kaXY+DQo8ZGl2PiZndDsgMS4gPGEgaHJlZj0iaHR0cDovL3d3dy5hbnlmaW5ldHdvcmtz LmNvbSI+aHR0cDovL3d3dy5hbnlmaW5ldHdvcmtzLmNvbTwvYT48L2Rpdj4NCjxkaXY+Jmd0Ozwv ZGl2Pg0KPGRpdj4mZ3Q7IDIuIDxhIGhyZWY9Imh0dHA6Ly9hbnlmaS5uZXQiPmh0dHA6Ly9hbnlm aS5uZXQ8L2E+IGFuZCA8YSBocmVmPSJodHRwOi8vd3d3LmFueWZpbmV0d29ya3MuY29tL3Byb2R1 Y3RzIj5odHRwOi8vd3d3LmFueWZpbmV0d29ya3MuY29tL3Byb2R1Y3RzPC9hPjwvZGl2Pg0KPGRp dj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgMy4gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZ3Jvc3MtZ2VuZXZlLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1ncm9zcy1nZW5ldmUtMDA8L2E+PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyA0LiA8YSBocmVmPSJodHRwOi8vYW55ZmkubmV0L2RvY3VtZW50YXRpb24jYXJjaGl0ZWN0dXJl Ij5odHRwOi8vYW55ZmkubmV0L2RvY3VtZW50YXRpb24jYXJjaGl0ZWN0dXJlPC9hPjwvZGl2Pg0K PGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgNS4gPGEgaHJlZj0iaHR0cDovL2FueWZpLm5ldC9k b2N1bWVudGF0aW9uI2FfaG93X2l0X2FsbF9maXRzX3RvZ2V0aGVyIj5odHRwOi8vYW55ZmkubmV0 L2RvY3VtZW50YXRpb24jYV9ob3dfaXRfYWxsX2ZpdHNfdG9nZXRoZXI8L2E+PC9kaXY+DQo8ZGl2 PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyA2LiA8YSBocmVmPSJodHRwOi8vYW55ZmkubmV0L2RvY3Vt ZW50YXRpb24jaV9zZWN1cml0eV9tb2RlbCI+aHR0cDovL2FueWZpLm5ldC9kb2N1bWVudGF0aW9u I2lfc2VjdXJpdHlfbW9kZWw8L2E+PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZGl2Pg0KPGRp dj4mZ3Q7IE9QU0FXRyBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+Jmd0OyA8YSBocmVmPSJtYWls dG86T1BTQVdHQGlldGYub3JnIj5PUFNBV0dAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2ciPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnPC9hPjwvZGl2Pg0KPGRp dj4mZ3Q7PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m b250PjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4ED2E36A22261145861BAB2C24088B4320F5D8F1xmbalnx09ciscoc_-- From nobody Tue Feb 25 00:27:32 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 9C9EE1A0444 for ; Tue, 25 Feb 2014 00:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 4gOIphtkPSdV for ; Tue, 25 Feb 2014 00:27:27 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 78DFF1A032B for ; Tue, 25 Feb 2014 00:27:27 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id cm18so52095qab.23 for ; Tue, 25 Feb 2014 00:27:26 -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=cd6+uSeYl3sXE7wlLP4FmecBWDq66C425vvqZ/IdGUQ=; b=w7q4t2pssQJKFtiqd7r6utC9wcOF2aqaRelBM/js4mYjR2FdXnq5xU22XercEnSlwG fkz0m47GegFFqjscZM3B9opKHe4WesuWPYnV1Q7QhLxw49sS5AmP/AXUF/PMgy2mytzb UITXu+VrpkdF7X4UiKHPcYaXESSzV2YQWoy92w7ThucnqxgSoZmqCekEInaMYK/dy4b4 mN4amN5uKqo8q1AEFaSuZ4Qt75kb2j5LyY0F8S0srWWy0/8lg0HUTd+dzIX1AzLa7bcr rX8Up0jKwPiA65dm6hjrzC2Dzbz6LUc8FQgRWBxn9WepUlEJPemL9FiIpH27e+v0njaZ Ru0g== MIME-Version: 1.0 X-Received: by 10.140.91.12 with SMTP id y12mr34043970qgd.26.1393316844965; Tue, 25 Feb 2014 00:27:24 -0800 (PST) Received: by 10.96.58.106 with HTTP; Tue, 25 Feb 2014 00:27:24 -0800 (PST) In-Reply-To: References: <4ED2E36A22261145861BAB2C24088B4320F5D75F@xmb-aln-x09.cisco.com> Date: Tue, 25 Feb 2014 16:27:24 +0800 Message-ID: From: "Cao,Zhen" To: =?ISO-8859-1?Q?Bj=F6rn_Smedman?= Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/x7dtFOXMTqGGQlQQFoHrA13Z8Y4 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP 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, 25 Feb 2014 08:27:28 -0000 Hello, Bjorn, Appreciate your analysis. > True, in CAPWAP it's a border case that 802.1X key exchange and 802.11 > encryption protects the user data plane all the way from the mobile > STA to the AC. But I think there are strong reasons to make this the > default: But I do not agree here. The 802.11 key only protect the data from STA to WTP, NOT the AC, both in local MAC and also one option in the split model. http://tools.ietf.org/html/rfc5416#section-2.2.2 -Zhen From nobody Tue Feb 25 05:22: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 3C70F1A06EF for ; Tue, 25 Feb 2014 05:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.622 X-Spam-Level: * X-Spam-Status: No, score=1.622 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 uXwaQ_Fx8cnp for ; Tue, 25 Feb 2014 05:22:38 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id D5C3B1A06F0 for ; Tue, 25 Feb 2014 05:22:37 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n16so345663oag.27 for ; Tue, 25 Feb 2014 05:22:37 -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 :content-transfer-encoding; bh=zMtY6C1H3ylBHA+IQ41FZ7MWau+Xn/MYaLoG//qq3fQ=; b=Ev3VAeVlJ8YkhecQGcEiNcPI7sdYPRNY1RM5Sg6NqNImgaZUitALkDutnM7gOA1wNg OKun+wHZf+eZfPrqfvJ+XSKMe5e2x68X4Q2d47fPjWdI6mtn1ufDUeoKn3TNHlBAuXDy jGqx1thZ/JJ1OsarmDej2Lizhu60IcEfgttB5Q06mNiVlW3f0pPA28KJZMz44x91sp/Y XDRwiEKAO6L7pqdPxRtmzWWr2TebfjQm1Rf40LjFhe7/cGa5w0tZCZcbkD9xATGelMtc F3r9w0el1Pj8M1OVbcRPLg12F/68idu5q5Ep/M2Z7cqLZ08XkG+3m8I5Epfb9ZRWlKwM dtXQ== X-Gm-Message-State: ALoCoQmo7/2qEc2+c6lZS+jSecnBMNBiyVyhgOqx56vOmo2EVejkzXDGyj8AEBp2+T50iFzjdGQG MIME-Version: 1.0 X-Received: by 10.182.55.65 with SMTP id q1mr827329obp.70.1393334556898; Tue, 25 Feb 2014 05:22:36 -0800 (PST) Received: by 10.182.191.9 with HTTP; Tue, 25 Feb 2014 05:22:36 -0800 (PST) X-Originating-IP: [82.99.7.230] In-Reply-To: References: <4ED2E36A22261145861BAB2C24088B4320F5D75F@xmb-aln-x09.cisco.com> Date: Tue, 25 Feb 2014 14:22:36 +0100 Message-ID: From: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= To: "Cao,Zhen" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/I4kuRWEjOmMyc7u6D_8l3UVWbpg Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP 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, 25 Feb 2014 13:22:40 -0000 Hi Zhen, On Tue, Feb 25, 2014 at 9:27 AM, Cao,Zhen wrote: > Appreciate your analysis. Thanks, likewise. >> True, in CAPWAP it's a border case that 802.1X key exchange and 802.11 >> encryption protects the user data plane all the way from the mobile >> STA to the AC. But I think there are strong reasons to make this the >> default: > > But I do not agree here. The 802.11 key only protect the data from STA > to WTP, NOT the AC, both in local MAC and also one option in the split > model. http://tools.ietf.org/html/rfc5416#section-2.2.2 I share your understanding that in the CAPWAP Local MAC mode, and most implementations of Split MAC, the 802.11 key only protects user data between STA and WTP. But what I'm saying is that this is unfortunate. In the corporate WLAN environment for which CAPWAP was originally designed there is an assumption that WTPs and the Distribution System (DS) are physically protected, by doors, badges and security personnel. If somebody gets through those protections and can access the WTP or DS then there are other things to worry about. But in a carrier Wi-Fi environment this assumption no-longer holds true. WTPs are installed in coffee shops, restaurants, stadiums and even fixed-line subscriber homes (as a "second SSID" on a residential gateway). There is ample opportunity for an attacker to go to work on a WTP, perhaps even in the privacy of their own home. If a single one of those WTPs is compromised (and CAPWAP mode is Local MAC or Split MAC with encryption in WTP) then there is no-longer any guarantee of user plane integrity or confidentiality for users of that WTP. But perhaps more alarmingly there is now also a gaping hole in the mutual authentication property of IEEE 802.11i, which means that all users of the wireless network are opened up to possible man-in-the-middle (MITM) attack [1]. If you combine this fact with automatic SIM authentication and global roaming the potential impact is significant. This is the reason we insist on always implementing both 802.11 encryption and 802.1X authentication at the tunnel termination point (e.g. an access router) in our SDWN architecture [2]. Unlike the WTP the tunnel termination point can often be physically protected. This provides strong guarantees of user data plane integrity and confidentiality, and also protects the mutual authentication property of the underlying IEEE 802.11i security mechanism. Best regards, Bj=C3=B6rn 1. This risk of MITM in a "secure" Wi-Fi network may not be entirely obvious. We explain this risk when an attacker has access to authentication credentials/interface here: http://anyfi.net/documentation#i_mutual_authentication. The same reasoning however holds true if the attacker can forward IEEE 802.11 frames between a targeted device and a CAPWAP AC, and get the 802.11 key from that AC (as in http://tools.ietf.org/html/rfc5416#section-6.15). 2. http://anyfi.net/documentation#a_data_plane From nobody Tue Feb 25 05:37:01 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 21E631A0431 for ; Tue, 25 Feb 2014 05:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] 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 s0_e5Gg_zsHJ for ; Tue, 25 Feb 2014 05:36:57 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id D23FC1A009E for ; Tue, 25 Feb 2014 05:36:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,540,1389736800"; d="scan'208";a="2597970" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 25 Feb 2014 15:36:54 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Tue, 25 Feb 2014 15:36:54 +0200 From: Edward Beili To: Melinda Shore , "Benoit Claise (bclaise@cisco.com)" , "Dan Romascanu (dromasca@avaya.com)" Date: Tue, 25 Feb 2014 15:36:53 +0200 Thread-Topic: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper (EFMCu) Interfaces MIB Thread-Index: Ac8vZ6FB1RYmov7rSeiQce/91ka4aQCxd6UA Message-ID: <4087887712E5C648B9F72BB9D912FD4602F6D3BB6CD4@il-mail07.actelis.net> References: <20140222003217.50B867FC392@rfc-editor.org> <5307F38D.1080908@gmail.com> In-Reply-To: <5307F38D.1080908@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/o-qjuC9G0tXXEbEuL0U9fnBXvVk Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper (EFMCu) Interfaces MIB 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, 25 Feb 2014 13:37:00 -0000 Dear Melinda, Benoit, Dan, the RFC editor and all reviewers, Thank you for your help and patience. Regards, -E. Edward Beili | Chief Architect & Network Technologist | w: +972-73-237-6852= | edward.beili@actelis.com | Actelis Networks | www.actelis.com -----Original Message----- From: Melinda Shore [mailto:melinda.shore@gmail.com]=20 Sent: Saturday, February 22, 2014 02:47 To: opsawg@ietf.org Cc: Edward Beili Subject: Fwd: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper (EFMCu= ) Interfaces MIB 5066bis has just been published. Many thanks to Ed, and to the reviewers w= ho put so much time into this. Melinda -------- Original Message -------- Subject: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper (EFMCu) Int= erfaces MIB Date: Fri, 21 Feb 2014 16:32:17 -0800 (PST) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, opsawg@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7124 Title: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB Author: E. Beili Status: Standards Track Stream: IETF Date: February 2014 Mailbox: edward.beili@actelis.com Pages: 6 Characters: 12123 Updates: RFC 5066 I-D Tag: draft-ietf-opsawg-rfc5066bis-07.txt URL: http://www.rfc-editor.org/rfc/rfc7124.txt This document updates RFC 5066. It amends that specification by informing = the Internet community about the transition of the EFM-CU-MIB module from t= he concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Inst= itute of Electrical and Electronics Engineers (IEEE) 802.3 working group. This document is a product of the Operations and Management Area Working Gr= oup Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protoc= ol for the Internet community,and requests discussion and suggestions for i= mprovements. Please refer to the current edition of the Internet Official = Protocol Standards (STD 1) for the standardization state and status of this= protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For down= loading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author = of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifical= ly noted otherwise on the RFC itself, all RFCs are for unlimited distributi= on. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Feb 25 06:24:27 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 164CC1A06D8 for ; Tue, 25 Feb 2014 06:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 fuDMN8RJwvQL for ; Tue, 25 Feb 2014 06:24:24 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id E3A141A037A for ; Tue, 25 Feb 2014 06:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2986; q=dns/txt; s=iport; t=1393338264; x=1394547864; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5EY+0SaJmtT1e+1QSTKUFFBwkcpn03An6iA2a5TgShk=; b=Y7rHbOlZrsmd9OSe693Lk5aBfwzkkkwnlKkZ0W2gGWp1WXsQ8jCE+jMQ Q6nKQl0O3VeedQ8QZwJLi+HDXw2bCJTtbFYzMYiyjxkLMW0MrCTn7BORX J8jRWs57N4MHaE76Ip5IaciRy4aW2acY5T5N0XIU7POPAGxqY51HtXiJC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAE2nDFOQ/khR/2dsb2JhbABZgwY7wVlPgRcWdIIlAQEBBAEBATUWIAoBDAQLEQMBAgEJAxMPCQMCAQIBFQoeCAYBDAEFAgEBBQsHAgSHZA3GXReOEVMHBoQyAQOYNIEyhRaGG4VEgW+BPzuBNQ X-IronPort-AV: E=Sophos;i="4.97,540,1389744000"; d="scan'208";a="6088691" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 25 Feb 2014 14:24:23 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1PEOLh3007559; Tue, 25 Feb 2014 14:24:22 GMT Message-ID: <530CA795.7050509@cisco.com> Date: Tue, 25 Feb 2014 15:24:21 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Melinda Shore , "opsawg@ietf.org" References: <20140222003217.50B867FC392@rfc-editor.org> <5307F38D.1080908@gmail.com> In-Reply-To: <5307F38D.1080908@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/pe-weUCJDf50C6qStQdUCd-ABVY Cc: Edward Beili Subject: Re: [OPSAWG] Fwd: RFC 7124 on Ethernet in the First Mile Copper (EFMCu) Interfaces MIB 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, 25 Feb 2014 14:24:26 -0000 On 22/02/2014 01:47, Melinda Shore wrote: > 5066bis has just been published. Many thanks to Ed, and > to the reviewers who put so much time into this. +1 Regards, Benoit > > Melinda > > > -------- Original Message -------- > Subject: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper (EFMCu) > Interfaces MIB > Date: Fri, 21 Feb 2014 16:32:17 -0800 (PST) > From: rfc-editor@rfc-editor.org > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > CC: drafts-update-ref@iana.org, opsawg@ietf.org, rfc-editor@rfc-editor.org > > A new Request for Comments is now available in online RFC libraries. > > > RFC 7124 > > Title: Ethernet in the First Mile > Copper (EFMCu) Interfaces MIB > Author: E. Beili > Status: Standards Track > Stream: IETF > Date: February 2014 > Mailbox: edward.beili@actelis.com > Pages: 6 > Characters: 12123 > Updates: RFC 5066 > > I-D Tag: draft-ietf-opsawg-rfc5066bis-07.txt > > URL: http://www.rfc-editor.org/rfc/rfc7124.txt > > This document updates RFC 5066. It amends that specification by > informing the Internet community about the transition of the > EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub > MIB Working Group to the Institute of Electrical and Electronics > Engineers (IEEE) 802.3 working group. > > This document is a product of the Operations and Management Area Working > Group Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/search > For downloading RFCs, see http://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > 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 nobody Tue Feb 25 06:25:58 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 D75641A073B for ; Tue, 25 Feb 2014 06:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 FbjnU14r-MaX for ; Tue, 25 Feb 2014 06:25:54 -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 61D3F1A0749 for ; Tue, 25 Feb 2014 06:25:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFANqmDFOHCzIm/2dsb2JhbABZgmUhO1eoWZgpT4EXFnSCJQEBAQECAQEBAQ8oDwUgCwUHBAIBCA0EAwEBAQsCEgkHIQYKARQJCAEBBAENBQgBCwcCBAGHTwMJCAEMm1WkDA2GcReMT4FCIjECBQaDHoEUBJZGAYMfhT6FcAOFRIFvgT6BcTk X-IronPort-AV: E=Sophos;i="4.97,540,1389762000"; d="scan'208";a="44207819" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Feb 2014 09:25:49 -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; 25 Feb 2014 09:12:38 -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.0174.001; Tue, 25 Feb 2014 15:25:46 +0100 From: "Romascanu, Dan (Dan)" To: Edward Beili , Melinda Shore , "Benoit Claise (bclaise@cisco.com)" Thread-Topic: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper (EFMCu) Interfaces MIB Thread-Index: Ac8vZ6FB1RYmov7rSeiQce/91ka4aQCxd6UAAAH5lFA= Date: Tue, 25 Feb 2014 14:25:45 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E438FDC@AZ-FFEXMB04.global.avaya.com> References: <20140222003217.50B867FC392@rfc-editor.org> <5307F38D.1080908@gmail.com> <4087887712E5C648B9F72BB9D912FD4602F6D3BB6CD4@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4602F6D3BB6CD4@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/lG4DMzYeerLXF_Fza6AeTIchS-0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper (EFMCu) Interfaces MIB 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, 25 Feb 2014 14:25:57 -0000 Thanks to you, Ed and congratulations for the publication! Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: Tuesday, February 25, 2014 3:37 PM > To: Melinda Shore; Benoit Claise (bclaise@cisco.com); Romascanu, Dan (Dan= ) > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper > (EFMCu) Interfaces MIB >=20 > Dear Melinda, Benoit, Dan, the RFC editor and all reviewers, Thank you fo= r > your help and patience. >=20 > Regards, > -E. >=20 > Edward Beili | Chief Architect & Network Technologist | w: +972-73-237- > 6852| edward.beili@actelis.com | Actelis Networks | www.actelis.com >=20 >=20 >=20 > -----Original Message----- > From: Melinda Shore [mailto:melinda.shore@gmail.com] > Sent: Saturday, February 22, 2014 02:47 > To: opsawg@ietf.org > Cc: Edward Beili > Subject: Fwd: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper > (EFMCu) Interfaces MIB >=20 > 5066bis has just been published. Many thanks to Ed, and to the reviewers > who put so much time into this. >=20 > Melinda >=20 >=20 > -------- Original Message -------- > Subject: [OPSAWG] RFC 7124 on Ethernet in the First Mile Copper (EFMCu) > Interfaces MIB > Date: Fri, 21 Feb 2014 16:32:17 -0800 (PST) > From: rfc-editor@rfc-editor.org > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > CC: drafts-update-ref@iana.org, opsawg@ietf.org, rfc-editor@rfc-editor.or= g >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7124 >=20 > Title: Ethernet in the First Mile > Copper (EFMCu) Interfaces MIB > Author: E. Beili > Status: Standards Track > Stream: IETF > Date: February 2014 > Mailbox: edward.beili@actelis.com > Pages: 6 > Characters: 12123 > Updates: RFC 5066 >=20 > I-D Tag: draft-ietf-opsawg-rfc5066bis-07.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc7124.txt >=20 > This document updates RFC 5066. It amends that specification by informin= g > the Internet community about the transition of the EFM-CU-MIB module > from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to > the Institute of Electrical and Electronics Engineers (IEEE) 802.3 workin= g > group. >=20 > This document is a product of the Operations and Management Area > Working Group Working Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions for improvements. Please refer to the current edition of the > Internet Official Protocol Standards (STD 1) for the standardization stat= e and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc-editor.org/search For > downloading RFCs, see http://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the autho= r of > the RFC in question, or to rfc-editor@rfc-editor.org. Unless specificall= y noted > otherwise on the RFC itself, all RFCs are for unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 From nobody Tue Feb 25 09:18: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 471DD1A01DB for ; Tue, 25 Feb 2014 09:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.747 X-Spam-Level: X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 e7nv2Z_GUj45 for ; Tue, 25 Feb 2014 09:18:20 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id D28C61A0111 for ; Tue, 25 Feb 2014 09:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16102; q=dns/txt; s=iport; t=1393348699; x=1394558299; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EGx1PLeRWJXsJeGUQxCAls0iCLgNlVKCkvpmUJ5uyXU=; b=eU7cbhOEsIr64Jk/WMzgNMqF3/gQulIAgmz1YFrbOAJv+kjEKUTKir8W Eqp05ZOjUi4dZEQYsIN+WF83imLKUIYwXFmuSlTkBFWHNXU4WESRMCZSL 1lLtIoQSRNtjjhviIcCc+1RWhiqqE4jOxWjYXoE/lW546h2pPg5nxI2hb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0GAFfPDFOtJXHB/2dsb2JhbABZgkJEO1eDA6g+jTiIWBiBABZ0giUBAQEDASMKOhIFBwQCAQgRAQMBAQEKHQMCAgIfERQDBggCBA4FCIdpAwkIDaZDmUkNhnEXjE+BZDEHBoJpNYEUBJZHgx+LLoVHgy2CKg X-IronPort-AV: E=Sophos; i="4.97,541,1389744000"; d="scan'208,217"; a="23063092" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-3.cisco.com with ESMTP; 25 Feb 2014 17:18:18 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1PHIIK9020297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 17:18:18 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.22]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 11:18:18 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: =?utf-8?B?QmrDtnJuIFNtZWRtYW4=?= , "Cao,Zhen" Thread-Topic: [OPSAWG] Simplified Alternative to CAPWAP Thread-Index: AQHPMbPgQtd3dWdjMUewmYg0xTSiXZrFGNzwgACBJoCAAG38AIAAUnsA///bPFA= Date: Tue, 25 Feb 2014 17:18:17 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F5E1E9@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320F5D75F@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.68.69] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F5E1E9xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/nS-qi8yuI2QzSuJyuU2lyZV8Lpw Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP 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, 25 Feb 2014 17:18:23 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F5E1E9xmbalnx09ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyB0aGUgcmVhc29uIHdlIGluc2lzdCBvbiBhbHdheXMgaW1wbGVtZW50aW5nIGJvdGgg ODAyLjExIGVuY3J5cHRpb24gYW5kIDgwMi4xWCBhdXRoZW50aWNhdGlvbiBhdCB0aGUgdHVubmVs IHRlcm1pbmF0aW9uIHBvaW50IChlLmcuIGFuIGFjY2VzcyByb3V0ZXIpIGluIG91ciBTRFdOIGFy Y2hpdGVjdHVyZSBbMl0uIFVubGlrZSB0aGUgV1RQIHRoZSB0dW5uZWwgdGVybWluYXRpb24gcG9p bnQgY2FuIG9mdGVuIGJlIHBoeXNpY2FsbHkgcHJvdGVjdGVkLiBUaGlzIHByb3ZpZGVzIHN0cm9u ZyBndWFyYW50ZWVzIG9mIHVzZXIgZGF0YSBwbGFuZSBpbnRlZ3JpdHkgYW5kIGNvbmZpZGVudGlh bGl0eSwgYW5kIGFsc28gcHJvdGVjdHMgdGhlIG11dHVhbCBhdXRoZW50aWNhdGlvbiBwcm9wZXJ0 eSBvZiB0aGUgdW5kZXJseWluZyBJRUVFIDgwMi4xMWkgc2VjdXJpdHkgbWVjaGFuaXNtLg0KDQo+ ICBJIHRoaW5rIEkgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSBldmVuIGJldHRlciBub3cgOikgLiBJ dCBhcHBlYXJzIHRoYXQgdGhlIGRyYWZ0IEFsdGVybmF0ZSBUdW5uZWwgRW5jYXBzdWxhdGlvbiBm b3IgRGF0YSBGcmFtZXMgaW4gQ0FQV0FQIiwgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC16aGFuZy1vcHNhd2ctY2Fwd2FwLWNkcy8gIHdvdWxkIG1lZXQgdGhlIHJlcXVpcmVt ZW50IHRvIHR1bm5lbCBkYXRhIHRyYWZmaWMgdG8gZGlmZmVyZW50IHR1bm5lbCBlbmQgcG9pbnQu IFlvdSB3b3VsZCBzZXQgdGhlIE1BQyBtb2RlIHRvIHNwbGl0IG1hYyBhbmQgdHVubmVsIG1vZGUg dG8gODAyLjExLiBUaGUgb25seSBtaXNzaW5nIHBpZWNlIHdvdWxkIGJlIHRvIHNwZWNpZnkgdGhl IHRoYXQgODAyLjExIGZyYW1lIGVuY3J5cHRpb24gc2hvdWxkIGhhcHBlbiBhdCB0aGUgdHVubmVs IHRlcm1pbmF0aW9uIHBvaW50IGFuZCBub3QgdGhlIFdUUC4gIFRoZXJlIGlzIG5vIGN1cnJlbnQg d2F5IHRvIG5lZ290aWF0ZSB0aGF0LiBOb3RlIHRoYXQgd2UgYXJlIHNvbHZpbmcgYSBzaW1pbGFy IHByb2JsZW0gKGluIHRoZSBjb250ZXh0IHdoZXJlIEFDIGlzIHRoZSB0dW5uZWwgdGVybWluYXRp b24gcG9pbnQpIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWNh cHdhcC1oeWJyaWRtYWMtMDIuDQpTbyBwb3RlbnRpYWxseSBhIG5ldyBzcGxpdCBNQUMgcHJvZmls ZSBpbiB0aGUgY2FzZSB0aGUgdHVubmVsIHRlcm1pbmF0aW9uIGlzIG5vdCBhdCB0aGUgQUMuDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCasO2cm4gU21lZG1hbiBbbWFpbHRv OmJqb3JuLnNtZWRtYW5AYW55ZmluZXR3b3Jrcy5jb21dDQpTZW50OiBUdWVzZGF5LCBGZWJydWFy eSAyNSwgMjAxNCA1OjIzIEFNDQpUbzogQ2FvLFpoZW4NCkNjOiBSYWplc2ggUGF6aHlhbm51ciAo cnBhemh5YW4pOyBvcHNhd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT1BTQVdHXSBTaW1wbGlm aWVkIEFsdGVybmF0aXZlIHRvIENBUFdBUA0KDQpIaSBaaGVuLA0KDQpPbiBUdWUsIEZlYiAyNSwg MjAxNCBhdCA5OjI3IEFNLCBDYW8sWmhlbiA8emVobi5jYW9AZ21haWwuY29tPG1haWx0bzp6ZWhu LmNhb0BnbWFpbC5jb20+PiB3cm90ZToNCj4gQXBwcmVjaWF0ZSB5b3VyIGFuYWx5c2lzLg0KDQpU aGFua3MsIGxpa2V3aXNlLg0KDQo+PiBUcnVlLCBpbiBDQVBXQVAgaXQncyBhIGJvcmRlciBjYXNl IHRoYXQgODAyLjFYIGtleSBleGNoYW5nZSBhbmQNCj4+IDgwMi4xMSBlbmNyeXB0aW9uIHByb3Rl Y3RzIHRoZSB1c2VyIGRhdGEgcGxhbmUgYWxsIHRoZSB3YXkgZnJvbSB0aGUNCj4+IG1vYmlsZSBT VEEgdG8gdGhlIEFDLiBCdXQgSSB0aGluayB0aGVyZSBhcmUgc3Ryb25nIHJlYXNvbnMgdG8gbWFr ZQ0KPj4gdGhpcyB0aGUNCj4+IGRlZmF1bHQ6DQo+DQo+IEJ1dCBJIGRvIG5vdCBhZ3JlZSBoZXJl LiBUaGUgODAyLjExIGtleSBvbmx5IHByb3RlY3QgdGhlIGRhdGEgZnJvbSBTVEENCj4gdG8gV1RQ LCBOT1QgdGhlIEFDLCBib3RoIGluIGxvY2FsIE1BQyBhbmQgYWxzbyBvbmUgb3B0aW9uIGluIHRo ZSBzcGxpdA0KPiBtb2RlbC4gIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU0MTYjc2Vj dGlvbi0yLjIuMg0KDQpJIHNoYXJlIHlvdXIgdW5kZXJzdGFuZGluZyB0aGF0IGluIHRoZSBDQVBX QVAgTG9jYWwgTUFDIG1vZGUsIGFuZCBtb3N0IGltcGxlbWVudGF0aW9ucyBvZiBTcGxpdCBNQUMs IHRoZSA4MDIuMTEga2V5IG9ubHkgcHJvdGVjdHMgdXNlciBkYXRhIGJldHdlZW4gU1RBIGFuZCBX VFAuIEJ1dCB3aGF0IEknbSBzYXlpbmcgaXMgdGhhdCB0aGlzIGlzIHVuZm9ydHVuYXRlLg0KDQpJ biB0aGUgY29ycG9yYXRlIFdMQU4gZW52aXJvbm1lbnQgZm9yIHdoaWNoIENBUFdBUCB3YXMgb3Jp Z2luYWxseSBkZXNpZ25lZCB0aGVyZSBpcyBhbiBhc3N1bXB0aW9uIHRoYXQgV1RQcyBhbmQgdGhl IERpc3RyaWJ1dGlvbiBTeXN0ZW0NCihEUykgYXJlIHBoeXNpY2FsbHkgcHJvdGVjdGVkLCBieSBk b29ycywgYmFkZ2VzIGFuZCBzZWN1cml0eSBwZXJzb25uZWwuIElmIHNvbWVib2R5IGdldHMgdGhy b3VnaCB0aG9zZSBwcm90ZWN0aW9ucyBhbmQgY2FuIGFjY2VzcyB0aGUgV1RQIG9yIERTIHRoZW4g dGhlcmUgYXJlIG90aGVyIHRoaW5ncyB0byB3b3JyeSBhYm91dC4NCg0KQnV0IGluIGEgY2Fycmll ciBXaS1GaSBlbnZpcm9ubWVudCB0aGlzIGFzc3VtcHRpb24gbm8tbG9uZ2VyIGhvbGRzIHRydWUu IFdUUHMgYXJlIGluc3RhbGxlZCBpbiBjb2ZmZWUgc2hvcHMsIHJlc3RhdXJhbnRzLCBzdGFkaXVt cyBhbmQgZXZlbiBmaXhlZC1saW5lIHN1YnNjcmliZXIgaG9tZXMgKGFzIGEgInNlY29uZCBTU0lE IiBvbiBhIHJlc2lkZW50aWFsIGdhdGV3YXkpLiBUaGVyZSBpcyBhbXBsZSBvcHBvcnR1bml0eSBm b3IgYW4gYXR0YWNrZXIgdG8gZ28gdG8gd29yayBvbiBhIFdUUCwgcGVyaGFwcyBldmVuIGluIHRo ZSBwcml2YWN5IG9mIHRoZWlyIG93biBob21lLg0KDQpJZiBhIHNpbmdsZSBvbmUgb2YgdGhvc2Ug V1RQcyBpcyBjb21wcm9taXNlZCAoYW5kIENBUFdBUCBtb2RlIGlzIExvY2FsIE1BQyBvciBTcGxp dCBNQUMgd2l0aCBlbmNyeXB0aW9uIGluIFdUUCkgdGhlbiB0aGVyZSBpcyBuby1sb25nZXIgYW55 IGd1YXJhbnRlZSBvZiB1c2VyIHBsYW5lIGludGVncml0eSBvciBjb25maWRlbnRpYWxpdHkgZm9y IHVzZXJzIG9mIHRoYXQgV1RQLiBCdXQgcGVyaGFwcyBtb3JlIGFsYXJtaW5nbHkgdGhlcmUgaXMg bm93IGFsc28gYSBnYXBpbmcgaG9sZSBpbiB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHByb3Bl cnR5IG9mIElFRUUgODAyLjExaSwgd2hpY2ggbWVhbnMgdGhhdCBhbGwgdXNlcnMgb2YgdGhlIHdp cmVsZXNzIG5ldHdvcmsgYXJlIG9wZW5lZCB1cCB0byBwb3NzaWJsZSBtYW4taW4tdGhlLW1pZGRs ZSAoTUlUTSkgYXR0YWNrIFsxXS4gSWYgeW91IGNvbWJpbmUgdGhpcyBmYWN0IHdpdGggYXV0b21h dGljIFNJTSBhdXRoZW50aWNhdGlvbiBhbmQgZ2xvYmFsIHJvYW1pbmcgdGhlIHBvdGVudGlhbCBp bXBhY3QgaXMgc2lnbmlmaWNhbnQuDQoNClRoaXMgaXMgdGhlIHJlYXNvbiB3ZSBpbnNpc3Qgb24g YWx3YXlzIGltcGxlbWVudGluZyBib3RoIDgwMi4xMSBlbmNyeXB0aW9uIGFuZCA4MDIuMVggYXV0 aGVudGljYXRpb24gYXQgdGhlIHR1bm5lbCB0ZXJtaW5hdGlvbiBwb2ludCAoZS5nLiBhbiBhY2Nl c3Mgcm91dGVyKSBpbiBvdXIgU0RXTiBhcmNoaXRlY3R1cmUgWzJdLiBVbmxpa2UgdGhlIFdUUCB0 aGUgdHVubmVsIHRlcm1pbmF0aW9uIHBvaW50IGNhbiBvZnRlbiBiZSBwaHlzaWNhbGx5IHByb3Rl Y3RlZC4gVGhpcyBwcm92aWRlcyBzdHJvbmcgZ3VhcmFudGVlcyBvZiB1c2VyIGRhdGEgcGxhbmUg aW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHksIGFuZCBhbHNvIHByb3RlY3RzIHRoZSBtdXR1 YWwgYXV0aGVudGljYXRpb24gcHJvcGVydHkgb2YgdGhlIHVuZGVybHlpbmcgSUVFRSA4MDIuMTFp IHNlY3VyaXR5IG1lY2hhbmlzbS4NCg0KQmVzdCByZWdhcmRzLA0KDQpCasO2cm4NCg0KMS4gVGhp cyByaXNrIG9mIE1JVE0gaW4gYSAic2VjdXJlIiBXaS1GaSBuZXR3b3JrIG1heSBub3QgYmUgZW50 aXJlbHkgb2J2aW91cy4gV2UgZXhwbGFpbiB0aGlzIHJpc2sgd2hlbiBhbiBhdHRhY2tlciBoYXMg YWNjZXNzIHRvIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzL2ludGVyZmFjZSBoZXJlOg0KaHR0 cDovL2FueWZpLm5ldC9kb2N1bWVudGF0aW9uI2lfbXV0dWFsX2F1dGhlbnRpY2F0aW9uLiBUaGUg c2FtZSByZWFzb25pbmcgaG93ZXZlciBob2xkcyB0cnVlIGlmIHRoZSBhdHRhY2tlciBjYW4gZm9y d2FyZCBJRUVFIDgwMi4xMSBmcmFtZXMgYmV0d2VlbiBhIHRhcmdldGVkIGRldmljZSBhbmQgYSBD QVBXQVAgQUMsIGFuZCBnZXQgdGhlIDgwMi4xMSBrZXkgZnJvbSB0aGF0IEFDIChhcyBpbiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDE2I3NlY3Rpb24tNi4xNSkuDQoNCjIuIGh0dHA6 Ly9hbnlmaS5uZXQvZG9jdW1lbnRhdGlvbiNhX2RhdGFfcGxhbmUNCg0K --_000_4ED2E36A22261145861BAB2C24088B4320F5E1E9xmbalnx09ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSI0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE2cHQ7Ij4NCjxkaXY+VGhpcyBpcyB0aGUgcmVhc29uIHdlIGluc2lzdCBv biBhbHdheXMgaW1wbGVtZW50aW5nIGJvdGggODAyLjExIGVuY3J5cHRpb24gYW5kIDgwMi4xWCBh dXRoZW50aWNhdGlvbiBhdCB0aGUgdHVubmVsIHRlcm1pbmF0aW9uIHBvaW50IChlLmcuIGFuIGFj Y2VzcyByb3V0ZXIpIGluIG91ciBTRFdOIGFyY2hpdGVjdHVyZSBbMl0uIFVubGlrZSB0aGUgV1RQ IHRoZSB0dW5uZWwgdGVybWluYXRpb24gcG9pbnQgY2FuIG9mdGVuIGJlIHBoeXNpY2FsbHkNCnBy b3RlY3RlZC4gVGhpcyBwcm92aWRlcyBzdHJvbmcgZ3VhcmFudGVlcyBvZiB1c2VyIGRhdGEgcGxh bmUgaW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHksIGFuZCBhbHNvIHByb3RlY3RzIHRoZSBt dXR1YWwgYXV0aGVudGljYXRpb24gcHJvcGVydHkgb2YgdGhlIHVuZGVybHlpbmcgSUVFRSA4MDIu MTFpIHNlY3VyaXR5IG1lY2hhbmlzbS48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsgPGZvbnQgY29sb3I9 IiM3MDMwQTAiPkkgdGhpbmsgSSB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIGV2ZW4gYmV0dGVyIG5v dyA6KSAuIEl0IGFwcGVhcnMgdGhhdCB0aGUgZHJhZnQgPC9mb250Pjxmb250IGZhY2U9IkNvdXJp ZXIgTmV3IiBjb2xvcj0iIzcwMzBBMCI+QWx0ZXJuYXRlIFR1bm5lbCBFbmNhcHN1bGF0aW9uIGZv ciBEYXRhIEZyYW1lcyBpbiBDQVBXQVAmcXVvdDssPC9mb250Pjxmb250IGZhY2U9IkNvdXJpZXIg TmV3IiBjb2xvcj0iIzcwMzBBMCI+Jm5ic3A7PC9mb250PjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctb3BzYXdnLWNhcHdhcC1jZHMvIj48Zm9udCBm YWNlPSJDb3VyaWVyIE5ldyIgY29sb3I9IiM3MDMwQTAiPjx1Pmh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctb3BzYXdnLWNhcHdhcC1jZHMvPC91PjwvZm9udD48L2E+ PGZvbnQgY29sb3I9IiM3MDMwQTAiPiZuYnNwOw0Kd291bGQgbWVldCA8L2ZvbnQ+PGZvbnQgY29s b3I9IiM3MDMwQTAiPnRoZSByZXF1aXJlbWVudCB0byB0dW5uZWwgZGF0YSB0cmFmZmljIHRvIGRp ZmZlcmVudCB0dW5uZWwgZW5kIHBvaW50LiBZb3Ugd291bGQgc2V0IHRoZSBNQUMgbW9kZSB0byBz cGxpdCBtYWMgYW5kIHR1bm5lbCBtb2RlIHRvIDgwMi4xMS4gVGhlIG9ubHkgbWlzc2luZyBwaWVj ZSA8L2ZvbnQ+PGZvbnQgY29sb3I9IiM3MDMwQTAiPndvdWxkIGJlIHRvIHNwZWNpZnkgdGhlIHRo YXQNCjgwMi4xMSBmcmFtZSA8L2ZvbnQ+PGZvbnQgY29sb3I9IiM3MDMwQTAiPmVuY3J5cHRpb248 L2ZvbnQ+PGZvbnQgY29sb3I9IiM3MDMwQTAiPiA8L2ZvbnQ+PGZvbnQgY29sb3I9IiM3MDMwQTAi PnNob3VsZCBoYXBwZW4gYXQgdGhlIHR1bm5lbCB0ZXJtaW5hdGlvbiBwb2ludCBhbmQgbm90IHRo ZSBXVFAuJm5ic3A7IFRoZXJlIGlzIG5vIGN1cnJlbnQgd2F5IHRvIG5lZ290aWF0ZSB0aGF0LiBO b3RlIHRoYXQgd2UgYXJlIHNvbHZpbmcgYSBzaW1pbGFyIHByb2JsZW0NCihpbiB0aGUgY29udGV4 dCB3aGVyZSBBQyBpcyB0aGUgdHVubmVsIHRlcm1pbmF0aW9uIHBvaW50KSA8L2ZvbnQ+PGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5 YnJpZG1hYy0wMiI+PGZvbnQgY29sb3I9IiM3MDMwQTAiPjx1Pmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWMtMDI8L3U+PC9mb250Pjwv YT48Zm9udCBjb2xvcj0iIzcwMzBBMCI+Lg0KPC9mb250Pjxmb250IGNvbG9yPSIjNzAzMEEwIj4g PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzcwMzBBMCI+U28gcG90ZW50aWFsbHkg YSBuZXcgc3BsaXQgTUFDIHByb2ZpbGUgaW4gdGhlIGNhc2UgdGhlIHR1bm5lbCB0ZXJtaW5hdGlv biBpcyBub3QgYXQgdGhlIEFDLiA8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCg0KRnJvbTogQmrDtnJuIFNtZWRtYW4gWzxhIGhyZWY9Im1haWx0bzpiam9y bi5zbWVkbWFuQGFueWZpbmV0d29ya3MuY29tIj5tYWlsdG86Ympvcm4uc21lZG1hbkBhbnlmaW5l dHdvcmtzLmNvbTwvYT5dDQo8YnI+DQoNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE0 IDU6MjMgQU08YnI+DQoNClRvOiBDYW8sWmhlbjxicj4NCg0KQ2M6IFJhamVzaCBQYXpoeWFubnVy IChycGF6aHlhbik7IG9wc2F3Z0BpZXRmLm9yZzxicj4NCg0KU3ViamVjdDogUmU6IFtPUFNBV0dd IFNpbXBsaWZpZWQgQWx0ZXJuYXRpdmUgdG8gQ0FQV0FQPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj5IaSBaaGVuLDwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+T24gVHVlLCBGZWIgMjUsIDIwMTQgYXQgOToyNyBB TSwgQ2FvLFpoZW4gJmx0OzxhIGhyZWY9Im1haWx0bzp6ZWhuLmNhb0BnbWFpbC5jb20iPnplaG4u Y2FvQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7IEFwcHJlY2lhdGUg eW91ciBhbmFseXNpcy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoYW5rcywgbGlr ZXdpc2UuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBUcnVlLCBpbiBD QVBXQVAgaXQncyBhIGJvcmRlciBjYXNlIHRoYXQgODAyLjFYIGtleSBleGNoYW5nZSBhbmQgPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7IDgwMi4xMSBlbmNyeXB0aW9uIHByb3RlY3RzIHRoZSB1c2VyIGRh dGEgcGxhbmUgYWxsIHRoZSB3YXkgZnJvbSB0aGUgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IG1vYmls ZSBTVEEgdG8gdGhlIEFDLiBCdXQgSSB0aGluayB0aGVyZSBhcmUgc3Ryb25nIHJlYXNvbnMgdG8g bWFrZSA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgdGhpcyB0aGU8L2Rpdj4NCjxkaXY+Jmd0OyZndDsg ZGVmYXVsdDo8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IEJ1dCBJIGRvIG5vdCBh Z3JlZSBoZXJlLiBUaGUgODAyLjExIGtleSBvbmx5IHByb3RlY3QgdGhlIGRhdGEgZnJvbSBTVEEg PC9kaXY+DQo8ZGl2PiZndDsgdG8gV1RQLCBOT1QgdGhlIEFDLCBib3RoIGluIGxvY2FsIE1BQyBh bmQgYWxzbyBvbmUgb3B0aW9uIGluIHRoZSBzcGxpdCA8L2Rpdj4NCjxkaXY+Jmd0OyBtb2RlbC4m bmJzcDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQxNiNzZWN0aW9u LTIuMi4yIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDE2I3NlY3Rpb24tMi4yLjI8 L2E+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250 PjwvZGl2Pg0KPGRpdj5JIHNoYXJlIHlvdXIgdW5kZXJzdGFuZGluZyB0aGF0IGluIHRoZSBDQVBX QVAgTG9jYWwgTUFDIG1vZGUsIGFuZCBtb3N0IGltcGxlbWVudGF0aW9ucyBvZiBTcGxpdCBNQUMs IHRoZSA4MDIuMTEga2V5IG9ubHkgcHJvdGVjdHMgdXNlciBkYXRhIGJldHdlZW4gU1RBIGFuZCBX VFAuIEJ1dCB3aGF0IEknbSBzYXlpbmcgaXMgdGhhdCB0aGlzIGlzIHVuZm9ydHVuYXRlLjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SW4gdGhlIGNvcnBvcmF0ZSBXTEFOIGVudmlyb25t ZW50IGZvciB3aGljaCBDQVBXQVAgd2FzIG9yaWdpbmFsbHkgZGVzaWduZWQgdGhlcmUgaXMgYW4g YXNzdW1wdGlvbiB0aGF0IFdUUHMgYW5kIHRoZSBEaXN0cmlidXRpb24gU3lzdGVtPC9kaXY+DQo8 ZGl2PihEUykgYXJlIHBoeXNpY2FsbHkgcHJvdGVjdGVkLCBieSBkb29ycywgYmFkZ2VzIGFuZCBz ZWN1cml0eSBwZXJzb25uZWwuIElmIHNvbWVib2R5IGdldHMgdGhyb3VnaCB0aG9zZSBwcm90ZWN0 aW9ucyBhbmQgY2FuIGFjY2VzcyB0aGUgV1RQIG9yIERTIHRoZW4gdGhlcmUgYXJlIG90aGVyIHRo aW5ncyB0byB3b3JyeSBhYm91dC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkJ1dCBp biBhIGNhcnJpZXIgV2ktRmkgZW52aXJvbm1lbnQgdGhpcyBhc3N1bXB0aW9uIG5vLWxvbmdlciBo b2xkcyB0cnVlLiBXVFBzIGFyZSBpbnN0YWxsZWQgaW4gY29mZmVlIHNob3BzLCByZXN0YXVyYW50 cywgc3RhZGl1bXMgYW5kIGV2ZW4gZml4ZWQtbGluZSBzdWJzY3JpYmVyIGhvbWVzIChhcyBhICZx dW90O3NlY29uZCBTU0lEJnF1b3Q7IG9uIGEgcmVzaWRlbnRpYWwgZ2F0ZXdheSkuIFRoZXJlIGlz IGFtcGxlIG9wcG9ydHVuaXR5IGZvciBhbiBhdHRhY2tlcg0KdG8gZ28gdG8gd29yayBvbiBhIFdU UCwgcGVyaGFwcyBldmVuIGluIHRoZSBwcml2YWN5IG9mIHRoZWlyIG93biBob21lLjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SWYgYSBzaW5nbGUgb25lIG9mIHRob3NlIFdUUHMgaXMg Y29tcHJvbWlzZWQgKGFuZCBDQVBXQVAgbW9kZSBpcyBMb2NhbCBNQUMgb3IgU3BsaXQgTUFDIHdp dGggZW5jcnlwdGlvbiBpbiBXVFApIHRoZW4gdGhlcmUgaXMgbm8tbG9uZ2VyIGFueSBndWFyYW50 ZWUgb2YgdXNlciBwbGFuZSBpbnRlZ3JpdHkgb3IgY29uZmlkZW50aWFsaXR5IGZvciB1c2VycyBv ZiB0aGF0IFdUUC4gQnV0IHBlcmhhcHMgbW9yZSBhbGFybWluZ2x5IHRoZXJlIGlzDQpub3cgYWxz byBhIGdhcGluZyBob2xlIGluIHRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24gcHJvcGVydHkgb2Yg SUVFRSA4MDIuMTFpLCB3aGljaCBtZWFucyB0aGF0IGFsbCB1c2VycyBvZiB0aGUgd2lyZWxlc3Mg bmV0d29yayBhcmUgb3BlbmVkIHVwIHRvIHBvc3NpYmxlIG1hbi1pbi10aGUtbWlkZGxlIChNSVRN KSBhdHRhY2sgWzFdLiBJZiB5b3UgY29tYmluZSB0aGlzIGZhY3Qgd2l0aCBhdXRvbWF0aWMgU0lN IGF1dGhlbnRpY2F0aW9uIGFuZCBnbG9iYWwNCnJvYW1pbmcgdGhlIHBvdGVudGlhbCBpbXBhY3Qg aXMgc2lnbmlmaWNhbnQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGlzIGlzIHRo ZSByZWFzb24gd2UgaW5zaXN0IG9uIGFsd2F5cyBpbXBsZW1lbnRpbmcgYm90aCA4MDIuMTEgZW5j cnlwdGlvbiBhbmQgODAyLjFYIGF1dGhlbnRpY2F0aW9uIGF0IHRoZSB0dW5uZWwgdGVybWluYXRp b24gcG9pbnQgKGUuZy4gYW4gYWNjZXNzIHJvdXRlcikgaW4gb3VyIFNEV04gYXJjaGl0ZWN0dXJl IFsyXS4gVW5saWtlIHRoZSBXVFAgdGhlIHR1bm5lbCB0ZXJtaW5hdGlvbiBwb2ludCBjYW4gb2Z0 ZW4gYmUgcGh5c2ljYWxseQ0KcHJvdGVjdGVkLiBUaGlzIHByb3ZpZGVzIHN0cm9uZyBndWFyYW50 ZWVzIG9mIHVzZXIgZGF0YSBwbGFuZSBpbnRlZ3JpdHkgYW5kIGNvbmZpZGVudGlhbGl0eSwgYW5k IGFsc28gcHJvdGVjdHMgdGhlIG11dHVhbCBhdXRoZW50aWNhdGlvbiBwcm9wZXJ0eSBvZiB0aGUg dW5kZXJseWluZyBJRUVFIDgwMi4xMWkgc2VjdXJpdHkgbWVjaGFuaXNtLjwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+QmrDtnJuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4xLiBUaGlzIHJpc2sg b2YgTUlUTSBpbiBhICZxdW90O3NlY3VyZSZxdW90OyBXaS1GaSBuZXR3b3JrIG1heSBub3QgYmUg ZW50aXJlbHkgb2J2aW91cy4gV2UgZXhwbGFpbiB0aGlzIHJpc2sgd2hlbiBhbiBhdHRhY2tlciBo YXMgYWNjZXNzIHRvIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzL2ludGVyZmFjZSBoZXJlOjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxhIGhyZWY9Imh0dHA6Ly9h bnlmaS5uZXQvZG9jdW1lbnRhdGlvbiNpX211dHVhbF9hdXRoZW50aWNhdGlvbiI+PGZvbnQgZmFj ZT0iQ2FsaWJyaSI+aHR0cDovL2FueWZpLm5ldC9kb2N1bWVudGF0aW9uI2lfbXV0dWFsX2F1dGhl bnRpY2F0aW9uPC9mb250PjwvYT48Zm9udCBmYWNlPSJDYWxpYnJpIj4uIFRoZSBzYW1lIHJlYXNv bmluZyBob3dldmVyIGhvbGRzIHRydWUgaWYgdGhlIGF0dGFja2VyDQpjYW4gZm9yd2FyZCBJRUVF IDgwMi4xMSBmcmFtZXMgYmV0d2VlbiBhIHRhcmdldGVkIGRldmljZSBhbmQgYSBDQVBXQVAgQUMs IGFuZCBnZXQgdGhlIDgwMi4xMSBrZXkgZnJvbSB0aGF0IEFDIChhcyBpbiA8L2ZvbnQ+PGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQxNiNzZWN0aW9uLTYuMTUiPjxmb250 IGZhY2U9IkNhbGlicmkiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU0MTYjc2VjdGlv bi02LjE1PC9mb250PjwvYT48Zm9udCBmYWNlPSJDYWxpYnJpIj4pLjwvZm9udD48L2ZvbnQ+PC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4yLiA8YSBocmVmPSJodHRwOi8vYW55ZmkubmV0 L2RvY3VtZW50YXRpb24jYV9kYXRhX3BsYW5lIj5odHRwOi8vYW55ZmkubmV0L2RvY3VtZW50YXRp b24jYV9kYXRhX3BsYW5lPC9hPjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_4ED2E36A22261145861BAB2C24088B4320F5E1E9xmbalnx09ciscoc_-- From nobody Tue Feb 25 12:12:58 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 30D9D1A082A for ; Tue, 25 Feb 2014 12:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 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_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 DNB1-p03g9RO for ; Tue, 25 Feb 2014 12:12:48 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 854BC1A082D for ; Tue, 25 Feb 2014 12:12:47 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so3605120lbv.24 for ; Tue, 25 Feb 2014 12:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lNNRrVgXR58damVRHgi4uvrhTQ3O1hoth6u4lTY6r6k=; b=O2prDes1Wzh610cbm7/h7CF/K5BaHfXIsIO3CeAaSgbXlWFswfdVFfpXWKUt3cszhx LV/5oFNrSuKJvtR0XTGObJYVyXQtPS9n5yJHQ1KHaDKROWEFOORZ4mQPOo+42y5GDB+J wYtQ2BJ9M9wfrRhbCxWF3oM2+W/3vw/SbKIptQi0yhV/wATvH5GHkM25jxAlchkk+Agh Ku3Lcvg4BLOewiaEWVl3V0XyaBnhGfsYV0J5+t2ZZ2lxnVVC4bYFtlZvKW8AVRPoXEdE 2PMS4vHDMgMZzItRYKdmIzwfrXO/2hFubU9PuqR56vw1tjWalG7E50p+HR61YhpXdYYt cfPg== MIME-Version: 1.0 X-Received: by 10.112.63.193 with SMTP id i1mr895925lbs.54.1393359165748; Tue, 25 Feb 2014 12:12:45 -0800 (PST) Received: by 10.114.176.234 with HTTP; Tue, 25 Feb 2014 12:12:45 -0800 (PST) In-Reply-To: References: Date: Tue, 25 Feb 2014 14:12:45 -0600 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?Q?Bj=F6rn_Smedman?= Content-Type: multipart/alternative; boundary=001a11c3fd101e9e3904f340b6e0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/X4tSyeKP_pO4Qz6fpynLBGVX4_o Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 20:12:51 -0000 --001a11c3fd101e9e3904f340b6e0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bjorn, On Mon, Feb 24, 2014 at 4:57 PM, Bj=F6rn Smedman < bjorn.smedman@anyfinetworks.com> wrote: > Dear all, > > I've been following the recent CAPWAP activity on this list and > thought I should share some general thoughts on the protocol, and see > if there's interest in a broader approach. > > The CAPWAP shortcomings discussed are similar to the problems > preventing us [1] from using it in our Software-Defined Networking > (SDN) architecture for IEEE 802.11 [2]: > > Where in IEEE 802.11 is this happening? Your link [2] is pointing to your company's evaluation system. As far as I know, in IEEE 802, SDN work is being pursued in 802.16. > 1. CAPWAP was specified before separation of data, control and > management planes became the norm in networking architecture. > Unsurprisingly it provides very little separation of concern, > conflating everything from firmware updates to configuration of an > extra SSID. > > 2. CAPWAP attempts to provide provisioning/management functionality > that overlaps with other IETF standards track protocols, e.g. SNMP and > NETCONF/YANG, as well as other established management protocols such > as TR-069. > > This is good point I think. But TR-069 is not ready for prime time yet. > 3. The separation of data and control planes that CAPWAP does provide > is IMHO incorrect: 802.1X key exchange is considered part of the > control plane but the derived encryption keys protect the data plane. > This doesn't matter when both control and data plane terminate in the > same location (the AC), but becomes a problem when they are separated > (encryption keys end up in a different place than the encrypted > data!). > > 4. CAPWAP leaves many options open to the implementer and is therefore > less interoperable than desired. To some extent this can be solved > with run-time negotiation, but such negotiation of security critical > aspects (such as where encryption keys are derived and kept) makes it > impossible to reason about the security of the system. This is less > than ideal IMHO. > > 5. CAPWAP (partly due to 1 and 2 above) depends excessively on details > in the IEEE 802.11 standard, with each amendment threatening to impact > the protocol. > > > We would be interested in specifying a simplified tunneling protocol > for IEEE 802.11 similar to Geneve [3], avoiding the above problems: > > Geneve seems to be derived from VXLAN or NVGRE. Is this correct? > A. The protocol should mandate a single well-defined partitioning of > the IEEE 802.11 stack, with 802.1X authentication, key management and > encryption all implemented at the tunnel termination point for > security reasons. > > B. The protocol should mandate a single well-defined frame format > relying only on a PHY-independent stable subset of IEEE 802.11, > ensuring compatibility with 11n/ac and (most likely) beyond. > > C. Like Geneve the protocol should not provide any > provisioning/management functionality, instead relying on SNMP, > NETCONF/YANG, TR-069 and similar. > > D. Like Geneve the protocol should not provide any control plane > functionality, instead remaining compatible with several > Software-Defined Networking (SDN) protocols for IEEE 802.11. > > Any pointers on this? Regards, Behcet > E. Each virtual access point in a multi-BSSID (and/or multi-radio) > access point should be treated as a separate entity associated with a > separate tunnel. > > > We see strong benefits to such a protocol from an extensibility [4], > flexibility [5] and security [6] perspective. If there is interest in > exploring this further please let me know. > > Best regards, > > Bj=F6rn Smedman > > 1. http://www.anyfinetworks.com > > 2. http://anyfi.net and http://www.anyfinetworks.com/products > > 3. http://tools.ietf.org/html/draft-gross-geneve-00 > > 4. http://anyfi.net/documentation#architecture > > 5. http://anyfi.net/documentation#a_how_it_all_fits_together > > 6. http://anyfi.net/documentation#i_security_model > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a11c3fd101e9e3904f340b6e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi Bjorn,




    On Mon, Feb 24, 2014 at 4:57 PM, Bj=F6rn Smedman <= span dir=3D"ltr"><bjorn.smedman@anyfinetworks.com> wrote:
    Dear all,

    I've been following the recent CAPWAP activity on this list and
    thought I should share some general thoughts on the protocol, and see
    if there's interest in a broader approach.

    The CAPWAP shortcomings discussed are similar to the problems
    preventing us [1] from using it in our Software-Defined Networking
    (SDN) architecture for IEEE 802.11 [2]:


    Where in IEEE 802.11 is this happening= ?
    Your link [2] is pointing to your company's evaluation = system.

    As far as I know, in IEEE 802, SDN work is being = pursued in 802.16.

    =A0
    1. CAPWAP was specified before separation of data, control and
    management planes became the norm in networking architecture.
    Unsurprisingly it provides very little separation of concern,
    conflating everything from firmware updates to configuration of an
    extra SSID.

    2. CAPWAP attempts to provide provisioning/management functionality
    that overlaps with other IETF standards track protocols, e.g. SNMP and
    NETCONF/YANG, as well as other established management protocols such
    as TR-069.


    This is good point I think. But TR-069= is not ready for prime time yet.

    =A0
    3. The separation of data and control planes that CAPWAP does provide
    is IMHO incorrect: 802.1X key exchange is considered part of the
    control plane but the derived encryption keys protect the data plane.
    This doesn't matter when both control and data plane terminate in the same location (the AC), but becomes a problem when they are separated
    (encryption keys end up in a different place than the encrypted
    data!).

    4. CAPWAP leaves many options open to the implementer and is therefore
    less interoperable than desired. To some extent this can be solved
    with run-time negotiation, but such negotiation of security critical
    aspects (such as where encryption keys are derived and kept) makes it
    impossible to reason about the security of the system. This is less
    than ideal IMHO.

    5. CAPWAP (partly due to 1 and 2 above) depends excessively on details
    in the IEEE 802.11 standard, with each amendment threatening to impact
    the protocol.


    We would be interested in specifying a simplified tunneling protocol
    for IEEE 802.11 similar to Geneve [3], avoiding the above problems:


    Geneve seems to be derived from VXLAN = or NVGRE.
    Is this correct?

    =A0
    A. The protocol should mandate a single well-defined partitioning of
    the IEEE 802.11 stack, with 802.1X authentication, key management and
    encryption all implemented at the tunnel termination point for
    security reasons.

    B. The protocol should mandate a single well-defined frame format
    relying only on a PHY-independent stable subset of IEEE 802.11,
    ensuring compatibility with 11n/ac and (most likely) beyond.

    C. Like Geneve the protocol should not provide any
    provisioning/management functionality, instead relying on SNMP,
    NETCONF/YANG, TR-069 and similar.

    D. Like Geneve the protocol should not provide any control plane
    functionality, instead remaining compatible with several
    Software-Defined Networking (SDN) protocols for IEEE 802.11.


    Any pointers on this?

    Regards,

    Behcet
    =A0
    E. Each virtual access point in a multi-BSSID (and/or multi-radio)
    access point should be treated as a separate entity associated with a
    separate tunnel.


    We see strong benefits to such a protocol from an extensibility [4],
    flexibility [5] and security [6] perspective. If there is interest in
    exploring this further please let me know.

    Best regards,

    Bj=F6rn Smedman

    1. http://www.an= yfinetworks.com

    2. http://anyfi.net and = http://= www.anyfinetworks.com/products

    3. http://tools.ietf.org/html/draft-gross-geneve-00

    4. http://anyfi.net/documentation#architecture

    5. http://anyfi.net/documentation#a_how_it_all_fits_together

    6.     http://anyfi.net/documentation#i_security_model

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

--001a11c3fd101e9e3904f340b6e0-- From nobody Tue Feb 25 12:26:14 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 F3A3C1A0789 for ; Tue, 25 Feb 2014 12:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 gUyCvLWDoEMF for ; Tue, 25 Feb 2014 12:26:10 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id DC94D1A0292 for ; Tue, 25 Feb 2014 12:26:09 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id l6so1040696oag.5 for ; Tue, 25 Feb 2014 12:26:08 -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 :content-transfer-encoding; bh=hC7SufpFFCEcAmhWfu0Fjp4SFDO17q7V9towlFXWUm4=; b=b5qvP3C4fbgmMeDZi/v+lZwvBY8LRx8UTZggra6wleTkBlq47lkMkkXgcM5jGGzaET OSTjp3/6fzdImaL5qeSy5NDYv44vOIdGIIdm07sK2o9PyDhTLRNSbx4cqK/FgfDcYpB4 eRnk8M3FUs54wfxy/fHBTbe/xSe8j1WOM6sRXDkKQ2smz1xDBb8HYUM+VvL4Q2l28pl1 EKMoMELBcXUS4I5n8rr+QE/v/+0R2ALcdFDra1rg7eyu9Z88bYTaV5S3XflUYh+Apa6B dQKkzvTXS1xchEUgCO4WN/Jlp7O/x7o6BJFgy7D7P89ggufukAJ8QfP0GjEIyXAy2qOf B30A== X-Gm-Message-State: ALoCoQlZeGcOZ+sxqTZsjf3a6gOjynyHNB7JNe4plAgoRN7wSGXlb9g4IC8f667XbQge3pRMTO2B MIME-Version: 1.0 X-Received: by 10.182.102.7 with SMTP id fk7mr3121206obb.28.1393359968553; Tue, 25 Feb 2014 12:26:08 -0800 (PST) Received: by 10.182.191.9 with HTTP; Tue, 25 Feb 2014 12:26:08 -0800 (PST) X-Originating-IP: [82.99.7.230] In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320F5D8F1@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320F5D75F@xmb-aln-x09.cisco.com> <4ED2E36A22261145861BAB2C24088B4320F5D8F1@xmb-aln-x09.cisco.com> Date: Tue, 25 Feb 2014 21:26:08 +0100 Message-ID: From: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= To: "Rajesh Pazhyannur (rpazhyan)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/MklYRG5g3p6HjKVfasSSFcYmCs8 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP 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, 25 Feb 2014 20:26:12 -0000 Hi Rajesh, On Tue, Feb 25, 2014 at 7:29 AM, Rajesh Pazhyannur (rpazhyan) wrote: > > Yes, if piecewise security is sufficient then there are a multitude of = IETF > > protocols to chose from. But if end-to-end 802.11 encryption all the wa= y > > from the mobile STA to a trusted location (e.g. a service/access router= in > > the network core) is desired then there is nothing in the IETF playbook > > except a border case of CAPWAP, which comes with an entangled control a= nd > > provisioning/management plane. > > Okay, I understand the problem statement much better. > Can you explain the part about =E2=80=9Centangled control=E2=80=9D. Is t= his because in the > existing CAPWAP model, 802.1X is always handled by the AC (even if the da= ta > channel is tunneled to another AR) and you want 802.1X to be handled by t= he > Tunnel Termination Gateway. Yes, my thinking is that 802.1X and (other) 802.11 data should ideally terminate in the same location - essentially because in the case I care most dearly about the 802.11 data frames are encrypted with the 802.11 key derived as part of the 802.1X authentication. To me it just makes sense that encryption and authentication terminate in the same place, so that the entity that gets my clear-text data is the entity that I have actually authenticated. But there's of course also a practical issue: if encrypted 802.11 frames end up in the AR but 802.11 key is in the AC... well you get the point. But what I meant with my comment above was more about how CAPWAP bundles everything into a single protocol, so if I want to use CAPWAP for tunneling between WTP and AC/AR/whatever then I also have to consider what my WTP will do if it receives the CAPWAP firmware update command... Imagine if IPSEC, L2oGRE and Geneve all came with a firmware update command and there was no alternative... That's what I mean with "entangled control and provisioning/management": there's no clean tunneling protocol for 802.11 that does only that - so we've had to implement our own [1]. Best regards, Bj=C3=B6rn 1. http://anyfi.net/documentation#a_data_plane > -----Original Message----- > From: Bj=C3=B6rn Smedman [mailto:bjorn.smedman@anyfinetworks.com] > Sent: Monday, February 24, 2014 5:54 PM > To: Rajesh Pazhyannur (rpazhyan) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP > > Hi Rajesh, > > On Tue, Feb 25, 2014 at 1:29 AM, Rajesh Pazhyannur (rpazhyan) > wrote: >> >> Thanks for the well captured email. Would like to explore more about >> what you are suggesting. > > Thanks, it's much appreciated. > >> In the meanwhile, >> >> > 3. The separation of data and control planes that CAPWAP does >> > provide is IMHO incorrect: 802.1X key exchange is considered part of >> > the control plane but the derived encryption keys protect the data >> > plane. >> > This doesn't matter when both control and data plane terminate in >> > the same location (the AC), but becomes a problem when they are >> > separated (encryption keys end up in a different place than the >> > encrypted data!). >> >> Technically speaking, 802.1X protects the 802.11 frames and does not >> have anything to do CAPWAP Data channel. The Data channel is protected >> using DTLS. It is conceivable that 1) the tunnel mode is encapsulating >> 802.11 frames (instead of 802.3 frames) and 2) CAPWAP-Data is not >> encrypted and 3) >> 802.11 encryption is happening at the AC instead of AP. When all three >> conditions hold, what you are saying is true: 802.1X is indeed >> protecting the data plane. > > True, in CAPWAP it's a border case that 802.1X key exchange and 802.11 > encryption protects the user data plane all the way from the mobile STA t= o > the AC. But I think there are strong reasons to make this the > default: > > * DTLS cannot protect the user data plane inside the WTP. If 802.11 > encryption keys and clear-text user data is available inside the WTP and = the > WTP is not physically protected then (at least from a theoretical > perspective) the integrity and confidentiality of the data plane cannot b= e > trusted. > > * DTLS encryption is also wasteful: encrypted 802.11 data frames come in > over the air, are unencrypted in the WTP and then encrypted again with DT= LS. > > * DTLS also provides authentication, but to me it makes little sense to > authenticate an untrusted party. If the WTP can be under the physical > control of an attacker, then there is no point in authenticating it again= st > a digital certificate stored in the WTP. > > IMHO encrypting the CAPWAP-Data channel with DTLS and authenticating the = WTP > is borderline "security by obscurity" in that it relies on an attacker no= t > being able to gain access to WTP memory. This assumption may have been > relatively true in the corporate WLAN environment that CAPWAP was designe= d > for, but it's less and less true for carrier Wi-Fi deployments. > > When on the other hand the 802.11 encryption is relied upon to protect th= e > user data plane the WTP is simply excluded from the security > equation: Even an attacker in complete control of the WTP is no threat to > the integrity or confidentiality of the user data plane (since they have > access to nothing more than the encrypted 802.11 frames which are also > available from the air). That also means there's no real need to > authenticate the WTP, and the security model is greatly simplified. > >> > A. The protocol should mandate a single well-defined partitioning of >> > the IEEE 802.11 stack, with 802.1X authentication, key management >> > and encryption all implemented at the tunnel termination point for >> > security reasons. >> >> By this I am assuming that you want encryption at the Tunnel >> termination point rather than the AP. What is motivating this, given >> that all APs (that I know of) implement 802.11 encryption and if >> security is needed between AP and Tunnel termination point then one coul= d >> use IPSEC or DTLS. > > Yes, if piecewise security is sufficient then there are a multitude of IE= TF > protocols to chose from. But if end-to-end 802.11 encryption all the way > from the mobile STA to a trusted location (e.g. a service/access router i= n > the network core) is desired then there is nothing in the IETF playbook > except a border case of CAPWAP, which comes with an entangled control and > provisioning/management plane. > > Best regards, > > Bj=C3=B6rn > >> -----Original Message----- >> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Bj=C3=B6rn >> Smedman >> Sent: Monday, February 24, 2014 2:57 PM >> To: opsawg@ietf.org >> Subject: [OPSAWG] Simplified Alternative to CAPWAP >> >> Dear all, >> >> I've been following the recent CAPWAP activity on this list and >> thought I should share some general thoughts on the protocol, and see >> if there's interest in a broader approach. >> >> The CAPWAP shortcomings discussed are similar to the problems >> preventing us [1] from using it in our Software-Defined Networking >> (SDN) architecture for IEEE 802.11 [2]: >> >> 1. CAPWAP was specified before separation of data, control and >> management planes became the norm in networking architecture. >> Unsurprisingly it provides very little separation of concern, >> conflating everything from firmware updates to configuration of an extra >> SSID. >> >> 2. CAPWAP attempts to provide provisioning/management functionality >> that overlaps with other IETF standards track protocols, e.g. SNMP and >> NETCONF/YANG, as well as other established management protocols such >> as TR-069. >> >> 3. The separation of data and control planes that CAPWAP does provide >> is IMHO incorrect: 802.1X key exchange is considered part of the >> control plane but the derived encryption keys protect the data plane. >> This doesn't matter when both control and data plane terminate in the >> same location (the AC), but becomes a problem when they are separated >> (encryption keys end up in a different place than the encrypted data!). >> >> 4. CAPWAP leaves many options open to the implementer and is therefore >> less interoperable than desired. To some extent this can be solved >> with run-time negotiation, but such negotiation of security critical >> aspects (such as where encryption keys are derived and kept) makes it >> impossible to reason about the security of the system. This is less than >> ideal IMHO. >> >> 5. CAPWAP (partly due to 1 and 2 above) depends excessively on details >> in the IEEE 802.11 standard, with each amendment threatening to impact >> the protocol. >> >> >> We would be interested in specifying a simplified tunneling protocol >> for IEEE 802.11 similar to Geneve [3], avoiding the above problems: >> >> A. The protocol should mandate a single well-defined partitioning of >> the IEEE 802.11 stack, with 802.1X authentication, key management and >> encryption all implemented at the tunnel termination point for security >> reasons. >> >> B. The protocol should mandate a single well-defined frame format >> relying only on a PHY-independent stable subset of IEEE 802.11, >> ensuring compatibility with 11n/ac and (most likely) beyond. >> >> C. Like Geneve the protocol should not provide any >> provisioning/management functionality, instead relying on SNMP, >> NETCONF/YANG, TR-069 and similar. >> >> D. Like Geneve the protocol should not provide any control plane >> functionality, instead remaining compatible with several >> Software-Defined Networking (SDN) protocols for IEEE 802.11. >> >> E. Each virtual access point in a multi-BSSID (and/or multi-radio) >> access point should be treated as a separate entity associated with a >> separate tunnel. >> >> >> We see strong benefits to such a protocol from an extensibility [4], >> flexibility [5] and security [6] perspective. If there is interest in >> exploring this further please let me know. >> >> Best regards, >> >> Bj=C3=B6rn Smedman >> >> 1. http://www.anyfinetworks.com >> >> 2. http://anyfi.net and http://www.anyfinetworks.com/products >> >> 3. http://tools.ietf.org/html/draft-gross-geneve-00 >> >> 4. http://anyfi.net/documentation#architecture >> >> 5. http://anyfi.net/documentation#a_how_it_all_fits_together >> >> 6. http://anyfi.net/documentation#i_security_model >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > From nobody Wed Feb 26 07:13: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 0AC731A042B for ; Wed, 26 Feb 2014 07:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.221 X-Spam-Level: X-Spam-Status: No, score=0.221 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 NyDUTLRoN-M6 for ; Wed, 26 Feb 2014 07:12:51 -0800 (PST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 985361A00DB for ; Wed, 26 Feb 2014 07:12:51 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id i11so952969oag.18 for ; Wed, 26 Feb 2014 07:12:50 -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 :content-transfer-encoding; bh=MbTM1eWzwKbge0RRDeup0NZTXwk9fCFEBe6wGsxl7Zo=; b=YV9aTAFQJGO6ctRUZ0Xe04GCzax1a2GOhzjhMsRuxajvyBe+3aPLxvVjPdJokpbQtH 6JjdaWNgnzv6Z983io/zm39QabbpcJNKAwA+mtv/LUXWvu7/IBOvMA11smWEXvhVjH2X kNm0f9mH/+cHz8+ktHitTlQGGvOQhpD+n35GhI+LpuhKPmahbLlhgwuqGh46oRUMcURM sPi6cT3MVjyxZy4aCANNiVMJi2mS3FNnM0tpEpfZg9uzGVs4xCBGjymyjmnkfhSyz75+ e7MJoRXSS9NXN94cIw6ITNXJ5fPUiv9qXFrhyd0rSffVoGyLIFStbLHBoQ+1Ga6oUSii +/dA== X-Gm-Message-State: ALoCoQm/HEpI7TdB//M2Bt7m1NVRPtQ3kGqEwBsLf/+dojh6ccojVNJHIxGLgtBiKJ7cqZ2UCy58 MIME-Version: 1.0 X-Received: by 10.60.165.72 with SMTP id yw8mr1170150oeb.71.1393427570206; Wed, 26 Feb 2014 07:12:50 -0800 (PST) Received: by 10.182.191.9 with HTTP; Wed, 26 Feb 2014 07:12:50 -0800 (PST) X-Originating-IP: [82.99.7.230] In-Reply-To: References: Date: Wed, 26 Feb 2014 16:12:50 +0100 Message-ID: From: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= To: sarikaya@ieee.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/pZYGa036NhAeqMdt9aYK6d0KSyI Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP 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, 26 Feb 2014 15:12:53 -0000 Hi Behcet, Thanks for your comments. On Tue, Feb 25, 2014 at 9:12 PM, Behcet Sarikaya w= rote: > On Mon, Feb 24, 2014 at 4:57 PM, Bj=C3=B6rn Smedman wrote: >> The CAPWAP shortcomings discussed are similar to the problems >> preventing us [1] from using it in our Software-Defined Networking >> (SDN) architecture for IEEE 802.11 [2]: >> > > Where in IEEE 802.11 is this happening? > Your link [2] is pointing to your company's evaluation system. > > As far as I know, in IEEE 802, SDN work is being pursued in 802.16. Our architecture is compliant with the IEEE 802.11 standard as-is, so we've seen little reason to get involved with the IEEE so far. The work within 802.16 seems more focused on 802.3 SDN. Ours is an overlay architecture based on tunneling 802.11 over IP (using our implementation of the here proposed protocol). Think Contrail meets the here proposed tunneling protocol and has a baby. ;) Long term we think the same split that you have for 802.3 SDN would make sense: IETF standards track for the data plane tunneling protocol (Geneve equivalent), separate standardization process for the control plane (OpenFlow / Open Networking Foundation equivalent). >> 1. CAPWAP was specified before separation of data, control and >> management planes became the norm in networking architecture. >> Unsurprisingly it provides very little separation of concern, >> conflating everything from firmware updates to configuration of an >> extra SSID. >> >> 2. CAPWAP attempts to provide provisioning/management functionality >> that overlaps with other IETF standards track protocols, e.g. SNMP and >> NETCONF/YANG, as well as other established management protocols such >> as TR-069. >> > > This is good point I think. But TR-069 is not ready for prime time yet. With all its shortcomings it's still widely deployed for managing residential gateways (fixed-line braodband CPE). We come across it a great deal in the field. >> 3. The separation of data and control planes that CAPWAP does provide >> is IMHO incorrect: 802.1X key exchange is considered part of the >> control plane but the derived encryption keys protect the data plane. >> This doesn't matter when both control and data plane terminate in the >> same location (the AC), but becomes a problem when they are separated >> (encryption keys end up in a different place than the encrypted >> data!). >> >> 4. CAPWAP leaves many options open to the implementer and is therefore >> less interoperable than desired. To some extent this can be solved >> with run-time negotiation, but such negotiation of security critical >> aspects (such as where encryption keys are derived and kept) makes it >> impossible to reason about the security of the system. This is less >> than ideal IMHO. >> >> 5. CAPWAP (partly due to 1 and 2 above) depends excessively on details >> in the IEEE 802.11 standard, with each amendment threatening to impact >> the protocol. >> >> >> We would be interested in specifying a simplified tunneling protocol >> for IEEE 802.11 similar to Geneve [3], avoiding the above problems: >> > > Geneve seems to be derived from VXLAN or NVGRE. > Is this correct? Yes, they're all essentially tunneling protocols for 802.3. What we're proposing is an IETF standard tunneling protocol for 802.11. >> A. The protocol should mandate a single well-defined partitioning of >> the IEEE 802.11 stack, with 802.1X authentication, key management and >> encryption all implemented at the tunnel termination point for >> security reasons. >> >> B. The protocol should mandate a single well-defined frame format >> relying only on a PHY-independent stable subset of IEEE 802.11, >> ensuring compatibility with 11n/ac and (most likely) beyond. >> >> C. Like Geneve the protocol should not provide any >> provisioning/management functionality, instead relying on SNMP, >> NETCONF/YANG, TR-069 and similar. >> >> D. Like Geneve the protocol should not provide any control plane >> functionality, instead remaining compatible with several >> Software-Defined Networking (SDN) protocols for IEEE 802.11. >> > > Any pointers on this? See Geneve draft section 2.1 Control Plane Independence (http://tools.ietf.org/html/draft-gross-geneve-00#section-2.1). There's no explicit mention of "Management Plane Independence", e.g. for firmware updates and similar, but I'd say it's just an implicit requirement on a tunneling protocol, taken for granted. >> E. Each virtual access point in a multi-BSSID (and/or multi-radio) >> access point should be treated as a separate entity associated with a >> separate tunnel. >> >> >> We see strong benefits to such a protocol from an extensibility [4], >> flexibility [5] and security [6] perspective. If there is interest in >> exploring this further please let me know. >> >> Best regards, >> >> Bj=C3=B6rn Smedman >> >> 1. http://www.anyfinetworks.com >> >> 2. http://anyfi.net and http://www.anyfinetworks.com/products >> >> 3. http://tools.ietf.org/html/draft-gross-geneve-00 >> >> 4. http://anyfi.net/documentation#architecture >> >> 5. http://anyfi.net/documentation#a_how_it_all_fits_together >> >> 6. http://anyfi.net/documentation#i_security_model >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > From nobody Wed Feb 26 08:02: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 A80741A0114 for ; Tue, 25 Feb 2014 10:32: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 IVakFYDtLZ6O for ; Tue, 25 Feb 2014 10:32:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 254451A014B for ; Tue, 25 Feb 2014 10:32:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140225183218.32070.74825.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2014 10:32:18 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/AeRShFFzJyIeu5wL5wB4KeI1Sow X-Mailman-Approved-At: Wed, 26 Feb 2014 08:02:32 -0800 Subject: [OPSAWG] Milestones changed for opsawg WG 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, 25 Feb 2014 18:32:28 -0000 Changed milestone "Initial submission for the 'IF-CAP-STACK-MIB MIB module' Internet-Draft", resolved as "Done", added draft-ietf-opsawg-rfc5066bis to milestone. Changed milestone "Submit the 'IF-CAP-STACK-MIB MIB module' Internet-Draft to the IESG for consideration as Proposed Standard", resolved as "Done", added draft-ietf-opsawg-rfc5066bis to milestone. URL: http://datatracker.ietf.org/wg/opsawg/charter/ From nobody Wed Feb 26 12:56: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 00E6E1A06BC for ; Wed, 26 Feb 2014 12:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 olLFwXIEkT9T for ; Wed, 26 Feb 2014 12:56:05 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 512661A0184 for ; Wed, 26 Feb 2014 12:56:03 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id p9so1048197lbv.32 for ; Wed, 26 Feb 2014 12:56:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AMR0CJ0qVgg2JKcJPn0jV9KTWAAHAzj4HW6tVlF6wmw=; b=H3gXqK8wKnzc/21KqU6m+dZp2LDHtkcN6JgkB14d1IQWgumkm/f1VFLdS6IXYDqWBR CCwlTH24Bwzf8DjebzTo58PcVIjK9ubEehdN2Nbeb95sRbIrfCZtP/UiwhJs7a6vtJ/J chZ5HY6suCKzWpSbdTPKChllYotWKTUU6VHY9AbowtlSB5lFT3RCFKnXYJlWSLhEdkon 2sUqEppdfaRhViWfavQ0tf3YFbFQmF2AU+L657wnA6ocFVlu75lUQYG0vbLkTbNK9suz txXzK3QyZTA0O6cPHlF+XyrP1N3moawzd1XtUER4MpiQmkLQotMbLDT344ixM+b4Cg/0 eXfg== MIME-Version: 1.0 X-Received: by 10.152.23.169 with SMTP id n9mr3105570laf.45.1393448161212; Wed, 26 Feb 2014 12:56:01 -0800 (PST) Received: by 10.114.176.234 with HTTP; Wed, 26 Feb 2014 12:56:01 -0800 (PST) In-Reply-To: References: Date: Wed, 26 Feb 2014 14:56:01 -0600 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?Q?Bj=F6rn_Smedman?= Content-Type: multipart/alternative; boundary=089e0160b99aa97ca704f3556e90 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ly_F1lcMdqSPkQXg308IeWaR7zI Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 20:56:08 -0000 --089e0160b99aa97ca704f3556e90 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bjorn, Thanks for your reply, see my comments inline. On Wed, Feb 26, 2014 at 9:12 AM, Bj=F6rn Smedman < bjorn.smedman@anyfinetworks.com> wrote: > Hi Behcet, > > Thanks for your comments. > > On Tue, Feb 25, 2014 at 9:12 PM, Behcet Sarikaya > wrote: > > On Mon, Feb 24, 2014 at 4:57 PM, Bj=F6rn Smedman < > bjorn.smedman@anyfinetworks.com> wrote: > >> The CAPWAP shortcomings discussed are similar to the problems > >> preventing us [1] from using it in our Software-Defined Networking > >> (SDN) architecture for IEEE 802.11 [2]: > >> > > > > Where in IEEE 802.11 is this happening? > > Your link [2] is pointing to your company's evaluation system. > > > > As far as I know, in IEEE 802, SDN work is being pursued in 802.16. > > Our architecture is compliant with the IEEE 802.11 standard as-is, so > we've seen little reason to get involved with the IEEE so far. > > IEEE has SDN BoFs during face to face meetings to bring together all people interested in SDN, so 802.11 people also attend these meetings. > The work within 802.16 seems more focused on 802.3 SDN. Ours is an > overlay architecture based on tunneling 802.11 over IP (using our > implementation of the here proposed protocol). Think Contrail meets > the here proposed tunneling protocol and has a baby. ;) > > Long term we think the same split that you have for 802.3 SDN would > make sense: IETF standards track for the data plane tunneling protocol > (Geneve equivalent), separate standardization process for the control > plane (OpenFlow / Open Networking Foundation equivalent). > > >> 1. CAPWAP was specified before separation of data, control and > >> management planes became the norm in networking architecture. > >> Unsurprisingly it provides very little separation of concern, > >> conflating everything from firmware updates to configuration of an > >> extra SSID. > >> > >> 2. CAPWAP attempts to provide provisioning/management functionality > >> that overlaps with other IETF standards track protocols, e.g. SNMP and > >> NETCONF/YANG, as well as other established management protocols such > >> as TR-069. > >> > > > > This is good point I think. But TR-069 is not ready for prime time yet. > > With all its shortcomings it's still widely deployed for managing > residential gateways (fixed-line braodband CPE). We come across it a > great deal in the field. > > Yes it is widely used. > >> 3. The separation of data and control planes that CAPWAP does provide > >> is IMHO incorrect: 802.1X key exchange is considered part of the > >> control plane but the derived encryption keys protect the data plane. > >> This doesn't matter when both control and data plane terminate in the > >> same location (the AC), but becomes a problem when they are separated > >> (encryption keys end up in a different place than the encrypted > >> data!). > >> > >> 4. CAPWAP leaves many options open to the implementer and is therefore > >> less interoperable than desired. To some extent this can be solved > >> with run-time negotiation, but such negotiation of security critical > >> aspects (such as where encryption keys are derived and kept) makes it > >> impossible to reason about the security of the system. This is less > >> than ideal IMHO. > >> > >> 5. CAPWAP (partly due to 1 and 2 above) depends excessively on details > >> in the IEEE 802.11 standard, with each amendment threatening to impact > >> the protocol. > >> > >> > >> We would be interested in specifying a simplified tunneling protocol > >> for IEEE 802.11 similar to Geneve [3], avoiding the above problems: > >> > > > > Geneve seems to be derived from VXLAN or NVGRE. > > Is this correct? > > Yes, they're all essentially tunneling protocols for 802.3. What we're > proposing is an IETF standard tunneling protocol for 802.11. > > I checked the Geneve draft. Sorry but I could not see much difference between Geneve and VXLAN. In Geneve you have Variable Length Options but that could be added to VXLAN easily. So I don't understand your argument that Geneve (by the way I like the name in French :-) ) is for 802.11 and VXLAN is for 802.3? VXLAN is becoming an RFC, you have all the reasons to use it, rather than reinventing the wheel. I am also having trouble in how Geneve will be used? The way I understand from you is it is going to be used between AP and AC as a tunneling protocol instead of CAPWAP tunnel. Then why does an AP need a VNI? I think you are envisioning a virtualized AP in a VM? Then it makes sense. > >> A. The protocol should mandate a single well-defined partitioning of > >> the IEEE 802.11 stack, with 802.1X authentication, key management and > >> encryption all implemented at the tunnel termination point for > >> security reasons. > >> > >> B. The protocol should mandate a single well-defined frame format > >> relying only on a PHY-independent stable subset of IEEE 802.11, > >> ensuring compatibility with 11n/ac and (most likely) beyond. > >> > >> C. Like Geneve the protocol should not provide any > >> provisioning/management functionality, instead relying on SNMP, > >> NETCONF/YANG, TR-069 and similar. > >> > >> D. Like Geneve the protocol should not provide any control plane > >> functionality, instead remaining compatible with several > >> Software-Defined Networking (SDN) protocols for IEEE 802.11. > >> > > > > Any pointers on this? > > See Geneve draft section 2.1 Control Plane Independence > (http://tools.ietf.org/html/draft-gross-geneve-00#section-2.1). > > See my comments on Geneve above. > There's no explicit mention of "Management Plane Independence", e.g. > for firmware updates and similar, but I'd say it's just an implicit > requirement on a tunneling protocol, taken for granted. > > Since Management Plane is different, how do you handle that? I am confused. Regards, Behcet > >> E. Each virtual access point in a multi-BSSID (and/or multi-radio) > >> access point should be treated as a separate entity associated with a > >> separate tunnel. > >> > >> > >> We see strong benefits to such a protocol from an extensibility [4], > >> flexibility [5] and security [6] perspective. If there is interest in > >> exploring this further please let me know. > >> > >> Best regards, > >> > >> Bj=F6rn Smedman > >> > >> 1. http://www.anyfinetworks.com > >> > >> 2. http://anyfi.net and http://www.anyfinetworks.com/products > >> > >> 3. http://tools.ietf.org/html/draft-gross-geneve-00 > >> > >> 4. http://anyfi.net/documentation#architecture > >> > >> 5. http://anyfi.net/documentation#a_how_it_all_fits_together > >> > >> 6. http://anyfi.net/documentation#i_security_model > >> > >> _______________________________________________ > >> OPSAWG mailing list > >> OPSAWG@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsawg > > > > > --089e0160b99aa97ca704f3556e90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Bjorn,

Thanks for your reply, see my = comments inline.



On Wed, Feb 26, 2014 at 9:12 AM, Bj=F6rn Smedman <bjorn.smedman@anyfinetworks.com> wrote:
Hi Behcet,

Thanks for your comments.

On Tue, Feb 25, 2014 at 9:12 PM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
> On Mon, Feb 24, 2014 at 4:57 PM, Bj=F6rn Smedman <bjorn.smedman@anyfinetworks.com> w= rote:
>> The CAPWAP shortcomings discussed are simila= r to the problems
>> preventing us [1] from using it in our Software-Defined Networking=
>> (SDN) architecture for IEEE 802.11 [2]:
>>
>
> Where in IEEE 802.11 is this happening?
> Your link [2] is pointing to your company's evaluation system.
>
> As far as I know, in IEEE 802, SDN work is being pursued in 802.16.
Our architecture is compliant with the IEEE 802.11 standard as-is, so=
we've seen little reason to get involved with the IEEE so far.


IEEE has SDN BoFs during face to face = meetings to bring together all people interested in SDN, so 802.11 people a= lso attend these meetings.
=A0
The work within 802.16 seems more focused on 802.3 SDN. Ours is an
overlay architecture based on tunneling 802.11 over IP (using our
implementation of the here proposed protocol). Think Contrail meets
the here proposed tunneling protocol and has a baby. ;)

Long term we think the same split that you have for 802.3 SDN would
make sense: IETF standards track for the data plane tunneling protocol
(Geneve equivalent), separate standardization process for the control
plane (OpenFlow / Open Networking Foundation equivalent).

>> 1. CAPWAP was specified before separation of data, control and
>> management planes became the norm in networking architecture.
>> Unsurprisingly it provides very little separation of concern,
>> conflating everything from firmware updates to configuration of an=
>> extra SSID.
>>
>> 2. CAPWAP attempts to provide provisioning/management functionalit= y
>> that overlaps with other IETF standards track protocols, e.g. SNMP= and
>> NETCONF/YANG, as well as other established management protocols su= ch
>> as TR-069.
>>
>
> This is good point I think. But TR-069 is not ready for prime time yet= .

With all its shortcomings it's still widely deployed for managing=
residential gateways (fixed-line braodband CPE). We come across it a
great deal in the field.


Yes it is widely used.
= =A0
>> 3. The separation of data and control planes that CAPWAP does prov= ide
>> is IMHO incorrect: 802.1X key exchange is considered part of the >> control plane but the derived encryption keys protect the data pla= ne.
>> This doesn't matter when both control and data plane terminate= in the
>> same location (the AC), but becomes a problem when they are separa= ted
>> (encryption keys end up in a different place than the encrypted >> data!).
>>
>> 4. CAPWAP leaves many options open to the implementer and is there= fore
>> less interoperable than desired. To some extent this can be solved=
>> with run-time negotiation, but such negotiation of security critic= al
>> aspects (such as where encryption keys are derived and kept) makes= it
>> impossible to reason about the security of the system. This is les= s
>> than ideal IMHO.
>>
>> 5. CAPWAP (partly due to 1 and 2 above) depends excessively on det= ails
>> in the IEEE 802.11 standard, with each amendment threatening to im= pact
>> the protocol.
>>
>>
>> We would be interested in specifying a simplified tunneling protoc= ol
>> for IEEE 802.11 similar to Geneve [3], avoiding the above problems= :
>>
>
> Geneve seems to be derived from VXLAN or NVGRE.
> Is this correct?

Yes, they're all essentially tunneling protocols for 802.3. What = we're
proposing is an IETF standard tunneling protocol for 802.11.


I checked the Ge= neve draft. Sorry but I could not see much difference between Geneve and VX= LAN. In Geneve you have Variable Length Options but that could be added to = VXLAN easily.
So I don't understand your argument that Geneve (by the way = I like the name in French :-) ) is for 802.11 and VXLAN is for 802.3?
<= br>

VXLAN is becoming an RFC, you have all the reasons to use= it, rather than reinventing the wheel.

I am also having trouble in how Geneve will be used? The way I=20 understand from you is it is going to be used between AP and AC as a=20 tunneling protocol instead of CAPWAP tunnel.
Then why does an AP = need a VNI?
I think you are envisioning a virtualized AP in a= VM? Then it makes sense.

=A0
>> A. The protocol should mandate a single well-defined partitioning = of
>> the IEEE 802.11 stack, with 802.1X authentication, key management = and
>> encryption all implemented at the tunnel termination point for
>> security reasons.
>>
>> B. The protocol should mandate a single well-defined frame format<= br> >> relying only on a PHY-independent stable subset of IEEE 802.11, >> ensuring compatibility with 11n/ac and (most likely) beyond.
>>
>> C. Like Geneve the protocol should not provide any
>> provisioning/management functionality, instead relying on SNMP, >> NETCONF/YANG, TR-069 and similar.
>>
>> D. Like Geneve the protocol should not provide any control plane >> functionality, instead remaining compatible with several
>> Software-Defined Networking (SDN) protocols for IEEE 802.11.
>>
>
> Any pointers on this?

See Geneve draft section 2.1 Control Plane Independence
(http://tools.ietf.org/html/draft-gross-geneve-00#section-2= .1).


See my comments on Geneve above.
= =A0
There's no explicit mention of "Management Plane Independence"= ;, e.g.
for firmware updates and similar, but I'd say it's just an implicit=
requirement on a tunneling protocol, taken for granted.


Since Management Plane is different, how do you handle that? I am c= onfused.

=A0Regards,

Behcet
>> E. Each virtual access point in a multi-BSSID (and/or multi-radio)=
>> access point should be treated as a separate entity associated wit= h a
>> separate tunnel.
>>
>>
>> We see strong benefits to such a protocol from an extensibility [4= ],
>> flexibility [5] and security [6] perspective. If there is interest= in
>> exploring this further please let me know.
>>
>> Best regards,
>>
>> Bj=F6rn Smedman
>>
>> 1. http= ://www.anyfinetworks.com
>>
>> 2. http://anyfi.net= and http://www.anyfinetworks.com/products
>>
>> 3. http://tools.ietf.org/html/draft-gross-geneve-00
>>
>> 4. http://anyfi.net/documentation#architecture
>>
>> 5. http://anyfi.net/documentation#a_how_it_all_fits_t= ogether
>>
>> 6. http://anyfi.net/documentation#i_security_model
>>
>> _______________________________________________
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
>
>

--089e0160b99aa97ca704f3556e90-- From nobody Wed Feb 26 15:40: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 1E88B1A07A7 for ; Wed, 26 Feb 2014 15:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.116 X-Spam-Level: ** X-Spam-Status: No, score=2.116 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 NhraP5EMKdcV for ; Wed, 26 Feb 2014 15:40:34 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 41C3A1A01EE for ; Wed, 26 Feb 2014 15:40:34 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1QNeV75007773; Wed, 26 Feb 2014 23:40:31 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1QNeTYa007760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Feb 2014 23:40:30 GMT From: "Adrian Farrel" To: Date: Wed, 26 Feb 2014 23:40:29 -0000 Message-ID: <101901cf334c$23070f30$69152d90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8zTB0HZnQpKgOOQ8mDcKLKc5SDpA== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/TK6j30teaSA_AfufTe2_TwveumU Cc: manet-chairs@tools.ietf.org, draft-clausen-manet-olsrv2-management-snapshot@tools.ietf.org Subject: [OPSAWG] Help with a MANET management draft please X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 23:40:37 -0000 Hi OPSAWG, The MANET working group develops protocols for mobile and ad-hoc networks (some of which are less mobile or less ad hoc than others). After discussion with the IESG and specifically the OPS ADs, the WG has agreed to try to put together some thoughts on management of these networks. It's early days and the authors are not experienced in these ideas (so be gentle!) but it seems important at this stage to see whether the work is going in the right direction. Could any of you find time to review and comment (on this list, on the MANET list, direct to the authors, channelled through me)? All contributions will be gratefully received. The document is: http://datatracker.ietf.org/doc/draft-clausen-manet-olsrv2-management-snapshot/ Thanks, Adrian From nobody Wed Feb 26 18:59:56 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 6AF761A0369 for ; Wed, 26 Feb 2014 18:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.547, 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 rYDOVlxiDYRw for ; Wed, 26 Feb 2014 18:59:41 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id C4DD21A038D for ; Wed, 26 Feb 2014 18:59:40 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta12.westchester.pa.mail.comcast.net with comcast id XEwr1n0040xGWP85CEzfzC; Thu, 27 Feb 2014 02:59:39 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta12.westchester.pa.mail.comcast.net with comcast id XEzd1n00N2yZEBF3YEzdQF; Thu, 27 Feb 2014 02:59:39 +0000 From: "ietfdbh" To: , References: <101901cf334c$23070f30$69152d90$@olddog.co.uk> In-Reply-To: <101901cf334c$23070f30$69152d90$@olddog.co.uk> Date: Wed, 26 Feb 2014 21:59:35 -0500 Message-ID: <00f601cf3367$f345a6f0$d9d0f4d0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF1A5tSLHss46KxsxGtdnNREVUDRJt8v1lw Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393469979; bh=Jkb0ozphehoQMOtoYKRDSspS/vP3msGvLhkaqlyga7M=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=tV9yJ3KpeIp1vOAnhLhJ+kYm6N6hFMOxhK65jXiVemc9mjs8BLORLkQJUBeyerjxj HBPIg6CkkqEj3qBlhJ89hEZVmCBOTWeyzcZQ36c37qZm038vsykXMR+dv+LFJ89vnO zow4Y3O+yfxye8WeptW1xHeL3S5kabIGvZ4KFKvlM4Ubbn4ww9X2p5k65fbOYsHv48 F8yKvFXKzVi9rRhJmzKQGgXXvjpxgznyblXc0DwzS5LzjEhIx/i9r1HUNb+CFKiVLv ga9H3gQ64JfgdBpWLrqtdZy7NxmWD+kMsfbUYiLygose36ARAOSX+y82b7k03tho9a 7Tdcj4vDlO8ww== Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/GMAvdsJHn5Y27ZZpgxJhi28tPI0 Cc: manet-chairs@tools.ietf.org, draft-clausen-manet-olsrv2-management-snapshot@tools.ietf.org Subject: Re: [OPSAWG] Help with a MANET management draft please 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, 27 Feb 2014 02:59:45 -0000 Hi, The document claims to be a snapshot of how MANET networks are being managed now. I'm not quite sure what types of comments you want on the document, since the authors have researched and are presumably knowledgeable about current management practices for MANETs. Are you looking for comments from operators of other MANET networks to expand the documentation of existing management techniques? Or are you looking for suggestions of ways that MANETs *could* be managed differently? RFC5706 may contain ideas regarding management and monitoring of protocols, that could apply for eliciting additional input from operators about current practices, or for eliciting suggestions of management approaches that might apply to further work on management techniques that could be applied to MANETs. Given the "startup" nature of much of the MANET config, it definitely looks like Netconf/YANG might be a better choice than RW MIB modules for configuration (I suggest attending the OPSAWG meeting in London, since that is already a planned topic of conversation). Section 3 appears to be mostly about IP configuration and interface configuration; there are netmod YANG modules for this purpose. Using standardized management would likely improve interoperability, if interoperability is important. It may not seem that important for deployment for internal management, but having a consistent management interface for an NMS to use to debug internal deployments could be awfully helpful to operators. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian > Farrel > Sent: Wednesday, February 26, 2014 6:40 PM > To: Opsawg@ietf.org > Cc: manet-chairs@tools.ietf.org; draft-clausen-manet-olsrv2-management- > snapshot@tools.ietf.org > Subject: [OPSAWG] Help with a MANET management draft please > > Hi OPSAWG, > > The MANET working group develops protocols for mobile and ad-hoc > networks (some > of which are less mobile or less ad hoc than others). > > After discussion with the IESG and specifically the OPS ADs, the WG has > agreed > to try to put together some thoughts on management of these networks. > > It's early days and the authors are not experienced in these ideas (so be > gentle!) but it seems important at this stage to see whether the work is going > in the right direction. > > Could any of you find time to review and comment (on this list, on the > MANET > list, direct to the authors, channelled through me)? All contributions will be > gratefully received. > > The document is: > http://datatracker.ietf.org/doc/draft-clausen-manet-olsrv2-management- > snapshot/ > > Thanks, > Adrian > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Feb 26 23:07:13 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 8A7A11A0706 for ; Wed, 26 Feb 2014 23:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 ovbkt4GEZcoA for ; Wed, 26 Feb 2014 23:07:08 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id B16761A045C for ; Wed, 26 Feb 2014 23:07:08 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7ECC916EC; Thu, 27 Feb 2014 08:07:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dSWlKz5KB_Pz; Thu, 27 Feb 2014 08:07:05 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 27 Feb 2014 08:07:05 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D10E20054; Thu, 27 Feb 2014 08:07:05 +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 b4e5mB5v_ZEn; Thu, 27 Feb 2014 08:07:04 +0100 (CET) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAD6020048; Thu, 27 Feb 2014 08:07:02 +0100 (CET) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id CA0352B7E092; Thu, 27 Feb 2014 08:07:00 +0100 (CET) Date: Thu, 27 Feb 2014 08:07:00 +0100 From: Juergen Schoenwaelder To: Adrian Farrel Message-ID: <20140227070700.GA8623@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Adrian Farrel , Opsawg@ietf.org, manet-chairs@tools.ietf.org, draft-clausen-manet-olsrv2-management-snapshot@tools.ietf.org References: <101901cf334c$23070f30$69152d90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <101901cf334c$23070f30$69152d90$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/74h9LZ1ALb5LG0M_B1F-Vorwcxk Cc: manet-chairs@tools.ietf.org, Opsawg@ietf.org, draft-clausen-manet-olsrv2-management-snapshot@tools.ietf.org Subject: Re: [OPSAWG] Help with a MANET management draft please 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, 27 Feb 2014 07:07:11 -0000 On Wed, Feb 26, 2014 at 11:40:29PM +0000, Adrian Farrel wrote: > Could any of you find time to review and comment (on this list, on > the MANET list, direct to the authors, channelled through me)? All > contributions will be gratefully received. Out of curiosity, I would like to understand what the background behind these statements is: "protocols such as SNMP (or possibly other, less "chatty", protocols)." In some deployments, the NMS communicates with individual routers by way of SNMP - and, more commonly, by way of "proprietary" simpler, less verbose and (often) less secure protocols, and over UDP. Any pointers to such proprietary protocols? I am just wondering what the network management communication patterns are that take place in MANETs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 27 02:15:14 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 674231A07EF for ; Thu, 27 Feb 2014 02:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 oKB7OdN0p6JE for ; Thu, 27 Feb 2014 02:15:10 -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 F2B081A07DE for ; Thu, 27 Feb 2014 02:15:09 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALUPD1OHCzIm/2dsb2JhbABagmUhO1fAOU+BGRZ0giUBAQEBAwEBAQ8oNBcEAgEIDQQEAQELFAkHJwsUCQgCBBMIGodXAQyebatXF44jOAaDHYEUBJlqhUCLN4Mtgio X-IronPort-AV: E=Sophos;i="4.97,553,1389762000"; d="scan'208";a="44486284" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Feb 2014 05:15:07 -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; 27 Feb 2014 05:01:53 -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.0174.001; Thu, 27 Feb 2014 11:15:05 +0100 From: "Romascanu, Dan (Dan)" To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] Milestones changed for opsawg WG Thread-Index: AQHPMwww6nUu8XL310SXKWF+/OIt5ZrI4uOg Date: Thu, 27 Feb 2014 10:15:04 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E43B47F@AZ-FFEXMB04.global.avaya.com> References: <20140225183218.32070.74825.idtracker@ietfa.amsl.com> In-Reply-To: <20140225183218.32070.74825.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/gMY5Xg-hwiv6Lv8plvoWLyfBoJg Subject: Re: [OPSAWG] Milestones changed for opsawg WG 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, 27 Feb 2014 10:15:12 -0000 Hi, There are a number of documents already adopted by the OPSAWG as WG documen= ts that do not show up in the milestones. For example the VMM MIB, the *com= an*, the *capwap* documents. Should not these also be added in the mileston= es list?=20 Regards, Dan > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of IETF > Secretariat > Sent: Tuesday, February 25, 2014 8:32 PM > To: opsawg@ietf.org > Subject: [OPSAWG] Milestones changed for opsawg WG >=20 > Changed milestone "Initial submission for the 'IF-CAP-STACK-MIB MIB > module' Internet-Draft", resolved as "Done", added draft-ietf-opsawg- > rfc5066bis to milestone. >=20 > Changed milestone "Submit the 'IF-CAP-STACK-MIB MIB module' > Internet-Draft to the IESG for consideration as Proposed Standard", resol= ved > as "Done", added draft-ietf-opsawg-rfc5066bis to milestone. >=20 > URL: http://datatracker.ietf.org/wg/opsawg/charter/ >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Feb 27 05:31:15 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 4F19E1A028E for ; Thu, 27 Feb 2014 05:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 3nxPe4n_3llW for ; Thu, 27 Feb 2014 05:29:22 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8691A021A for ; Thu, 27 Feb 2014 05:29:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45479240433; Thu, 27 Feb 2014 05:29:21 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 51C2D24034A; Thu, 27 Feb 2014 05:29:17 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2198CB12-4106-438F-A0D7-0274E2084BA5" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <00f601cf3367$f345a6f0$d9d0f4d0$@comcast.net> Date: Thu, 27 Feb 2014 14:29:15 +0100 Message-Id: References: <101901cf334c$23070f30$69152d90$@olddog.co.uk> <00f601cf3367$f345a6f0$d9d0f4d0$@comcast.net> To: ietfdbh X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/-uUWFgxE32LRCPTpTMMLsg8Doz0 X-Mailman-Approved-At: Thu, 27 Feb 2014 05:31:13 -0800 Cc: "" , Opsawg@ietf.org, draft-clausen-manet-olsrv2-management-snapshot@tools.ietf.org Subject: Re: [OPSAWG] Help with a MANET management draft please 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, 27 Feb 2014 13:29:26 -0000 --Apple-Mail=_2198CB12-4106-438F-A0D7-0274E2084BA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello David, Thank you for your remarks, and for engaging with & educating us here. = It's really appreciated. Comments below.... On 27 Feb 2014, at 03:59, ietfdbh wrote: > Hi, >=20 > The document claims to be a snapshot of how MANET networks are being = managed > now. More specifically, how MANETs running OLSR(v1 or v2) as routing protocol = are being managed. > I'm not quite sure what types of comments you want on the document, = since > the authors have researched and are presumably knowledgeable about = current > management practices for MANETs. We actually do not claim to document what is done in MANETs in general - = there are routing protocols other than OLSR(v1 or v2) out there, albeit = less widely deployed, which are operating with a very different = architecture, and which the authors of this document suspect would have = (in some cases, significantly) different management practices. > Are you looking for comments from operators of other MANET networks to > expand the documentation of existing management techniques? > Or are you looking for suggestions of ways that MANETs *could* be = managed > differently? Good question ;) This document came to be as the OPS ADs asked us to "document how you're = actually currently managing MANETs", as part of their processing of MIBs = for the different protocols (notably OLSRv2 and NHDP - which is a = constituent, but independent, protocol to OLSRv2). One of the triggering = comments was from Benoit Claise (can't find a public link to quote him, = so it may have been in a conversation), another was Ron Bonica's (which = is in the tracker for what became RFC6779 here: = https://datatracker.ietf.org/doc/rfc6779/ballot/): This document fails to provide use cases. Because it doesn't = provide use cases, it is not clear that any/all of its objects are useful. While this comment might be leveled concerning regarding MIB, it = is particularly applicable in this case because we have so little = operational experience with ad hoc networks. Will the ad hoc network include = a NOC? What policy will that NOC attempt to enforce? What = information/control will the NOC need to enforce that policy. So, we set forth to document what we know about how the ad hoc networks = that we know are actually being managed, asking those building/operating = such networks, and trying to generalise from that. There are actually = quite a few operators of "highly managed ad hoc networks" out there - = sadly, those networks are typically "tactical networks" and so it is = rather difficult to get their operators to be particularly forthcoming = about specifics... Therefore, in part, the question that we would like to ask from the OPS = experts is: does this document make any sense to you? Is what's in there = of any (educational, or otherwise) value? Anything that you feel is = missing, or where more information would be helpful? With reference to = Ron's comment quoted above, does this document provide necessary context = for understanding what may come out of the MANET wg in an operational = frame? Now, if opsawg has a bunch of stealthy MANET operators subscribed, whom = we do not know about already, then we'd *love* to make friends get = comments and feedback as to how they're doing things. So please, anyone = with MANET experience do come forward.... And yes, any suggestions as to "how can we do better/differently?" are = always highly welcome. We're just routing guys, who recognise the need = for network management - but, who also recognise that we just are = routing guys and that we better be attentive to domain-expert advice. > RFC5706 may contain ideas regarding management and monitoring of = protocols, > that could apply for eliciting additional input from operators about = current > practices, or for eliciting suggestions of management approaches that = might > apply to further work on management techniques that could be applied = to > MANETs. Now, THAT was an RFC that I wasn't aware of, but which seems (after a = quick skim-through) to be hugely interesting. I'll definitely give that = a careful read-through on my way to London. Thank you for that pointer.=20= > Given the "startup" nature of much of the MANET config, it definitely = looks > like Netconf/YANG might be a better choice than RW MIB modules for > configuration (I suggest attending the OPSAWG meeting in London, since = that > is already a planned topic of conversation). And again, that was a very good pointer, and I'll make sure to be there. = Thanks. Now, there's something to be said for the way in which we designed = OLSRv2: essentially, ad-hoc networks are intended to be very = "autonomous", that's how they often are deployed.=20 There's very little that *requires* global agreement (off the top of my = head, three things: the value of C, cryptographic material, and = interface address configuration) for correct operation of a network. The = protocol is designed to be accommodating to heterogeneity of pretty much = everything else. Of course, for *efficient* operation, one will want if = not global agreement, then at least a way of affecting other parameters = in the routers - and this over time, as the network evolves (e.g., = devices start to move about, or settle down, or the environment changes, = etc.). So yes, while all the "required config" probably is startup config, = there is a need for also being able to configure (and, certainly, = monitor) the network while in continued operation. > Section 3 appears to be mostly about IP configuration and interface > configuration; there are netmod YANG modules for this purpose.=20 I have actually only passing familiarity with YANG, so I will have to go = look at that in more details, also, in preparation of London. > Using standardized management would likely improve interoperability, = if > interoperability is important. It may not seem that important for = deployment > for internal management, but having a consistent management interface = for an > NMS to use to debug internal deployments could be awfully helpful to > operators. Interoperability is hugely important (otherwise, we'd not bother going = through the hoops, expenses, and frustrations, of standardising). The back-story (which we kinda allude to, but which really is not worth = telling in detail in the document, since I expect that it's quite = classic) is, that in the past we had no standardised ways of a NMS = interacting with an OLSR instance. Consequently, we saw each = implementation of OLSR come with its own (if any, that is) more or less = wicked "interface" (examples include using Java RMI, Sun RPC, a TCP = socket with 'untraditional' textual commands, ...) and = exposing/expecting data in more or less wicked formats and amounts, and = towards "custom" NMSes, visualisation tools, etc. Not throwing any = stones here - I believe that my initial implementation of a "management = interface" to an OLSR instance takes the price of being "the most wicked = of the bunch" - just observing how it was. Operationally, that's not good - and, even for our interop events, that = has occasionally been a difficulty - or, at least, it would have = simplified life greatly had we all had identical interfaces and = information exposure. That's what motivated us to dig in and develop MIB = modules and the likes. Again, thanks for your interest and guidance, it is hugely appreciated, = and - I think I can speak for both the authors - we're eager to learn = from all y'all. Best, Thomas >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >> -----Original Message----- >> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian >> Farrel >> Sent: Wednesday, February 26, 2014 6:40 PM >> To: Opsawg@ietf.org >> Cc: manet-chairs@tools.ietf.org; = draft-clausen-manet-olsrv2-management- >> snapshot@tools.ietf.org >> Subject: [OPSAWG] Help with a MANET management draft please >>=20 >> Hi OPSAWG, >>=20 >> The MANET working group develops protocols for mobile and ad-hoc >> networks (some >> of which are less mobile or less ad hoc than others). >>=20 >> After discussion with the IESG and specifically the OPS ADs, the WG = has >> agreed >> to try to put together some thoughts on management of these networks. >>=20 >> It's early days and the authors are not experienced in these ideas = (so be >> gentle!) but it seems important at this stage to see whether the work = is > going >> in the right direction. >>=20 >> Could any of you find time to review and comment (on this list, on = the >> MANET >> list, direct to the authors, channelled through me)? All = contributions > will be >> gratefully received. >>=20 >> The document is: >> = http://datatracker.ietf.org/doc/draft-clausen-manet-olsrv2-management- >> snapshot/ >>=20 >> Thanks, >> Adrian >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >=20 --Apple-Mail=_2198CB12-4106-438F-A0D7-0274E2084BA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = David,

Thank you for your remarks, and for engaging = with & educating us here. It's really appreciated. Comments = below....

On 27 Feb 2014, at 03:59, ietfdbh = <ietfdbh@comcast.net> = wrote:

Hi,

The document claims to be a snapshot of how = MANET networks are being = managed
now.

More specifically, how = MANETs running OLSR(v1 or v2) as routing protocol are being = managed.

I'm not quite sure what = types of comments you want on the document, since
the authors have = researched and are presumably knowledgeable about current
management = practices for MANETs.

We actually do not = claim to document what is done in MANETs in general - there are routing = protocols other than OLSR(v1 or v2) out there, albeit less widely = deployed, which are operating with a very different architecture, and = which the authors of this document suspect would have (in some cases, = significantly) different management practices.

Are you looking for comments from operators of other MANET = networks to
expand the documentation of existing management = techniques?
Or are you looking for suggestions of ways that MANETs = *could* be managed
differently?

Good = question ;)

This document came to be = as the OPS ADs asked us to "document how you're actually currently = managing MANETs", as part of their processing of MIBs for the different = protocols (notably OLSRv2 and NHDP - which is a constituent, but = independent, protocol to OLSRv2). One of the triggering comments was = from Benoit Claise (can't find a public link to quote him, so it may = have been in a conversation), another was Ron Bonica's (which is in the = tracker for what became RFC6779 here: https://datatrac= ker.ietf.org/doc/rfc6779/ballot/):

	This document fails to provide =
use cases. Because it doesn't provide use cases,
	it is not clear that any/all of =
its objects are useful.

	While this comment might be =
leveled concerning regarding MIB, it is
	particularly applicable in this =
case because we have so little operational
	experience with ad hoc networks. =
Will the ad hoc network include a NOC? What
	policy will that NOC attempt to =
enforce? What information/control will the NOC
	need to enforce that =
policy.
So, we set forth to document what we know about = how the ad hoc networks that we know are actually being managed, asking = those building/operating such networks, and trying to generalise from = that. There are actually quite a few operators of "highly managed ad hoc = networks" out there - sadly, those networks are typically "tactical = networks" and so it is rather difficult to get their operators to be = particularly forthcoming about = specifics...

Therefore, in part, the question = that we would like to ask from the OPS experts is: does this document = make any sense to you? Is what's in there of any (educational, or = otherwise) value? Anything that you feel is missing, or where more = information would be helpful? With reference to Ron's comment quoted = above, does this document provide necessary context for understanding = what may come out of the MANET wg in an operational = frame?

Now, if opsawg has a bunch of = stealthy MANET operators subscribed, whom we do not know about already, = then we'd *love* to make friends get comments and feedback as to how = they're doing things. So please, anyone with MANET experience do come = forward....

And yes, any suggestions as to "how = can we do better/differently?" are always highly welcome. We're just = routing guys, who recognise the need for network management - but, who = also recognise that we just are routing guys and that we better be = attentive to domain-expert advice.

RFC5706 may contain ideas regarding management and = monitoring of protocols,
that could apply for eliciting additional = input from operators about current
practices, or for eliciting = suggestions of management approaches that might
apply to further work = on management techniques that could be applied = to
MANETs.

Now, THAT was an RFC that I = wasn't aware of, but which seems (after a quick skim-through) to be = hugely interesting. I'll definitely give that a careful read-through on = my way to London. Thank you for that = pointer. 

Given the = "startup" nature of much of the MANET config, it definitely = looks
like Netconf/YANG might be a better choice than RW MIB modules = for
configuration (I suggest attending the OPSAWG meeting in London, = since that
is already a planned topic of = conversation).

And again, that was a very = good pointer, and I'll make sure to be there. = Thanks.

Now, there's something to be said for = the way in which we designed OLSRv2: essentially, ad-hoc networks are = intended to be very "autonomous", that's how they often are = deployed. 

There's very little that = *requires* global agreement (off the top of my head, three things: the = value of C, cryptographic material, and interface address configuration) = for correct operation of a network. The protocol is designed to be = accommodating to heterogeneity of pretty much everything else. Of = course, for *efficient* operation, one will want if not global = agreement, then at least a way of affecting other parameters in the = routers - and this over time, as the network evolves (e.g., devices = start to move about, or settle down, or the environment changes, = etc.).

So yes, while all the "required config" = probably is startup config, there is a need for also being able to = configure (and, certainly, monitor) the network while in continued = operation.

Section 3 appears to = be mostly about IP configuration and interface
configuration; there = are netmod YANG modules for this purpose. =

I have actually only passing = familiarity with YANG, so I will have to go look at that in more = details, also, in preparation of London.

Using standardized management would likely improve = interoperability, if
interoperability is important. It may not seem = that important for deployment
for internal management, but having a = consistent management interface for an
NMS to use to debug internal = deployments could be awfully helpful = to
operators.

Interoperability is = hugely important (otherwise, we'd not bother going through the hoops, = expenses, and frustrations, of = standardising).

The back-story (which we kinda = allude to, but which really is not worth telling in detail in the = document, since I expect that it's quite classic) is, that in the past = we had no standardised ways of a NMS interacting with an OLSR instance. = Consequently, we saw each implementation of OLSR come with its own (if = any, that is) more or less wicked "interface" (examples include using = Java RMI, Sun RPC, a TCP socket with 'untraditional' textual commands, = ...) and exposing/expecting data in more or less wicked formats and = amounts, and towards "custom" NMSes, visualisation tools, etc. Not = throwing any stones here - I believe that my initial implementation of a = "management interface" to an OLSR instance takes the price of being "the = most wicked of the bunch" - just observing how it = was.

Operationally, that's not good - and, even = for our interop events, that has occasionally been a difficulty - or, at = least, it would have simplified life greatly had we all had identical = interfaces and information exposure. That's what motivated us to dig in = and develop MIB modules and the likes.

Again, = thanks for your interest and guidance, it is hugely appreciated, and - I = think I can speak for both the authors - we're eager to learn from all = y'all.

Best,

Thomas


David Harrington
ietfdbh@comcast.net
+1-603-828-= 1401
-----Original Message-----
From: = OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of = Adrian
Farrel
Sent: Wednesday, February 26, 2014 6:40 PM
To: = Opsawg@ietf.org
Cc: manet-chairs@tools.ietf.org; = draft-clausen-manet-olsrv2-management-
snapshot@tools.ietf.org
Subje= ct: [OPSAWG] Help with a MANET management draft please

Hi = OPSAWG,

The MANET working group develops protocols for mobile and = ad-hoc
networks (some
of which are less mobile or less ad hoc than = others).

After discussion with the IESG and specifically the OPS = ADs, the WG has
agreed
to try to put together some thoughts on = management of these networks.

It's early days and the authors are = not experienced in these ideas (so be
gentle!) but it seems important = at this stage to see whether the work = is
going
in the right = direction.

Could any of you find time to review and comment (on = this list, on the
MANET
list, direct to the authors, channelled = through me)? All contributions
will be
gratefully received.

The document = is:
http://datatracker.ietf.org/doc/draft-clausen-manet-olsrv2-manageme= nt-
snapshot/

Thanks,
Adrian

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


= --Apple-Mail=_2198CB12-4106-438F-A0D7-0274E2084BA5-- From nobody Thu Feb 27 06:17: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 CD0741A01E8 for ; Thu, 27 Feb 2014 06:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 wIhwgkQY2DJc for ; Thu, 27 Feb 2014 06:17:33 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 473CD1A02C6 for ; Thu, 27 Feb 2014 06:17:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 17060240472; Thu, 27 Feb 2014 06:17:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6BE7D240433; Thu, 27 Feb 2014 06:17:29 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <20140227070700.GA8623@elstar.jacobs.jacobs-university.de> Date: Thu, 27 Feb 2014 15:17:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <101901cf334c$23070f30$69152d90$@olddog.co.uk> <20140227070700.GA8623@elstar.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/FvnBFcEX58GG6Rb2LM8_HQqB6UE Cc: "" , Opsawg@ietf.org, draft-clausen-manet-olsrv2-management-snapshot@tools.ietf.org Subject: Re: [OPSAWG] Help with a MANET management draft please 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, 27 Feb 2014 14:17:40 -0000 Dear Juergen, On 27 Feb 2014, at 08:07, Juergen Schoenwaelder = wrote: > On Wed, Feb 26, 2014 at 11:40:29PM +0000, Adrian Farrel wrote: >=20 >> Could any of you find time to review and comment (on this list, on >> the MANET list, direct to the authors, channelled through me)? All >> contributions will be gratefully received. >=20 > Out of curiosity, I would like to understand what the background > behind these statements is: >=20 > "protocols such as SNMP (or possibly other, less "chatty", > protocols)." >=20 > In some deployments, the NMS communicates with individual routers by > way of SNMP - and, more commonly, by way of "proprietary" simpler, > less verbose and (often) less secure protocols, and over UDP. >=20 > Any pointers to such proprietary protocols? I am just wondering what > the network management communication patterns are that take place in > MANETs. I would love to be able to provide a pointer, but that's unfortunately = the nature of "proprietary": I can't. I actually do not believe that = there's any "de-facto standard" or "commonly used proprietary protocol" = out there, more a matter of each implementer of OLSR (v1 and v2, both) = set out realising the need for interacting with a running OLSR instance, = and coming up with his/her own approach depending on ad-hoc needs. = Heck, I don't think I've actually seen a written documentation of these = "proprietary" protocols, except for their code.... Initially, what we saw was in the numerous OLSR interop's we've held, = where we saw a remarkable number of visualisation tools, for example, = depicting the evolution of the network topology (caveat: routers in a = MANET are likely to move about), or tools permitting to temporarily = provoke a "failure-like event" in a router to be able to observe how the = surrounding network behaves - with instrumenting routers to record and = reflect their behaviours. Tools, that is, communicating with the = protocol instance in whatever way the implementer saw fit to build, = since there was no commonly agreed-upon, documented, way. But, you do make a good point which is - I think - that it might be = helpful to document what the (management) communications patterns may = look like in an operating (post-startup) network. I think that that = probably is a good idea, so we'll definitely see about that in a coming = revision of the document, thank you for that suggestion! I'll throw a few thoughts - without claiming to be exhaustive - out = below as what I see in the networks that I know of and know very well, = that happens "often" - note, this is just in what *I* see, not what = *everybody* sees or what everybody may wish to see happen: a) Inquire the state (complete topology graph, link states, = local links even if not part of topology graph) of a router Often, this is getting "up to a few KB worth of data" = back It's not a very common operation. b) Inquire the history/statistics of a router This is typically something tiny, like "how many local = link changes have you seen within the past n minutes/seconds/hours" This may be very rare, or it may be several times per = minute per router for a while: if my NMS is trying to "tune" message=20 intervals and timers, it may be a case of "doing this to = a group of topologically close routers" - until, that is, the NMS = decides that it's happy with what it sees and will ease up c) Change the configuration of a router Other than in the above case (tuning) this really = happens only when somehow I get a new uplink to an external network, and I either need to throw a new gateway into the = network, and/or I need to get a new prefix out to the routers. d) Visualising the network as a router sees it. Note that as in a MANET, routers do move about, this may = mean that the topology changes frequently. In a naive way, this would essentially be the NMS setting up a connection to the = router in question, and "getting a copy of all routing protocol control messages" to construct its own topology graph as = would have done that router. Typically, it consists of the router = sending a=20 notification to the NMS when a topological change = happens, i.e., when either of its information bases change. Even better, = it consists of these notifications being "filtered" to only = send for those changes that actually impact the usable topology. e) Rekeying - we do not actually have a (standard) = mechanism for AKM, and I maintain that it probably is not possible to = come up with a single such that will satisfy the requirements = for all the different deployments, but it's still something that we do = play with. I'm actually doing that as part of a management = operation and schlepping it around as I would any configuration = parameter (not saying that it's the right thing to do, though, = just what I'm playing with). The particularity of this is, that it often = is a "broadcast configuration operation" where you want to get new = material to everybody, and not just a single device. Some of the proprietary stuff that has been done (and which I have done) = in the past, can be explained easily by the above, and by the fact that = in OLSR (v1 and v2) we have really efficient flooding operations in = place. This can (and has) be used to do e) much much more efficiently (& = reliably) than a bunch of unicasts. For b), too, in case we want to = configure a "group of topologically close routers": unicast to one of = them (topologically as central as possible) and then use scope-limited = optimized flooding to reach the surrounding routers. As for d), the = opportunities are endless for thinking up ways to do that... Moving towards standardized data representations, such as the MIBs, as = well as some of the interesting developments by Bob Cole (REPORT-MIB - = http://tools.ietf.org/html/draft-ietf-manet-report-mib - yes, it is = expired, but we need to revive that, I think) are steps that we're = trying to take to exit the world of "ad-hoc" management solutions. =20 Not sure if that's a useful answer to your question? I am sorry that I = can't point to some neatly written up whitepaper, which clearly would = have been a better answer. Either way, your question is good and it might make sense to mull a bit = on that and try to capture a more complete answer to it than what I = provided in the above in the document? Tsch=FC=DF, Thomas > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Thu Feb 27 06:18: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 055F31A028D for ; Thu, 27 Feb 2014 06:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 kVaHabmlS_6A for ; Thu, 27 Feb 2014 06:18:28 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id ABAE31A01E8 for ; Thu, 27 Feb 2014 06:18:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7A65E240433; Thu, 27 Feb 2014 06:18:27 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8B16B240348; Thu, 27 Feb 2014 06:18:24 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9CAC43C5-E154-483B-8437-85D6D654DAD1" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <00f601cf3367$f345a6f0$d9d0f4d0$@comcast.net> Date: Thu, 27 Feb 2014 15:18:23 +0100 Message-Id: References: <101901cf334c$23070f30$69152d90$@olddog.co.uk> <00f601cf3367$f345a6f0$d9d0f4d0$@comcast.net> To: ietfdbh X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/MuXrVQHbySHgjdq8zAaEu1-CyDA Cc: "" , Opsawg@ietf.org, draft-clausen-manet-olsrv2-management-snapshot@tools.ietf.org Subject: Re: [OPSAWG] Help with a MANET management draft please 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, 27 Feb 2014 14:18:32 -0000 --Apple-Mail=_9CAC43C5-E154-483B-8437-85D6D654DAD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (Apologies for the double-posting to some of you; I realized that I had = not subscribed to opsawg so I am resending) Hello David, Thank you for your remarks, and for engaging with & educating us here. = It's really appreciated. Comments below.... On 27 Feb 2014, at 03:59, ietfdbh wrote: > Hi, >=20 > The document claims to be a snapshot of how MANET networks are being = managed > now. More specifically, how MANETs running OLSR(v1 or v2) as routing protocol = are being managed. > I'm not quite sure what types of comments you want on the document, = since > the authors have researched and are presumably knowledgeable about = current > management practices for MANETs. We actually do not claim to document what is done in MANETs in general - = there are routing protocols other than OLSR(v1 or v2) out there, albeit = less widely deployed, which are operating with a very different = architecture, and which the authors of this document suspect would have = (in some cases, significantly) different management practices. > Are you looking for comments from operators of other MANET networks to > expand the documentation of existing management techniques? > Or are you looking for suggestions of ways that MANETs *could* be = managed > differently? Good question ;) This document came to be as the OPS ADs asked us to "document how you're = actually currently managing MANETs", as part of their processing of MIBs = for the different protocols (notably OLSRv2 and NHDP - which is a = constituent, but independent, protocol to OLSRv2). One of the triggering = comments was from Benoit Claise (can't find a public link to quote him, = so it may have been in a conversation), another was Ron Bonica's (which = is in the tracker for what became RFC6779 here: = https://datatracker.ietf.org/doc/rfc6779/ballot/): This document fails to provide use cases. Because it doesn't = provide use cases, it is not clear that any/all of its objects are useful. While this comment might be leveled concerning regarding MIB, it = is particularly applicable in this case because we have so little = operational experience with ad hoc networks. Will the ad hoc network include = a NOC? What policy will that NOC attempt to enforce? What = information/control will the NOC need to enforce that policy. So, we set forth to document what we know about how the ad hoc networks = that we know are actually being managed, asking those building/operating = such networks, and trying to generalise from that. There are actually = quite a few operators of "highly managed ad hoc networks" out there - = sadly, those networks are typically "tactical networks" and so it is = rather difficult to get their operators to be particularly forthcoming = about specifics... Therefore, in part, the question that we would like to ask from the OPS = experts is: does this document make any sense to you? Is what's in there = of any (educational, or otherwise) value? Anything that you feel is = missing, or where more information would be helpful? With reference to = Ron's comment quoted above, does this document provide necessary context = for understanding what may come out of the MANET wg in an operational = frame? Now, if opsawg has a bunch of stealthy MANET operators subscribed, whom = we do not know about already, then we'd *love* to make friends get = comments and feedback as to how they're doing things. So please, anyone = with MANET experience do come forward.... And yes, any suggestions as to "how can we do better/differently?" are = always highly welcome. We're just routing guys, who recognise the need = for network management - but, who also recognise that we just are = routing guys and that we better be attentive to domain-expert advice. > RFC5706 may contain ideas regarding management and monitoring of = protocols, > that could apply for eliciting additional input from operators about = current > practices, or for eliciting suggestions of management approaches that = might > apply to further work on management techniques that could be applied = to > MANETs. Now, THAT was an RFC that I wasn't aware of, but which seems (after a = quick skim-through) to be hugely interesting. I'll definitely give that = a careful read-through on my way to London. Thank you for that pointer.=20= > Given the "startup" nature of much of the MANET config, it definitely = looks > like Netconf/YANG might be a better choice than RW MIB modules for > configuration (I suggest attending the OPSAWG meeting in London, since = that > is already a planned topic of conversation). And again, that was a very good pointer, and I'll make sure to be there. = Thanks. Now, there's something to be said for the way in which we designed = OLSRv2: essentially, ad-hoc networks are intended to be very = "autonomous", that's how they often are deployed.=20 There's very little that *requires* global agreement (off the top of my = head, three things: the value of C, cryptographic material, and = interface address configuration) for correct operation of a network. The = protocol is designed to be accommodating to heterogeneity of pretty much = everything else. Of course, for *efficient* operation, one will want if = not global agreement, then at least a way of affecting other parameters = in the routers - and this over time, as the network evolves (e.g., = devices start to move about, or settle down, or the environment changes, = etc.). So yes, while all the "required config" probably is startup config, = there is a need for also being able to configure (and, certainly, = monitor) the network while in continued operation. > Section 3 appears to be mostly about IP configuration and interface > configuration; there are netmod YANG modules for this purpose.=20 I have actually only passing familiarity with YANG, so I will have to go = look at that in more details, also, in preparation of London. > Using standardized management would likely improve interoperability, = if > interoperability is important. It may not seem that important for = deployment > for internal management, but having a consistent management interface = for an > NMS to use to debug internal deployments could be awfully helpful to > operators. Interoperability is hugely important (otherwise, we'd not bother going = through the hoops, expenses, and frustrations, of standardising). The back-story (which we kinda allude to, but which really is not worth = telling in detail in the document, since I expect that it's quite = classic) is, that in the past we had no standardised ways of a NMS = interacting with an OLSR instance. Consequently, we saw each = implementation of OLSR come with its own (if any, that is) more or less = wicked "interface" (examples include using Java RMI, Sun RPC, a TCP = socket with 'untraditional' textual commands, ...) and = exposing/expecting data in more or less wicked formats and amounts, and = towards "custom" NMSes, visualisation tools, etc. Not throwing any = stones here - I believe that my initial implementation of a "management = interface" to an OLSR instance takes the price of being "the most wicked = of the bunch" - just observing how it was. Operationally, that's not good - and, even for our interop events, that = has occasionally been a difficulty - or, at least, it would have = simplified life greatly had we all had identical interfaces and = information exposure. That's what motivated us to dig in and develop MIB = modules and the likes. Again, thanks for your interest and guidance, it is hugely appreciated, = and - I think I can speak for both the authors - we're eager to learn = from all y'all. Best, Thomas >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >> -----Original Message----- >> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian >> Farrel >> Sent: Wednesday, February 26, 2014 6:40 PM >> To: Opsawg@ietf.org >> Cc: manet-chairs@tools.ietf.org; = draft-clausen-manet-olsrv2-management- >> snapshot@tools.ietf.org >> Subject: [OPSAWG] Help with a MANET management draft please >>=20 >> Hi OPSAWG, >>=20 >> The MANET working group develops protocols for mobile and ad-hoc >> networks (some >> of which are less mobile or less ad hoc than others). >>=20 >> After discussion with the IESG and specifically the OPS ADs, the WG = has >> agreed >> to try to put together some thoughts on management of these networks. >>=20 >> It's early days and the authors are not experienced in these ideas = (so be >> gentle!) but it seems important at this stage to see whether the work = is > going >> in the right direction. >>=20 >> Could any of you find time to review and comment (on this list, on = the >> MANET >> list, direct to the authors, channelled through me)? All = contributions > will be >> gratefully received. >>=20 >> The document is: >> = http://datatracker.ietf.org/doc/draft-clausen-manet-olsrv2-management- >> snapshot/ >>=20 >> Thanks, >> Adrian >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >=20 --Apple-Mail=_9CAC43C5-E154-483B-8437-85D6D654DAD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
(Apologies for the double-posting to some of = you; I realized that I had not subscribed to opsawg so I am = resending)

Hello David,

Thank you = for your remarks, and for engaging with & educating us here. It's = really appreciated. Comments below....

On 27 Feb = 2014, at 03:59, ietfdbh <ietfdbh@comcast.net> = wrote:

Hi,

The document claims to be a snapshot of how = MANET networks are being = managed
now.

More specifically, how = MANETs running OLSR(v1 or v2) as routing protocol are being = managed.

I'm not quite sure what = types of comments you want on the document, since
the authors have = researched and are presumably knowledgeable about current
management = practices for MANETs.

We actually do not = claim to document what is done in MANETs in general - there are routing = protocols other than OLSR(v1 or v2) out there, albeit less widely = deployed, which are operating with a very different architecture, and = which the authors of this document suspect would have (in some cases, = significantly) different management practices.

Are you looking for comments from operators of other MANET = networks to
expand the documentation of existing management = techniques?
Or are you looking for suggestions of ways that MANETs = *could* be managed
differently?

Good = question ;)

This document came to be = as the OPS ADs asked us to "document how you're actually currently = managing MANETs", as part of their processing of MIBs for the different = protocols (notably OLSRv2 and NHDP - which is a constituent, but = independent, protocol to OLSRv2). One of the triggering comments was = from Benoit Claise (can't find a public link to quote him, so it may = have been in a conversation), another was Ron Bonica's (which is in the = tracker for what became RFC6779 here: https://datatrac= ker.ietf.org/doc/rfc6779/ballot/):

	This document fails to provide =
use cases. Because it doesn't provide use cases,
	it is not clear that any/all of =
its objects are useful.

	While this comment might be =
leveled concerning regarding MIB, it is
	particularly applicable in this =
case because we have so little operational
	experience with ad hoc networks. =
Will the ad hoc network include a NOC? What
	policy will that NOC attempt to =
enforce? What information/control will the NOC
	need to enforce that =
policy.
So, we set forth to document what we know about = how the ad hoc networks that we know are actually being managed, asking = those building/operating such networks, and trying to generalise from = that. There are actually quite a few operators of "highly managed ad hoc = networks" out there - sadly, those networks are typically "tactical = networks" and so it is rather difficult to get their operators to be = particularly forthcoming about = specifics...

Therefore, in part, the question = that we would like to ask from the OPS experts is: does this document = make any sense to you? Is what's in there of any (educational, or = otherwise) value? Anything that you feel is missing, or where more = information would be helpful? With reference to Ron's comment quoted = above, does this document provide necessary context for understanding = what may come out of the MANET wg in an operational = frame?

Now, if opsawg has a bunch of = stealthy MANET operators subscribed, whom we do not know about already, = then we'd *love* to make friends get comments and feedback as to how = they're doing things. So please, anyone with MANET experience do come = forward....

And yes, any suggestions as to "how = can we do better/differently?" are always highly welcome. We're just = routing guys, who recognise the need for network management - but, who = also recognise that we just are routing guys and that we better be = attentive to domain-expert advice.

RFC5706 may contain ideas regarding management and = monitoring of protocols,
that could apply for eliciting additional = input from operators about current
practices, or for eliciting = suggestions of management approaches that might
apply to further work = on management techniques that could be applied = to
MANETs.

Now, THAT was an RFC that I = wasn't aware of, but which seems (after a quick skim-through) to be = hugely interesting. I'll definitely give that a careful read-through on = my way to London. Thank you for that = pointer. 

Given the = "startup" nature of much of the MANET config, it definitely = looks
like Netconf/YANG might be a better choice than RW MIB modules = for
configuration (I suggest attending the OPSAWG meeting in London, = since that
is already a planned topic of = conversation).

And again, that was a very = good pointer, and I'll make sure to be there. = Thanks.

Now, there's something to be said for = the way in which we designed OLSRv2: essentially, ad-hoc networks are = intended to be very "autonomous", that's how they often are = deployed. 

There's very little that = *requires* global agreement (off the top of my head, three things: the = value of C, cryptographic material, and interface address configuration) = for correct operation of a network. The protocol is designed to be = accommodating to heterogeneity of pretty much everything else. Of = course, for *efficient* operation, one will want if not global = agreement, then at least a way of affecting other parameters in the = routers - and this over time, as the network evolves (e.g., devices = start to move about, or settle down, or the environment changes, = etc.).

So yes, while all the "required config" = probably is startup config, there is a need for also being able to = configure (and, certainly, monitor) the network while in continued = operation.

Section 3 appears to = be mostly about IP configuration and interface
configuration; there = are netmod YANG modules for this purpose. =

I have actually only passing = familiarity with YANG, so I will have to go look at that in more = details, also, in preparation of London.

Using standardized management would likely improve = interoperability, if
interoperability is important. It may not seem = that important for deployment
for internal management, but having a = consistent management interface for an
NMS to use to debug internal = deployments could be awfully helpful = to
operators.

Interoperability is = hugely important (otherwise, we'd not bother going through the hoops, = expenses, and frustrations, of = standardising).

The back-story (which we kinda = allude to, but which really is not worth telling in detail in the = document, since I expect that it's quite classic) is, that in the past = we had no standardised ways of a NMS interacting with an OLSR instance. = Consequently, we saw each implementation of OLSR come with its own (if = any, that is) more or less wicked "interface" (examples include using = Java RMI, Sun RPC, a TCP socket with 'untraditional' textual commands, = ...) and exposing/expecting data in more or less wicked formats and = amounts, and towards "custom" NMSes, visualisation tools, etc. Not = throwing any stones here - I believe that my initial implementation of a = "management interface" to an OLSR instance takes the price of being "the = most wicked of the bunch" - just observing how it = was.

Operationally, that's not good - and, even = for our interop events, that has occasionally been a difficulty - or, at = least, it would have simplified life greatly had we all had identical = interfaces and information exposure. That's what motivated us to dig in = and develop MIB modules and the likes.

Again, = thanks for your interest and guidance, it is hugely appreciated, and - I = think I can speak for both the authors - we're eager to learn from all = y'all.

Best,

Thomas


David Harrington
ietfdbh@comcast.net
+1-603-828-= 1401
-----Original Message-----
From: = OPSAWG [mailto:opsawg-bounces@ietf.org= ] On Behalf Of Adrian
Farrel
Sent: Wednesday, February 26, 2014 = 6:40 PM
To: Opsawg@ietf.org
Cc: manet-chairs@tools.ietf.org; draft-clausen-manet-olsrv2-management-
snapshot@tools.ietf.org
Sub= ject: [OPSAWG] Help with a MANET management draft please

Hi = OPSAWG,

The MANET working group develops protocols for mobile and = ad-hoc
networks (some
of which are less mobile or less ad hoc than = others).

After discussion with the IESG and specifically the OPS = ADs, the WG has
agreed
to try to put together some thoughts on = management of these networks.

It's early days and the authors are = not experienced in these ideas (so be
gentle!) but it seems important = at this stage to see whether the work = is
going
in the right = direction.

Could any of you find time to review and comment (on = this list, on the
MANET
list, direct to the authors, channelled = through me)? All contributions
will be
gratefully received.

The document is:
http://datatracker.ietf.org/doc/draft-clausen-manet-olsrv2-managemen= t-
snapshot/

Thanks,
Adrian

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


= --Apple-Mail=_9CAC43C5-E154-483B-8437-85D6D654DAD1-- From nobody Thu Feb 27 06:45:38 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 A05221A02DD for ; Thu, 27 Feb 2014 06:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 aUXKIH97xeGa for ; Thu, 27 Feb 2014 06:45:32 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1631A02CF for ; Thu, 27 Feb 2014 06:45:31 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7E9EE1B16; Thu, 27 Feb 2014 15:45:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1NsEjG7shnIK; Thu, 27 Feb 2014 15:45:26 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 27 Feb 2014 15:45:26 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B92B42005C; Thu, 27 Feb 2014 15:45:26 +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 TWLDORqEuD0a; Thu, 27 Feb 2014 15:45:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD27F20048; Thu, 27 Feb 2014 15:45:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 880652B80262; Thu, 27 Feb 2014 15:45:22 +0100 (CET) Date: Thu, 27 Feb 2014 15:45:22 +0100 From: Juergen Schoenwaelder To: Thomas Clausen Message-ID: <20140227144520.GA9856@elstar.local> Mail-Followup-To: Thomas Clausen , Adrian Farrel , Opsawg@ietf.org, "" , draft-clausen-manet-olsrv2-management-snapshot@tools.ietf.org References: <101901cf334c$23070f30$69152d90$@olddog.co.uk> <20140227070700.GA8623@elstar.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/s7RorPS63FmfZNQ2d2waj4DbwLU Cc: "" , Opsawg@ietf.org, draft-clausen-manet-olsrv2-management-snapshot@tools.ietf.org Subject: Re: [OPSAWG] Help with a MANET management draft please 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, 27 Feb 2014 14:45:35 -0000 Hi, this is useful input, in particular the description of the various things NMSes in a MANET context like to do. Concerning the text in the I-D, I would probably stay away from classifying other protocols as "simpler" or "less chatty", in particular if they are all kept secret (note that proprietary does not necessarily imply that a protocol is secret - there are many proprietary protocols that are documented). /js On Thu, Feb 27, 2014 at 03:17:26PM +0100, Thomas Clausen wrote: > Dear Juergen, > > On 27 Feb 2014, at 08:07, Juergen Schoenwaelder wrote: > > > On Wed, Feb 26, 2014 at 11:40:29PM +0000, Adrian Farrel wrote: > > > >> Could any of you find time to review and comment (on this list, on > >> the MANET list, direct to the authors, channelled through me)? All > >> contributions will be gratefully received. > > > > Out of curiosity, I would like to understand what the background > > behind these statements is: > > > > "protocols such as SNMP (or possibly other, less "chatty", > > protocols)." > > > > In some deployments, the NMS communicates with individual routers by > > way of SNMP - and, more commonly, by way of "proprietary" simpler, > > less verbose and (often) less secure protocols, and over UDP. > > > > Any pointers to such proprietary protocols? I am just wondering what > > the network management communication patterns are that take place in > > MANETs. > > I would love to be able to provide a pointer, but that's unfortunately the nature of "proprietary": I can't. I actually do not believe that there's any "de-facto standard" or "commonly used proprietary protocol" out there, more a matter of each implementer of OLSR (v1 and v2, both) set out realising the need for interacting with a running OLSR instance, and coming up with his/her own approach depending on ad-hoc needs. Heck, I don't think I've actually seen a written documentation of these "proprietary" protocols, except for their code.... > > Initially, what we saw was in the numerous OLSR interop's we've held, where we saw a remarkable number of visualisation tools, for example, depicting the evolution of the network topology (caveat: routers in a MANET are likely to move about), or tools permitting to temporarily provoke a "failure-like event" in a router to be able to observe how the surrounding network behaves - with instrumenting routers to record and reflect their behaviours. Tools, that is, communicating with the protocol instance in whatever way the implementer saw fit to build, since there was no commonly agreed-upon, documented, way. > > But, you do make a good point which is - I think - that it might be helpful to document what the (management) communications patterns may look like in an operating (post-startup) network. I think that that probably is a good idea, so we'll definitely see about that in a coming revision of the document, thank you for that suggestion! > > I'll throw a few thoughts - without claiming to be exhaustive - out below as what I see in the networks that I know of and know very well, that happens "often" - note, this is just in what *I* see, not what *everybody* sees or what everybody may wish to see happen: > > a) Inquire the state (complete topology graph, link states, local links even if not part of topology graph) of a router > Often, this is getting "up to a few KB worth of data" back > It's not a very common operation. > > b) Inquire the history/statistics of a router > This is typically something tiny, like "how many local link changes have you seen within the past n minutes/seconds/hours" > This may be very rare, or it may be several times per minute per router for a while: if my NMS is trying to "tune" message > intervals and timers, it may be a case of "doing this to a group of topologically close routers" - until, that is, the NMS decides > that it's happy with what it sees and will ease up > > c) Change the configuration of a router > Other than in the above case (tuning) this really happens only when somehow I get a new uplink to an external network, > and I either need to throw a new gateway into the network, and/or I need to get a new prefix out to the routers. > > d) Visualising the network as a router sees it. > Note that as in a MANET, routers do move about, this may mean that the topology changes frequently. In a naive way, this would > essentially be the NMS setting up a connection to the router in question, and "getting a copy of all routing protocol > control messages" to construct its own topology graph as would have done that router. Typically, it consists of the router sending a > notification to the NMS when a topological change happens, i.e., when either of its information bases change. Even better, it > consists of these notifications being "filtered" to only send for those changes that actually impact the usable topology. > > e) Rekeying - we do not actually have a (standard) mechanism for AKM, and I maintain that it probably is not possible to come > up with a single such that will satisfy the requirements for all the different deployments, but it's still something that we do play with. > I'm actually doing that as part of a management operation and schlepping it around as I would any configuration parameter > (not saying that it's the right thing to do, though, just what I'm playing with). The particularity of this is, that it often is a "broadcast > configuration operation" where you want to get new material to everybody, and not just a single device. > > Some of the proprietary stuff that has been done (and which I have done) in the past, can be explained easily by the above, and by the fact that in OLSR (v1 and v2) we have really efficient flooding operations in place. This can (and has) be used to do e) much much more efficiently (& reliably) than a bunch of unicasts. For b), too, in case we want to configure a "group of topologically close routers": unicast to one of them (topologically as central as possible) and then use scope-limited optimized flooding to reach the surrounding routers. As for d), the opportunities are endless for thinking up ways to do that... > > Moving towards standardized data representations, such as the MIBs, as well as some of the interesting developments by Bob Cole (REPORT-MIB - http://tools.ietf.org/html/draft-ietf-manet-report-mib - yes, it is expired, but we need to revive that, I think) are steps that we're trying to take to exit the world of "ad-hoc" management solutions. > > Not sure if that's a useful answer to your question? I am sorry that I can't point to some neatly written up whitepaper, which clearly would have been a better answer. > > Either way, your question is good and it might make sense to mull a bit on that and try to capture a more complete answer to it than what I provided in the above in the document? > > Tschüß, > > Thomas > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 27 06:52: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 C2D211A02EC for ; Thu, 27 Feb 2014 06:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 vp3frRuba6zO for ; Thu, 27 Feb 2014 06:52:39 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 21EAA1A02F8 for ; Thu, 27 Feb 2014 06:52:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E1618240763; Thu, 27 Feb 2014 06:52:36 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 44587240433; Thu, 27 Feb 2014 06:52:33 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <20140227144520.GA9856@elstar.local> Date: Thu, 27 Feb 2014 15:52:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73593C27-8B09-4AF9-984E-3385429A44A7@thomasclausen.org> References: <101901cf334c$23070f30$69152d90$@olddog.co.uk> <20140227070700.GA8623@elstar.jacobs.jacobs-university.de> <20140227144520.GA9856@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/mFkGYdAANwWjwv5wnbHYmjvuQ9Q Cc: "" , Opsawg@ietf.org, draft-clausen-manet-olsrv2-management-snapshot@tools.ietf.org Subject: Re: [OPSAWG] Help with a MANET management draft please 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, 27 Feb 2014 14:52:42 -0000 Dear Juergen, On 27 Feb 2014, at 15:45, Juergen Schoenwaelder = wrote: > Hi, >=20 > this is useful input, in particular the description of the various > things NMSes in a MANET context like to do. OK, we'll try to think of ways of reflecting that. > Concerning the text in the > I-D, I would probably stay away from classifying other protocols as > "simpler" or "less chatty",=20 OK, that's perhaps too colloquial, we'll pay attention to that. > in particular if they are all kept secret > (note that proprietary does not necessarily imply that a protocol is > secret - there are many proprietary protocols that are documented). >=20 Agree. I note that "kept secret" is not really due to "don't want to = share" but rather due to "nobody seemed to have bothered to document = it". Either way, thank you so much for your feedback. Question to the OPSAWG chairs:=20 We'll probably spin a new revision within the IETF week.=20 As we're not regulars in OPSAWG we thought we'd ask permission = rather than forgiveness,=20 as to how you run usually: shall we forward the announce to this = list (and to MANET, of course), or is this noise you'd rather be without? A bientot, Thomas =09 > /js >=20 > On Thu, Feb 27, 2014 at 03:17:26PM +0100, Thomas Clausen wrote: >> Dear Juergen, >>=20 >> On 27 Feb 2014, at 08:07, Juergen Schoenwaelder = wrote: >>=20 >>> On Wed, Feb 26, 2014 at 11:40:29PM +0000, Adrian Farrel wrote: >>>=20 >>>> Could any of you find time to review and comment (on this list, on >>>> the MANET list, direct to the authors, channelled through me)? All >>>> contributions will be gratefully received. >>>=20 >>> Out of curiosity, I would like to understand what the background >>> behind these statements is: >>>=20 >>> "protocols such as SNMP (or possibly other, less "chatty", >>> protocols)." >>>=20 >>> In some deployments, the NMS communicates with individual routers = by >>> way of SNMP - and, more commonly, by way of "proprietary" simpler, >>> less verbose and (often) less secure protocols, and over UDP. >>>=20 >>> Any pointers to such proprietary protocols? I am just wondering what >>> the network management communication patterns are that take place in >>> MANETs. >>=20 >> I would love to be able to provide a pointer, but that's = unfortunately the nature of "proprietary": I can't. I actually do not = believe that there's any "de-facto standard" or "commonly used = proprietary protocol" out there, more a matter of each implementer of = OLSR (v1 and v2, both) set out realising the need for interacting with a = running OLSR instance, and coming up with his/her own approach depending = on ad-hoc needs. Heck, I don't think I've actually seen a written = documentation of these "proprietary" protocols, except for their = code.... >>=20 >> Initially, what we saw was in the numerous OLSR interop's we've held, = where we saw a remarkable number of visualisation tools, for example, = depicting the evolution of the network topology (caveat: routers in a = MANET are likely to move about), or tools permitting to temporarily = provoke a "failure-like event" in a router to be able to observe how the = surrounding network behaves - with instrumenting routers to record and = reflect their behaviours. Tools, that is, communicating with the = protocol instance in whatever way the implementer saw fit to build, = since there was no commonly agreed-upon, documented, way. >>=20 >> But, you do make a good point which is - I think - that it might be = helpful to document what the (management) communications patterns may = look like in an operating (post-startup) network. I think that that = probably is a good idea, so we'll definitely see about that in a coming = revision of the document, thank you for that suggestion! >>=20 >> I'll throw a few thoughts - without claiming to be exhaustive - out = below as what I see in the networks that I know of and know very well, = that happens "often" - note, this is just in what *I* see, not what = *everybody* sees or what everybody may wish to see happen: >>=20 >> a) Inquire the state (complete topology graph, link states, = local links even if not part of topology graph) of a router >> Often, this is getting "up to a few KB worth of data" = back >> It's not a very common operation. >>=20 >> b) Inquire the history/statistics of a router >> This is typically something tiny, like "how many local = link changes have you seen within the past n minutes/seconds/hours" >> This may be very rare, or it may be several times per = minute per router for a while: if my NMS is trying to "tune" message=20 >> intervals and timers, it may be a case of "doing this to = a group of topologically close routers" - until, that is, the NMS = decides >> that it's happy with what it sees and will ease up >>=20 >> c) Change the configuration of a router >> Other than in the above case (tuning) this really = happens only when somehow I get a new uplink to an external network, >> and I either need to throw a new gateway into the = network, and/or I need to get a new prefix out to the routers. >>=20 >> d) Visualising the network as a router sees it. >> Note that as in a MANET, routers do move about, this may = mean that the topology changes frequently. In a naive way, this would >> essentially be the NMS setting up a connection to the = router in question, and "getting a copy of all routing protocol >> control messages" to construct its own topology graph as = would have done that router. Typically, it consists of the router = sending a=20 >> notification to the NMS when a topological change = happens, i.e., when either of its information bases change. Even better, = it >> consists of these notifications being "filtered" to only = send for those changes that actually impact the usable topology. >>=20 >> e) Rekeying - we do not actually have a (standard) = mechanism for AKM, and I maintain that it probably is not possible to = come >> up with a single such that will satisfy the requirements = for all the different deployments, but it's still something that we do = play with. >> I'm actually doing that as part of a management = operation and schlepping it around as I would any configuration = parameter >> (not saying that it's the right thing to do, though, = just what I'm playing with). The particularity of this is, that it often = is a "broadcast >> configuration operation" where you want to get new = material to everybody, and not just a single device. >>=20 >> Some of the proprietary stuff that has been done (and which I have = done) in the past, can be explained easily by the above, and by the fact = that in OLSR (v1 and v2) we have really efficient flooding operations in = place. This can (and has) be used to do e) much much more efficiently (& = reliably) than a bunch of unicasts. For b), too, in case we want to = configure a "group of topologically close routers": unicast to one of = them (topologically as central as possible) and then use scope-limited = optimized flooding to reach the surrounding routers. As for d), the = opportunities are endless for thinking up ways to do that... >>=20 >> Moving towards standardized data representations, such as the MIBs, = as well as some of the interesting developments by Bob Cole (REPORT-MIB = - http://tools.ietf.org/html/draft-ietf-manet-report-mib - yes, it is = expired, but we need to revive that, I think) are steps that we're = trying to take to exit the world of "ad-hoc" management solutions. >>=20 >> Not sure if that's a useful answer to your question? I am sorry that = I can't point to some neatly written up whitepaper, which clearly would = have been a better answer. >>=20 >> Either way, your question is good and it might make sense to mull a = bit on that and try to capture a more complete answer to it than what I = provided in the above in the document? >>=20 >> Tsch=FC=DF, >>=20 >> Thomas >>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Thu Feb 27 13: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 67C6D1A0400 for ; Thu, 27 Feb 2014 13:47:59 -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 H0ncZBJZR0X3 for ; Thu, 27 Feb 2014 13:47:57 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id BBD461A0198 for ; Thu, 27 Feb 2014 13:47:57 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id ar20so2651189iec.37 for ; Thu, 27 Feb 2014 13:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=elmrZUg2+yACfH1O3H4Vj1EtgDLESftuc0kUE1WMu2o=; b=zXrEYdRqtP7mFNC1ynqL9Uq+tpibfPVn7xyvQo1VjpM17W0fyPH/QUqvOEdDqFqPJh 2bTuvCSBzYkSrTvD+C3dR93Juaerb8w2JRXwBWFltbTCdDur1Qarm9sDcwpAz43QfwzM VS+bH0XauhAi5cO7zjcqdP50Xa790hvgxR6hF3G/NMxq1iJtqZMoewNm6l+xglwX+9X5 5xgKR3V3xeTkLqI9ceuVK+d9J2JsWczzo/o+QyD1Sp/FvDBoiw5JbgB98tf27LmB70+u cByOdQD47edZ24OiCrNudGYeHdWoQ4/kuA5zE1IRAwLGM8fG3mMtPvSTb4iXWM4U95f8 WKMg== X-Received: by 10.50.217.232 with SMTP id pb8mr375841igc.8.1393537676008; Thu, 27 Feb 2014 13:47:56 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-150-99.tor.primus.ca. [173.206.150.99]) by mx.google.com with ESMTPSA id qk2sm10106605igc.1.2014.02.27.13.47.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Feb 2014 13:47:55 -0800 (PST) Message-ID: <530FB28B.6000507@gmail.com> Date: Thu, 27 Feb 2014 16:47:55 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-extension@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/0lMlMBkJ1fZG30fovyHRRTnp87s Subject: [OPSAWG] Review of draft-ietf-opsawg-capwap-extension-02 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, 27 Feb 2014 21:47:59 -0000 Numerous grammatical and stylistic suggestions that I gave you in my first review haven't made it into the revision, so I won't bother with any more. However, there are still points where the intention isn't clear and the text needs to be tightened up. Section 4.1.2 regarding antenna configuration: ---------------------------------------------- I don't understand the explanation of this field. It says each bit represents the number of antennas corresponding to that bit. Taking that literally, I could see 1+2+...+8 = a total of 36 antennas being configured. Is this what you mean, or do you mean that there are eight antennas, each bit corresponds to one of them, and the bits determine which of those eight antennas are enabled? Section 5.1 first paragraph: ---------------------------- Currently says: "... if those information element is zero ..." Do you mean that literally (I haven't looked those information elements up), or do you mean: "... if those information elements are not present ..."? Section 5.3 explanation of scanning procedure: ---------------------------------------------- Do the three parameters that determine scan operation apply to both passive and active scanning, or just to active scanning? I can get the answer by looking in Section 5.3.1, but it wouldn't hurt to say it here. Section 5.3.1 Scan Parameter message element: --------------------------------------------- The M and S bits are described as having values 1 or 2, but are only one bit wide. They should be 0 or 1. You probably mean to designate that M bit is "WTP oper mode", not "AP oper mode". You may want to specify what L=0 and D=0 mean. 5.3.4. Neighbor WTP Report: --------------------------- You should probably use phrasing similar to that of Section 4.1.1 to specify transport of the Neighbor Report Element in the 802.11 Information Element, rather than talking about a new message type. From nobody Fri Feb 28 02:58: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 305FB1A00EF for ; Fri, 28 Feb 2014 02:58:18 -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 0U8cppPts8qA for ; Fri, 28 Feb 2014 02:58:15 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 70DA71A00CB for ; Fri, 28 Feb 2014 02:58:15 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id if11so528986vcb.8 for ; Fri, 28 Feb 2014 02:58:13 -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=ed4ZS/OPbAdnQ7Qx1+J/af99GQynkbtnTplT+ZT3Ol0=; b=zcqrQCL1OsmtFi47IhP3WPc52in3+xbpksKD5rwdeZhmOTinzrtGupUGdyV143FElb Ad/USIru+cD0mkwhdwpOMxxB/upBKQNvnHKcTpOi2U+9C/oLqNhTBplKTNNIjOqu9IxQ B3Ttk2HgDCTzt2VQAyC7iwJr5dlpWdse1+I4DcYZlL49Ck4MsmIT/AxqT0GUT6E8eOb+ zCtYCT8uXf5QV/5K1a5KodBn74zyeFAGmg0LUSWqa8S4kER3CMo0ILKyg2B3LMABeWH1 s3DvhsDNXfiBdHVXcjAYsarCzQHegE4iZzc+tCgB6hYE5JABBwogggF4WO2UuMuk4nnB pMXQ== MIME-Version: 1.0 X-Received: by 10.58.186.132 with SMTP id fk4mr1917248vec.9.1393585093483; Fri, 28 Feb 2014 02:58:13 -0800 (PST) Received: by 10.221.24.146 with HTTP; Fri, 28 Feb 2014 02:58:13 -0800 (PST) In-Reply-To: <530FB28B.6000507@gmail.com> References: <530FB28B.6000507@gmail.com> Date: Fri, 28 Feb 2014 18:58:13 +0800 Message-ID: From: Liu Dapeng To: Tom Taylor , chenyifan@chinamobile.com, gaoyoujun@chinamobile.com Content-Type: multipart/alternative; boundary=047d7b6dc25076262504f3755096 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/OxPmBrijaNqAXyBedAOJoJ-UB1U Cc: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-extension@tools.ietf.org Subject: Re: [OPSAWG] Review of draft-ietf-opsawg-capwap-extension-02 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, 28 Feb 2014 10:58:18 -0000 --047d7b6dc25076262504f3755096 Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, Thanks for your review. 2014-02-28 5:47 GMT+08:00 Tom Taylor : > Numerous grammatical and stylistic suggestions that I gave you in my first > review haven't made it into the revision, so I won't bother with any more. I searched the mailing list and can not find your "grammatical and stylistic suggestions" comments. Do you mind to give me a pointer? > However, there are still points where the intention isn't clear and the > text needs to be tightened up. > > Section 4.1.2 regarding antenna configuration: > ---------------------------------------------- > I don't understand the explanation of this field. It says each bit > represents the number of antennas corresponding to that bit. Taking that > literally, I could see 1+2+...+8 = a total of 36 antennas being configured. > Is this what you mean, or do you mean that there are eight antennas, each > bit corresponds to one of them, and the bits determine which of those eight > antennas are enabled? > It is the latter case, only eight antennas. How about adding the following sentence for clarification: "Only one bit is allowed to be set to 1." > Section 5.1 first paragraph: > ---------------------------- > > Currently says: "... if those information element is zero ..." > Do you mean that literally (I haven't looked those information elements > up), or do you mean: "... if those information elements are not present > ..."? > It should be the channel field of those information element. How about the following sentence? "If the channel field of those information element is set to 0" > Section 5.3 explanation of scanning procedure: > ---------------------------------------------- > > Do the three parameters that determine scan operation apply to both > passive and active scanning, or just to active scanning? I can get the > answer by looking in Section 5.3.1, but it wouldn't hurt to say it here. > OK, how about adding a sentence after the first sentence in page 9: There are three parameters that will determine the working mode of scan: PrimeChlSrvTime, On Channel ScanTime, Off Channel ScanTime. It applies to both active and passive scan. Section 5.3.1 Scan Parameter message element: > --------------------------------------------- > > The M and S bits are described as having values 1 or 2, but are only one > bit wide. They should be 0 or 1. Yes. I will change its values to 0 and 1. > You probably mean to designate that M bit is "WTP oper mode", not "AP oper > mode". > > Yes, I will change the "AP" to "WTP". > You may want to specify what L=0 and D=0 mean. > I will add the following: L=0: Disable Load Balance Scan. D=0: Disable Rouge WTP detection scan. > > 5.3.4. Neighbor WTP Report: > --------------------------- > > You should probably use phrasing similar to that of Section 4.1.1 to > specify transport of the Neighbor Report Element in the 802.11 Information > Element, rather than talking about a new message type. > OK. How about changing it to the following: This document specifies use of the IEEE 802.11 Information Element (Type 1029) that defined in section 6.6 of RFC5416 and IEEE 802.11 Neighbor Report Element that defined in section 8.4.2.39 of IEEE-802.11.2012 to carry the neighbor WTP report message. Cheers, Dapeng Liu > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- ------ Best Regards, Dapeng Liu --047d7b6dc25076262504f3755096 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tom,

Thanks for your review.


2014-02-28 5:47= GMT+08:00 Tom Taylor <tom.taylor.stds@gmail.com>:
Numerous grammatical and stylistic suggestions that I gave= you in my first review haven't made it into the revision, so I won'= ;t bother with any more.

I searched the mailing list and can not find your= "grammatical and stylistic suggestions" comments. Do you mind to= give me a pointer?=A0
=A0
However, there are still points where the intention isn't clear and the= text needs to be tightened up.

Section 4.1.2 regarding antenna configuration:
----------------------------------------------
I don't understand the explanation of this field. It says each bit repr= esents the number of antennas corresponding to that bit. Taking that litera= lly, I could see 1+2+...+8 =3D a total of 36 antennas being configured. Is = this what you mean, or do you mean that there are eight antennas, each bit = corresponds to one of them, and the bits determine which of those eight ant= ennas are enabled?

It is the latter case, only eight an= tennas.

How about adding the following= sentence for clarification:

"Onl= y one bit is allowed to be set to 1."


Section 5.1 first paragraph:
----------------------------

Currently says: "... if those information element is zero ..." Do you mean that literally (I haven't looked those information elements= up), or do you mean: "... if those information elements are not prese= nt ..."?

It should be the ch= annel field of those information element. How about the following sentence?=

=A0"If the channel field of those informatio= n element is set to 0"


Section 5.3 explanation of scanning procedure:
----------------------------------------------

Do the three parameters that determine scan operation apply to both passive= and active scanning, or just to active scanning? I can get the answer by l= ooking in Section 5.3.1, but it wouldn't hurt to say it here.

OK, how about adding a sentence after the first s= entence in page 9:


There are three parameters that will determine the working mode of scan: Pr=
imeChlSrvTime, On Channel ScanTime, Off Channel ScanTime.  It applies to bo=
th active and passive scan.




Section 5.3.1 Scan Parameter message element:
---------------------------------------------

The M and S bits are described as having values 1 or 2, but are only one bi= t wide. They should be 0 or 1.

Yes. = I will change its values to 0 and 1.
=A0
You probably mean to designate that M bit is "WTP oper mode", not= "AP oper mode".


Yes, I will change the "AP&= quot; to "WTP".
=A0
You may want to specify what L=3D0 and D=3D0 mean.
I will add the following:

L=3D0: Disable Load Balance Scan.
D=3D0: Disable = Rouge WTP detection scan.
=A0

5.3.4. Neighbor WTP Report:
---------------------------

You should probably use phrasing similar to that of Section 4.1.1 to specif= y transport of the Neighbor Report Element in the 802.11 Information Elemen= t, rather than talking about a new message type.

OK. How about changing it to the following:

This document specifies use of the IEEE 802.11 Informa= tion Element (Type 1029) that defined in section 6.6 of=A0RFC5416 and IEEE = 802.11 Neighbor Report Element that defined in section 8.4.2.39 of IEEE-802= .11.2012 to carry the neighbor WTP report message.=A0


Cheers,
Dape= ng Liu
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org = https://www.ietf.org/mailman/listinfo/opsawg



--

------Best Regards,
Dapeng Liu
--047d7b6dc25076262504f3755096-- From nobody Fri Feb 28 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 003E01A0179 for ; Fri, 28 Feb 2014 03:04:32 -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 nSs7_1Eicunw for ; Fri, 28 Feb 2014 03:04:31 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5D91A00CB for ; Fri, 28 Feb 2014 03:04:31 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hm4so568310wib.14 for ; Fri, 28 Feb 2014 03:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AED53NAV+9dDdXG4M4b3uAJ53WPOW3iepP0aP+8Fr7E=; b=vz3MzhkLncXR6jsrJ53BCFoq98P+22kObNkmU8DXYQ7/U7d91mtYHzoKfmxy8mii3o dM3DUQDRwVg2AF4Ts0KD6TW9oBu6huqp6Dy+aEWT69unthE22DoBiMJR6nCjzS2QGjOv kZYTRxMbV93BQqXIXcsDNMPx00nWPXI+tb4qefxXyq6nhj6NO19UBaZL4T72xQXerVM3 A6kuHkMwAmqm+RwC+k2O5pfQkgSDuWTqw3//tHbIjD2naSsi9PueSBk8DsQfNWpmUFO/ U34zAbb1E0X9XVJDRdWoSsD3TgA4cbrG8JwIzsxoqll8ltLvj9a//r8DfenWDVmdMXL0 A3+A== X-Received: by 10.180.211.50 with SMTP id mz18mr2612169wic.43.1393585469072; Fri, 28 Feb 2014 03:04:29 -0800 (PST) Received: from [10.207.195.210] ([109.144.236.144]) by mx.google.com with ESMTPSA id de3sm3467022wjb.8.2014.02.28.03.04.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 03:04:28 -0800 (PST) Message-ID: <53106D3B.70507@gmail.com> Date: Fri, 28 Feb 2014 03:04:27 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <101901cf334c$23070f30$69152d90$@olddog.co.uk> <20140227070700.GA8623@elstar.jacobs.jacobs-university.de> <20140227144520.GA9856@elstar.local> <73593C27-8B09-4AF9-984E-3385429A44A7@thomasclausen.org> In-Reply-To: <73593C27-8B09-4AF9-984E-3385429A44A7@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Epg982pLnBSmPoOKY3nRxbrptAY Subject: Re: [OPSAWG] Help with a MANET management draft please 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, 28 Feb 2014 11:04:33 -0000 On 02/27/2014 06:52 AM, Thomas Clausen wrote: > Question to the OPSAWG chairs: > > We'll probably spin a new revision within the IETF week. As we're not > regulars in OPSAWG we thought we'd ask permission rather than > forgiveness, as to how you run usually: shall we forward the announce > to this list (and to MANET, of course), or is this noise you'd rather > be without? Speaking strictly for myself, as long as it's topical to opsawg and it's productive discussion, it's signal, not noise, and I'm good with it. Melinda From nobody Fri Feb 28 06:56:18 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 397CF1A0808 for ; Fri, 28 Feb 2014 06:56:04 -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 t1CVuce2EDzj for ; Fri, 28 Feb 2014 06:55:59 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 826F21A080A for ; Fri, 28 Feb 2014 06:55:56 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id h18so1775133igc.1 for ; Fri, 28 Feb 2014 06:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tK7ZypZOcw0oMWUg5mN+Wwv9cx4q+12hQkVuQpQzyEc=; b=Rz2qtG9RmNDOPikGSWjVsr27PlFLouXZaljl3IzlXmPf27Zd1zah64VvuL2Ou0Fl+6 xKXcmao30yadAbCixAnjHfP2H4Fp55AP2oRuOx3WNuhHGCYSw6vct6Hvk+ueo/CXuOuz epq4/RkqZWyd/FRtmT/P5LLEok376CRNlYjzD2+pxkbfYAWENkGX4je3ALhohNXbxJoM ex1Ug1lXfXDeQJckLA9dNWVg41BiP3smksdAUTGvN+60Cb+qSyeAEzA+vFZCN5i1hxPD X2gzDLNVGXxembFI8MU82C93r/J+P1Ct/LyaqlUlXfGW2LLn/Oc5fouE28sJCo9pnfam ebSw== X-Received: by 10.50.22.210 with SMTP id g18mr4443037igf.19.1393599354608; Fri, 28 Feb 2014 06:55:54 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-150-99.tor.primus.ca. [173.206.150.99]) by mx.google.com with ESMTPSA id dz8sm7740951igb.5.2014.02.28.06.55.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 06:55:54 -0800 (PST) Message-ID: <5310A37A.8090600@gmail.com> Date: Fri, 28 Feb 2014 09:55:54 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Liu Dapeng , chenyifan@chinamobile.com, gaoyoujun@chinamobile.com References: <530FB28B.6000507@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/DLMDMbKO0HEkmXbKXlnx99FaqIo Cc: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-extension@tools.ietf.org Subject: Re: [OPSAWG] Review of draft-ietf-opsawg-capwap-extension-02 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, 28 Feb 2014 14:56:04 -0000 On 28/02/2014 5:58 AM, Liu Dapeng wrote: > Hi Tom, > > Thanks for your review. > > > 2014-02-28 5:47 GMT+08:00 Tom Taylor : > >> Numerous grammatical and stylistic suggestions that I gave you in my first >> review haven't made it into the revision, so I won't bother with any more. > > > I searched the mailing list and can not find your "grammatical and > stylistic suggestions" comments. Do you mind to give me a pointer? > [PTT] Sorry, I sent it to you privately as a marked-up .docx on 7 Nov 2013. It's only 19 kB, so I suppose I could send it to the list too, or just resend it. Alternatively I could work directly on something you send me. Let me know. > >> However, there are still points where the intention isn't clear and the >> text needs to be tightened up. >> >> Section 4.1.2 regarding antenna configuration: >> ---------------------------------------------- >> I don't understand the explanation of this field. It says each bit >> represents the number of antennas corresponding to that bit. Taking that >> literally, I could see 1+2+...+8 = a total of 36 antennas being configured. >> Is this what you mean, or do you mean that there are eight antennas, each >> bit corresponds to one of them, and the bits determine which of those eight >> antennas are enabled? >> > > It is the latter case, only eight antennas. > > How about adding the following sentence for clarification: > > "Only one bit is allowed to be set to 1." [PTT] If that is so, why do you need 8 bits and not just 3 (if you number the antennas starting from 0)? Are you sure this isn't a matter of configuring a specific set of antennas, so that multiple bits can be set? For example, 10010000 enables antennas 8 and 5 and disables the rest? > > >> Section 5.1 first paragraph: >> ---------------------------- >> >> Currently says: "... if those information element is zero ..." >> Do you mean that literally (I haven't looked those information elements >> up), or do you mean: "... if those information elements are not present >> ..."? >> > > It should be the channel field of those information element. How about the > following sentence? > > "If the channel field of those information element is set to 0" > > >> Section 5.3 explanation of scanning procedure: >> ---------------------------------------------- >> >> Do the three parameters that determine scan operation apply to both >> passive and active scanning, or just to active scanning? I can get the >> answer by looking in Section 5.3.1, but it wouldn't hurt to say it here. >> > > OK, how about adding a sentence after the first sentence in page 9: > > There are three parameters that will determine the working mode of > scan: PrimeChlSrvTime, On Channel ScanTime, Off Channel ScanTime. It > applies to both active and passive scan. > [PTT] I believe the definitions of the On and Off Channel Scan Time parameters say that they apply to active mode only. > > > > > Section 5.3.1 Scan Parameter message element: >> --------------------------------------------- >> >> The M and S bits are described as having values 1 or 2, but are only one >> bit wide. They should be 0 or 1. > > > Yes. I will change its values to 0 and 1. > > >> You probably mean to designate that M bit is "WTP oper mode", not "AP oper >> mode". >> >> > Yes, I will change the "AP" to "WTP". > > >> You may want to specify what L=0 and D=0 mean. >> > > I will add the following: > > L=0: Disable Load Balance Scan. > D=0: Disable Rouge WTP detection scan. > > >> >> 5.3.4. Neighbor WTP Report: >> --------------------------- >> >> You should probably use phrasing similar to that of Section 4.1.1 to >> specify transport of the Neighbor Report Element in the 802.11 Information >> Element, rather than talking about a new message type. >> > > OK. How about changing it to the following: > > This document specifies use of the IEEE 802.11 Information Element (Type > 1029) that defined in section 6.6 of RFC5416 and IEEE 802.11 Neighbor > Report Element that defined in section 8.4.2.39 of IEEE-802.11.2012 to > carry the neighbor WTP report message. > [PTT] The point is that there is no such thing as the neighbour WTP report message. The sentence should be: "This document specifies use of the IEEE 802.11 Information Element (Type 1029) defined in section 6.6 of RFC5416 to carry the IEEE 802.11 Neighbor Report Element defined in section 8.4.2.39 of [IEEE-802.11.2012], possibly along with other IEEE 802.11 elements." > > Cheers, > Dapeng Liu > >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > >