From tom.taylor.stds@gmail.com Tue Oct 1 04:52:07 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8E721F9AD8; Tue, 1 Oct 2013 04:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxcuORgf2oRd; Tue, 1 Oct 2013 04:52:06 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 37BA821F9AD5; Tue, 1 Oct 2013 04:52:06 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id ar20so13482083iec.32 for ; Tue, 01 Oct 2013 04:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=AnvLaOrExDIwke4nyILRR33xDtn+sL1FgHGZ3r5QoLc=; b=PV182wO7P0kLCMrYej62XfQS6uq52STdzCnMVVr8EVhd1iEZLxo8UHRGLhj6yB1GpI avVuAXnuKEFIvusRXKc8zSEeIqvPk/Dmjp87qaGNRyzGjNIaLzEwz8YkBX/nHXhpqlUA 6Zxw89kGpZZw/vesLY90DrO9Q6R41hgAYAZ+Ez1rT0ot20GES3d07GfSWf9MMXMHN0yR 739Ey7XKzYG/Ctw/Gy2cQb9tYhjBQsliHgrMDmZU+gvvQdqUFnSllcMjMxGhy5gnnddW fpWSP+E5+aaqYKAU3s2KivjYjS6Bg1Ig2HU/Wq0h/t7e3hRQ76P9iutKNF+e1dw3o6yI iMbA== X-Received: by 10.50.6.71 with SMTP id y7mr17297978igy.8.1380628324667; Tue, 01 Oct 2013 04:52:04 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id y10sm2945563igl.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Oct 2013 04:52:03 -0700 (PDT) Message-ID: <524AB761.5030703@gmail.com> Date: Tue, 01 Oct 2013 07:52:01 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Management of logging X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 11:52:07 -0000 While working on draft-ietf-behave-syslog-nat-logging-04, I added a Management Considerations section intended to highlight requirements for management of the logging system. I included the following general requirements. These are my best guess, but undoubtedly people with real operational experience will correct me. Please look this over and comment. Note that I have cross-posted to Behave and OPSAWG. Tom Taylor 7.1. General Requirements For Control Of Logging This document assumes that any implementation provides the following capabilities, discussed in more detail below: o ability to configure the PRI value of each event report type at the granularity of (APP-ID, MSGID) combination; o ability at each collector to determine that event reports that it should have received have been lost. The required granularity is at least at the level of PRI and may be finer for some event types. o ability to configure criteria to automatically suppress the generation of event reports while the criteria are met, at the granularity of (APP-ID, MSGID) combination. 7.1.1. Configuration of PRI Value The PRI value is composed of two numbers, the Facility value and the Severity. It may be used at the origin for selecting logs to streams being dispatched to different collectors, and in applications beyond the collectors to prioritize display of logs to operators. The event reports in this document have been structured such that the Severity level varies between event types as represented by (APP-ID, MSGID) combination. As an extreme example, the address pool high- water- mark threshold event (APP-ID="NATMTC", MSGID="POOLHT") is obviously more urgent than the low-water-mark threshold event (APP-ID="NATMTC", MSGID="POOLLT"). To some extent, this document tries to simplify message routing by making a general distinction between event types recording the allocation of resources to hosts (with APP-ID="NAT") and events of interest to operations and maintenance (with APP-ID="NATMTC"). The need to provide different Severity levels for different event types remains. 7.1.2. Ability For Each Collector To Detect Lost Event Reports Operators have a need to know when a given collector has not received all of the event reports it should have. It probably does not matter if less-important events are tracked at the granularity of event type (APP-ID, MSGID combination), by APP-ID, or just by PRI value. The event types defined in this document relating to allocation of resources to hosts are a special case. Regulatory requirements or the possibility that such reports might be introduced into court in cases such as abuse impose a requirement that the record of allocations to a particular host be complete. This requirement is important enough to be stated in the Security Considerations section Section 8, where the implementation of signed SYSLOG messages [RFC5848], which also provides message sequencing, is mandated as part of this specification. In deploying [RFC5848], the operator needs to decide the level of granularity of tracking, whether it should be over the whole set of reports covered by APP-ID="NAT" or at a finer level. This judgement has to be tempered by local circumstances. One point to note is that since both creations/allocations and deletions/deallocations are recorded, a certain amount of redundancy is available in the reports being generated. However, without both the creation and deletion timestamps, there is no definitive evidence of the specific period of time during which the resources concerned were allocated to a specific host. 7.1.3. Ability To Suppress Event Reports The event report types specified with APP-ID="NATMTC" all relate to limits or thresholds. By their nature, events of this sort will come in bursts. The limit or threshold will be hit, the resource concerned will remain busy for a period, then pressure on the resource will ease. Depending on the resource, possibly hundreds of instances of the event concerned will be detected during a single busy period. Where repeated events involve the same resource, it makes little sense to report all of them, since the NAT MIB counters provide the necessary information more succinctly. On the other hand, it can be useful to know that the fragmentation limit, for instance, is being hit by successive packets from the same source address. As a result of these considerations, this document requires that implementations MUST provide means to configure limits on the rate at which event reports of a given type (APP-ID, MSGID combination) are generated. This document RECOMMENDs that it be possible to specify two values per (APP-ID, MSGID) combination: o minimum time between initial instances of a given event report type; o maximum number of instances of the event report to generate per busy period. The ability to suppress event reports MUST NOT interfere with the requirement to detect lost messages. This has implications for any sequence numbering used for that purpose. It is RECOMMENDED in any event that the implementation provide counters of numbers of suppressed messages by event type. Just to state the obvious, given the need for a full record, an operator will not wish to enable suppression of the APP-ID="NAT" event reports. From melinda.shore@gmail.com Sat Oct 5 14:13:06 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB3821F8D62 for ; Sat, 5 Oct 2013 14:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FR_DOT_FEVER_5=3.9] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmzGGzolDS0G for ; Sat, 5 Oct 2013 14:13:05 -0700 (PDT) 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 51EFB21F9CE3 for ; Sat, 5 Oct 2013 14:13:03 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kp14so5579550pab.20 for ; Sat, 05 Oct 2013 14:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=aiP1l0iFVJrEu2AE6uogeHVi9oNKrASzjUxoiIfWUm0=; b=X5yTzCDLcOEUIDRTK/XMSLT2Pew4dO2urymvC2RnM5xlpP2KUJCMo8rjdbdXuEZgJU s2uSN2qUwJPGOYG+7kkUchxRBX0kp6UtTiAMk5r0T/4mOSohlOOzAn7pU0GV5TPPyExD v7XpEWqTi1pM7UWp0BUjTdR8Y0fSOKM60BehPItFCkt6K3Ai4s3m0y1N+DkwdMX9J2WS XJktesipKODnvi4/SLVJqpdSeTyy4d2SAWyqca/ekpzlod9xYv+KisuKt/7+Jn96KTJX ixlO2h8v/vF4dhuTmSNXR6/RElagbD5IjGojWsRoJtu1DrvoncvCHKIWYUnzdFBOr5My x0HQ== X-Received: by 10.66.158.196 with SMTP id ww4mr23424215pab.57.1381007583101; Sat, 05 Oct 2013 14:13:03 -0700 (PDT) Received: from spandex.local (216-67-113-166.dynamic.dsl.acsalaska.net. [216.67.113.166]) by mx.google.com with ESMTPSA id tz3sm23124369pbc.20.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Oct 2013 14:13:01 -0700 (PDT) Message-ID: <525080DB.2070206@gmail.com> Date: Sat, 05 Oct 2013 13:12:59 -0800 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" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Vancouver schedule is out X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 21:13:06 -0000 In case you missed it, the initial draft of the IETF 88 meeting schedule has been posted: https://datatracker.ietf.org/meeting/88/agenda.html We are scheduled to meet on Tuesday morning, 9:00 - 11:30. Also scheduled at the same time are . NFSv4 . mpls . dhc . sdnrg . httpbis . clue . sidr Melinda From bclaise@cisco.com Mon Oct 7 04:57:19 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DE721E81C6 for ; Mon, 7 Oct 2013 04:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.554 X-Spam-Level: X-Spam-Status: No, score=-10.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0l32ZzqwX000 for ; Mon, 7 Oct 2013 04:57:15 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 870C521E8190 for ; Mon, 7 Oct 2013 04:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11676; q=dns/txt; s=iport; t=1381147034; x=1382356634; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=qKY70L5Z1QUdUc0KKt+JZBvFYbDwqIv6mF9d3JpxEOM=; b=deuVOAn/AZ9euMdOY0XVJy9aHg4k2OwHE1rnUohNjNQOK+0Ep1X8dIb5 lxZ+WOvKQaEBTtYlll5hMdryzzq4XrAzFzkbqG2LDJAGuicDS+6YrpEDx dPrQcaJRfHCWCwFUNvGfDV1Q4afr4Y3GM9xjHTZ4ceDImaGHcZDlXPigS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAFOhUlKQ/khL/2dsb2JhbABZgwc4iVe4FoEdFnSCJgEBBGcRARAsFg8JAwIBAgFFEwEHAQGIAgy6Z49RB4QjA5gBgS+FB4tKgyY6 X-IronPort-AV: E=Sophos;i="4.90,1050,1371081600"; d="scan'208,217";a="18584647" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 07 Oct 2013 11:57:13 +0000 Received: from [10.61.194.168] ([10.61.194.168]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r97Bv8r4024015; Mon, 7 Oct 2013 11:57:10 GMT Message-ID: <5252A194.6030700@cisco.com> Date: Mon, 07 Oct 2013 13:57:08 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: draft-ietf-opsawg-lsn-deployment@tools.ietf.org References: <525281E0.8020107@cisco.com> In-Reply-To: <525281E0.8020107@cisco.com> X-Forwarded-Message-Id: <525281E0.8020107@cisco.com> Content-Type: multipart/alternative; boundary="------------080402030309090601000903" Cc: "opsawg@ietf.org" Subject: [OPSAWG] AD review: draft-ietf-opsawg-lsn-deployment-03 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:57:20 -0000 This is a multi-part message in MIME format. --------------080402030309090601000903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, - Section 3. CGN Network Deployment Requirements If a service provider is considering a CGN deployment with a provider NAT44 function, there are a number of basic architectural requirements which are of importance. Preliminary architectural requirements may require all or some of the following from the incoming CGN system: Then there is a long list of points. I spent some time on each point, making sure I understood it. Then, reading further, I realized that each point is expanded in the sub section. This should be explained up front. - I see Section 3 CGN Network Deployment Requirements What is the link with the requirements in rfc6888? Yes, there are a few references, for example in section 3.7 and 3.8 for specific requirements, but what about the other requirements. So the requirements in this document are 1. on top of the RFC6888 2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment 3. a complete different set Btw, RFC6888 lists: 3 . Requirements for CGNs What follows is a list of requirements for CGNs. They are in addition to those found in other documents such as [RFC4787 ], [RFC5382 ], and [RFC5508 ]. Again, same question for these extra RFCs. _ Editorial:_ Abstract OLD: This document provides a practical integration model which allows the CGN platform to be integrated into the network meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. NEW: This document provides a practical integration model which allows the CGN platform to be integrated into the_network,_ meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. Section 1. Introduction OLD: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 addresses caches run out on the local local operator. NEW: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 addresses caches run out on the local operator. Section 2. Motivation OLD: The ability to replace IPv4-Only equipment may be out of the control of the operator, and even when it's in the administrative control; it poses both cost and technical challenges as operators build out massive programs for equipment retirement or upgrade. NEW: The ability to replace_IPv4-only_ equipment may be out of the control of the operator, and even when it's in the administrative_control,_ it poses both cost and technical challenges as operators build out massive programs for equipment retirement or upgrade. Section 2. Motivation OLD: This will include solving a number of challenges since subscribers who's connections require translation will have network routing and flow needs which are different from legacy IPv4 connections. NEW: This will include solving a number of challenges since subscribers_whose_connections require translation will have network routing and flow needs which are different from legacy IPv4 connections. Section 3.3 CGN By-Pass OLD: CGN By-pass can be accomplished in many ways, but a simplistic, deterministic and scalable model is preferred. NEW: CGN by-pass can be accomplished in many ways, but a simplistic, deterministic and scalable model is preferred. Section 3.5. Flexible Deployment Options OLD: Depending on hardware capabilities, security practices and IPv4 address availability, the translation environments my need to be segmented and/or scaled over time to meet organic IPv4 demand growth. NEW: Depending on hardware capabilities, security practices and IPv4 address availability, the translation environments may need to be segmented and/or scaled over time to meet organic IPv4 demand growth. - Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment Options Something weird with the section format, at least in the html version - A couple of acronyms - Flexibility should include integration options for common access technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ ASN-GW), and direct Ethernet; - expand large-scale NAT (LSN) Regards, Benoit --------------080402030309090601000903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear authors,

- Section 3. CGN Network Deployment Requirements 
   If a service provider is considering a CGN deployment with a provider
   NAT44 function, there are a number of basic architectural
   requirements which are of importance.  Preliminary architectural
   requirements may require all or some of the following from the
   incoming CGN system:

Then there is a long list of points.
I spent some time on each point, making sure I understood it.
Then, reading further, I realized that each point is expanded in the sub section. 
This should be explained up front.

- I see Section 3 CGN Network Deployment Requirements
What is the link with the requirements in rfc6888?
Yes, there are a few references, for example in section 3.7 and 3.8 for specific requirements, but what about the other requirements. So the requirements in this document are
    1. on top of the RFC6888
    2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment
    3. a complete different set

Btw, RFC6888 lists: 
3.  Requirements for CGNs
   What follows is a list of requirements for CGNs.  They are in
   addition to those found in other documents such as [RFC4787],
   [RFC5382], and [RFC5508].
Again, same question for these extra RFCs.


Editorial:

Abstract
OLD:
   This
   document provides a practical integration model which allows the CGN
   platform to be integrated into the network meeting the connectivity
   needs of the subscriber while being mindful of not disrupting
   existing services and meeting the technical challenges that CGN
   brings.

NEW:
   This
   document provides a practical integration model which allows the CGN
   platform to be integrated into the network, meeting the connectivity
   needs of the subscriber while being mindful of not disrupting
   existing services and meeting the technical challenges that CGN
   brings.

Section 1. Introduction
OLD:
To face this challenge, operators may need to deploy CGN (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local local
   operator. 

NEW:
To face this challenge, operators may need to deploy CGN (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local
   operator.

Section 2. Motivation

OLD:
   The ability to replace IPv4-Only equipment may be out of the control
   of the operator, and even when it's in the administrative control; it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade. 

NEW:
   The ability to replace IPv4-only equipment may be out of the control
   of the operator, and even when it's in the administrative control, it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade.

Section 2. Motivation

OLD:
   This will include solving a number of challenges
   since subscribers who's connections require translation will have
   network routing and flow needs which are different from legacy IPv4
   connections.

NEW:
   This will include solving a number of challenges
   since subscribers whose connections require translation will have
   network routing and flow needs which are different from legacy IPv4
   connections.

Section 3.3 CGN By-Pass

OLD:
   CGN
   By-pass can be accomplished in many ways, but a simplistic,
   deterministic and scalable model is preferred.

NEW:
   CGN
   by-pass can be accomplished in many ways, but a simplistic,
   deterministic and scalable model is preferred.


Section 3.5.  Flexible Deployment Options

OLD:
   Depending on hardware capabilities, security practices and IPv4
   address availability, the translation environments my need to be
   segmented and/or scaled over time to meet organic IPv4 demand growth.

NEW:
   Depending on hardware capabilities, security practices and IPv4
   address availability, the translation environments may need to be
   segmented and/or scaled over time to meet organic IPv4 demand growth.
- Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment Options
Something weird with the section format, at least in the html version

- A couple of acronyms
      - Flexibility should include integration options for common access
      technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/
      ASN-GW), and direct Ethernet;
	
    - expand large-scale NAT (LSN)

Regards, Benoit

--------------080402030309090601000903-- From sob@harvard.edu Mon Oct 7 07:37:52 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB03221F9FD6 for ; Mon, 7 Oct 2013 07:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7ngGaigDQ-1 for ; Mon, 7 Oct 2013 07:37:45 -0700 (PDT) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5F72421E80AD for ; Mon, 7 Oct 2013 07:37:42 -0700 (PDT) Received: from ENTWEDGE0000000.university.harvard.edu (entwedge0000000.university.harvard.edu [10.35.2.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 5212AE9046 for ; Mon, 7 Oct 2013 10:37:32 -0400 (EDT) Received: from ENTWHUBT0000003.university.harvard.edu (192.168.36.24) by ENTWEDGE0000000.university.harvard.edu (10.35.2.151) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 7 Oct 2013 10:37:13 -0400 Received: from ENTWEXMB0000008.university.harvard.edu ([169.254.1.243]) by entwhubt0000003.university.harvard.edu ([192.168.36.24]) with mapi id 14.03.0146.000; Mon, 7 Oct 2013 10:37:32 -0400 From: "Bradner, Scott" To: "opsawg@ietf.org" Thread-Topic: NOMCOM 2013 - Second Call for Nominations - two weeks left Thread-Index: AQHOw08UvdONPAH4L06pZiI4JYk1Fg== Date: Mon, 7 Oct 2013 14:37:31 +0000 Message-ID: <93A4F8BA-1B1F-40E3-90A3-99472CC743E5@harvard.edu> References: <52527773.9020400@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.248.127.162] Content-Type: text/html; charset="us-ascii" Content-ID: <36A566485DBB214A9FA34C91D5314FBC@Exchange.university.harvard.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSAWG] Fwd: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:37:52 -0000
reminder:

-------- Original Message --------
Subject: NOMCOM 2013 - Second Call for Nominations - two weeks left
Date: Fri, 4 Oct 2013 10:31:49 -0700
From: NomCom Chair 2013 <nomcom-chair-2013@ietf.org>
Reply-To: <ie= tf@ietf.org>, &l= t;Nomcom@ietfa.amsl.com>, <= ;Chair@ietfa.amsl.com>, <"2013 <nomcom-chair-2013"@<= a href=3D"http://ietf.org">ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
CC: IETF Discuss List <ietf@ietf.org> 


Nominations for the IESG, IAB, and IAOC are due to the Nomcom by Frida=
y, 18 October, 2013.

Is there someone you work with at IETF who has leadership potential and a g=
rowing track record? Please read the Nomcom call for nominations and consid=
er nominating her or him. Or several folks! Deadline for nominations is Oct=
ober 18.  Nominate soon to give your nominee(s) plenty time to fill in the =
questionnaire. Information about the desired expertise for positions is her=
e:=20
           https://datatracker.ietf.org/nomcom/2013/exp=
ertise

Lots more, including which positions are open, how to make a nomination, an=
d how to=20
send us your feedback on the desired expertise, follows.

IETFers, let's hear from you!  Make nominations, accept nominations!

If you have any questions about the process, feel free to get in touch with=
 me.

Best regards,

Allison for the Nomcom

Allison Mankin=20
Nomcom Chair 2013-14

----- The Info You Need for Nominating -----

The 2013-14 Nominating Committee (Nomcom) is seeking nominations
from now until October 18, 2013. The open positions being considered
by this year's Nomcom can be found later in this section, and also on
this year's Nomcom website:=20

https://datatracker.ietf.org/nomcom/2013/

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2013 home page, or by visiting the following URL:=20

https://datatracker.ietf.org/nomcom/2013/nominate/

Note that nominations made using the web tool require an ietf.org=20
datatracker account. You can create a datatracker ietf.org account=20
if you don't have one already by visiting the following URL:

https://datatracker.ietf.org/accounts/create/

Nominations may also be made by email to nomcom13 at ietf.org.
If you nominate by email, please include the word "Nominate" in t=
he Subject
and indicate in the email who is being nominated, their email address (to
confirm acceptance of the nomination), and the position for which you
are making the nomination. If you use email, please use a separate email fo=
r
each person you nominate, and for each position (if you are nominating one
person for multiple positions).

Self-nomination is welcome!  No need to be shy.

Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing
Nominees" described in RFC 5680.  As stated in RFC 5680: "The lis=
t of
nominees willing to be considered for positions under review in the
current Nomcom cycle is not confidential". Willing nominees for each
position will be listed in a publicly accessible way - anyone with a
datatracker account may access the lists.  In all other ways, the=20
confidentiality requirements of RFC 3777/BCP10 remain in effect.  All
feedback and all Nomcom deliberations will remain confidential and will
not be disclosed. =20

In order to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by the=20
Nomcom on or before October 18, 2013.  Please submit your nominations =20
as early as possible for the sake of your nominees, as we've set the=20
questionnaire submission deadline for October 25, 2013.

The list of people and posts whose terms end with the March 2014 IETF meeti=
ng,=20
and thus the positions for which we are accepting nominations: =20

IAOC
Chris Griffiths

IAB
Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG
Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

Please be resourceful in identifying possible candidates for these
positions, as developing our talent is a very crucial requirement for
the IETF.  Also, please give serious consideration to accepting nominations
you receive. =20
=20
The summaries of the desired expertise for the positions, developed by the=
=20
respective bodies, are found at:

https://datatracker.ietf.org/nomcom/2013/expertise/

In addition to nominations, the Nomcom seeks community input on=20
the positions themselves.  We need and welcome the community's=20
views and input on the jobs within each organization. If you=20
have ideas on the positions' responsibilities (more, less,=20
different), please let us know.  You can send us email about this to
nomcom13 at ietf.org, and we will use this =
feedback actively.

Thank you for your help in nominating a great pool of strong and interestin=
g
nominees!



.



From tom.taylor.stds@gmail.com Mon Oct 7 12:48:15 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A3311E814C for ; Mon, 7 Oct 2013 12:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cGG1LyVAPuX for ; Mon, 7 Oct 2013 12:48:14 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id D4C1011E812B for ; Mon, 7 Oct 2013 12:48:14 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id qd12so16180323ieb.8 for ; Mon, 07 Oct 2013 12:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=YPKOaQj0Tl2NbaGtgaqTv681IWK3LEtwIFQJTlLU8hs=; b=Y2YS8yZUNJZZbYA8iqps+pu+5UcSksC7YddTGwyiym1h4QiXfYP4vSBikj7QLEIjW/ v3Xs2cx+/5P4omiaDmN9lRHkja96HDPq2iC1HudoxAIcEZU62Y2QGFMZ9h7psc82h5Ks kFe8B5ygB7qpkehEpSsRnuK07sM2CsibCUc+VhpddKbMw0aj6bk7IF8yuVbvmzAqJs7c fpjtG433VVqyFLFksyklFMUAyR0DV2ZT59psu9D1w0od2rWJiMShjJcpeA50D9acyg/o gMhNoHYJijAWNq396YGa7tXuenMmXCfdb6PMXlSBw2zqlPgmFnrdJrZJlM15Z+FRt0v2 8V5w== X-Received: by 10.50.45.73 with SMTP id k9mr18565739igm.38.1381175294069; Mon, 07 Oct 2013 12:48:14 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id yt10sm53701igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Oct 2013 12:48:13 -0700 (PDT) Message-ID: <52530FF9.9080904@gmail.com> Date: Mon, 07 Oct 2013 15:48:09 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark.Durrett@overturenetworks.com, Prayson.Pate@overturenetworks.com Subject: [OPSAWG] Comments on draft-xjz-nfv-model-problem-statement-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:48:15 -0000 While looking this draft over, I was concerned about the relationship between Network Function Virtualization (NFV) and SDN, and whether the proposal meant that the IETF would be working on a regional model (ETSI oriented) which overlapped with models being developed and implemented by other organizations. Checking out the web for background information (couldn't find the cited ETSI references), I found this nice comparison table. I reproduce it from Prayson Pate's blog at http://www.overturenetworks.com/blog/tags/network-function-virtualization with kind permission of Overture. If it represents the general understanding of the relationship between the two technologies, my concerns are met. As a general comment, the subject area proposed seems huge. I imagine any charter items would be scoped much more narrowly, so it's a question of figuring out priorities. Tom Taylor Basic Concept SDN Separate control and data, centralize control and programmability of network NFV Relocate network functions from dedicated appliances to generic servers Target Location SDN Campus, data center / cloud NFV Service provider network Target Device SDN Commodity servers and switches NFV Same Initial Applications SDN Cloud orchestration and networking NFV Routers, Firewalls, gateways, CDN, WAN accelerators, SLA assurance New Protocols SDN OpenFlow NFV None Formalization SDN Open Networking Foundation (ONF) NFV ETSI NFV Working Group From panda@hongo.wide.ad.jp Tue Oct 8 05:07:23 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14A021E8198 for ; Tue, 8 Oct 2013 05:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB9oOICYQNF8 for ; Tue, 8 Oct 2013 05:07:18 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id C704621E81B8 for ; Tue, 8 Oct 2013 05:07:02 -0700 (PDT) Received: from [157.82.5.2] (unknown [157.82.5.2]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 8B680108E50A; Tue, 8 Oct 2013 21:07:01 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <5215067C.3040000@cisco.com> Date: Tue, 8 Oct 2013 21:07:01 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4191F938-9BE8-4CD3-AB12-B709E57E04ED@hongo.wide.ad.jp> References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> To: Joe Marcus Clarke X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:07:23 -0000 Hi, I'm working on revising our draft and updating our implementation now. Here I'd like to go on this topic again because I found some points to be discussed. According to this discussion, the MAX-ACCESS of vmMinCpuNumber etc. is left as read-write with "MUST NOT persist" sentence. I think vmCurCpuNumber and vmCurMem are more operational parameters than vmMax* and vmMin*. So shall we change the MAX-ACCESS of these two objects to read-write? It depends on the hypervisor implementation whether these objects as well as vmMax* and vmMin* can be changed without persisted. It also dependes on a guest OS whether vmCur* can be changed for running virtual machines. Could you give us your comments on this? Thank you, Hirochika On Aug 22, 2013, at 3:27 AM, Joe Marcus Clarke = wrote: > On 8/20/13 2:37 AM, Juergen Schoenwaelder wrote: >> On Mon, Aug 19, 2013 at 04:38:28PM -0400, Joe Marcus Clarke wrote: >>>>=20 >>>> We seem to agree on the general scope. Now we have to determine = which >>>> objects reasonably have a MAX-ACCESS or read-write. For me, it = seems >>>> that vmAutoStart likely should indeed be read-only. However, as far = as >>>> I know, Xen allows to change vmMinCpuNumber, vmMaxCpuNumber, = vmMinMem, >>>> and vmMaxMem at runtime without touching persistent config state. >>>=20 >>> If the WG's intent is to leave them as RW (and I can see that = certain >>> HV's allow this sans persistence), then there should be stronger >>> guidance (I think) that indicates that these are operational-only >>> objects and the new values should not be persisted. But that may be = too >>> messy. >=20 > Sorry for the delay. I've been in meetings this week. >=20 >>=20 >> There is already text like this: >>=20 >> Changes to this object may not persist across restarts of the >> hypervisor. >>=20 >> What is your proposal to make this clearer / stronger? >=20 > This leaves it open to one persisting it. You could use normative > language and say, MUST NOT persist... >=20 >>=20 >>> Is there a strong push from operators to toggle these values via = SNMP? >>=20 >> Remeber that this is a MAX-ACCESS. RFC 2578 section 7.3 says that it >> 'defines whether it makes "protocol sense" to read, write and/or >> create an instance of the object, or to include its value in a >> notification'. The compliance statement vmReadOnlyCompliances says >> that write access is not required to be implemented. I believe this = is >> how we commonly do things in a MIB module - we allow read-write >> implementations but we do not require read-write implementations. >> Hence, I prefer to make no changes (except perhaps vmAutoStart but I >> need to check whether there are hypervisors that actually allow to >> change autostart behaviour of the running instance without touching >> persistent config - this might actually be possible). >=20 > That's fair. I was not aware of the ability to adjust VM CPU and = memory > on the fly without touching the config. That said, I struggle to > understand the use case of doing this via SNMP versus a more reliable = API. >=20 > I would also ask that some language be added to the compliance section > like you have in Section 3.2 about only implementing read-write if the > changes can be made dynamically and independent of the config. >=20 > Joe >=20 >>=20 >> /js >>=20 >=20 >=20 > --=20 > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > = --------------------------------------------------------------------------= -- > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --=20 Hirochika Asai , The University of Tokyo From jclarke@cisco.com Tue Oct 8 11:11:11 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B6521E8273 for ; Tue, 8 Oct 2013 11:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNcE82An00l7 for ; Tue, 8 Oct 2013 11:11:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 29B2621E8274 for ; Tue, 8 Oct 2013 11:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4517; q=dns/txt; s=iport; t=1381255866; x=1382465466; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ofATYvwG4IX+jM9MAiIgEhgBQVoiEpZnjzkQlEi/1jY=; b=b21VKni2KfijuONJb7ZTknZNVYUZopthHv9YPzwLx7QyG+vr0rB/MEIj m9xqUCaBIzywUDm4zM3H7smO63dJjXwFvSmlIt+WKAgs/dCOe2nyeoblB 4aPGvG29iejEG526yM5hX5B0F+XnBmiie7XgdO476MM0XcSQKRwADketO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAJhKVFKtJV2b/2dsb2JhbABWA4MHOIN6vTNKgSIWdIIlAQEBAwEBAQEeAUwKAQ4CCw4KAQMFFgoDAgkDAgECAQkMMAYNAQUCAQGHfAYMjGWbVwGSOQQEgSKMU4E5EAcRglaBPAOYAZIAgWaBWiCBNQ X-IronPort-AV: E=Sophos;i="4.90,1057,1371081600"; d="scan'208";a="269407784" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 08 Oct 2013 18:10:51 +0000 Received: from dhcp-10-150-54-156.cisco.com (dhcp-10-150-54-156.cisco.com [10.150.54.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r98IAouq031796; Tue, 8 Oct 2013 18:10:50 GMT Message-ID: <52544AAA.9010200@cisco.com> Date: Tue, 08 Oct 2013 14:10:50 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Hirochika Asai References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> <4191F938-9BE8-4CD3-AB12-B709E57E04ED@hongo.wide.ad.jp> In-Reply-To: <4191F938-9BE8-4CD3-AB12-B709E57E04ED@hongo.wide.ad.jp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:11:11 -0000 On 10/8/13 8:07 AM, Hirochika Asai wrote: > Hi, > > I'm working on revising our draft and updating our implementation > now. Here I'd like to go on this topic again because I found some > points to be discussed. > > According to this discussion, the MAX-ACCESS of vmMinCpuNumber etc. > is left as read-write with "MUST NOT persist" sentence. I believe that is what we arrived at. > > I think vmCurCpuNumber and vmCurMem are more operational parameters > than vmMax* and vmMin*. So shall we change the MAX-ACCESS of these > two objects to read-write? It depends on the hypervisor > implementation whether these objects as well as vmMax* and vmMin* > can be changed without persisted. It also dependes on a guest OS > whether vmCur* can be changed for running virtual machines. > > Could you give us your comments on this? I would be okay with that given my previous related comments and the appropriate verbiage. Joe > > Thank you, > Hirochika > > > On Aug 22, 2013, at 3:27 AM, Joe Marcus Clarke wrote: > >> On 8/20/13 2:37 AM, Juergen Schoenwaelder wrote: >>> On Mon, Aug 19, 2013 at 04:38:28PM -0400, Joe Marcus Clarke wrote: >>>>> >>>>> We seem to agree on the general scope. Now we have to determine which >>>>> objects reasonably have a MAX-ACCESS or read-write. For me, it seems >>>>> that vmAutoStart likely should indeed be read-only. However, as far as >>>>> I know, Xen allows to change vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, >>>>> and vmMaxMem at runtime without touching persistent config state. >>>> >>>> If the WG's intent is to leave them as RW (and I can see that certain >>>> HV's allow this sans persistence), then there should be stronger >>>> guidance (I think) that indicates that these are operational-only >>>> objects and the new values should not be persisted. But that may be too >>>> messy. >> >> Sorry for the delay. I've been in meetings this week. >> >>> >>> There is already text like this: >>> >>> Changes to this object may not persist across restarts of the >>> hypervisor. >>> >>> What is your proposal to make this clearer / stronger? >> >> This leaves it open to one persisting it. You could use normative >> language and say, MUST NOT persist... >> >>> >>>> Is there a strong push from operators to toggle these values via SNMP? >>> >>> Remeber that this is a MAX-ACCESS. RFC 2578 section 7.3 says that it >>> 'defines whether it makes "protocol sense" to read, write and/or >>> create an instance of the object, or to include its value in a >>> notification'. The compliance statement vmReadOnlyCompliances says >>> that write access is not required to be implemented. I believe this is >>> how we commonly do things in a MIB module - we allow read-write >>> implementations but we do not require read-write implementations. >>> Hence, I prefer to make no changes (except perhaps vmAutoStart but I >>> need to check whether there are hypervisors that actually allow to >>> change autostart behaviour of the running instance without touching >>> persistent config - this might actually be possible). >> >> That's fair. I was not aware of the ability to adjust VM CPU and memory >> on the fly without touching the config. That said, I struggle to >> understand the use case of doing this via SNMP versus a more reliable API. >> >> I would also ask that some language be added to the compliance section >> like you have in Section 3.2 about only implementing read-write if the >> changes can be made dynamically and independent of the config. >> >> Joe >> >>> >>> /js >>> >> >> >> -- >> Joe Marcus Clarke, CCIE #5384, | | >> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >> Email: jclarke@cisco.com >> >> ---------------------------------------------------------------------------- >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From panda@hongo.wide.ad.jp Tue Oct 8 22:14:52 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AE321F9DD6 for ; Tue, 8 Oct 2013 22:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLHFQTSIV9+f for ; Tue, 8 Oct 2013 22:14:48 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id CD43421F9A40 for ; Tue, 8 Oct 2013 22:14:47 -0700 (PDT) Received: from [157.82.7.190] (unknown [157.82.7.190]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 7C088108E50A; Wed, 9 Oct 2013 14:14:46 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <52544AAA.9010200@cisco.com> Date: Wed, 9 Oct 2013 14:14:46 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6D8A3F10-798D-4A28-8DE5-2E08E16B122D@hongo.wide.ad.jp> References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> <4191F938-9BE8-4CD3-AB12-B709E57E04ED@hongo.wide.ad.jp> <52544AAA.9010200@cisco.com> To: Joe Marcus Clarke X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 05:14:52 -0000 Dear Joe, Thank you for your comment. Let us change these two objects to = read-write in the next version. Thank you. Hirochika On Oct 9, 2013, at 3:10 AM, Joe Marcus Clarke wrote: > On 10/8/13 8:07 AM, Hirochika Asai wrote: >> Hi, >>=20 >> I'm working on revising our draft and updating our implementation >> now. Here I'd like to go on this topic again because I found some >> points to be discussed. >>=20 >> According to this discussion, the MAX-ACCESS of vmMinCpuNumber etc. >> is left as read-write with "MUST NOT persist" sentence. >=20 > I believe that is what we arrived at. >=20 >>=20 >> I think vmCurCpuNumber and vmCurMem are more operational parameters >> than vmMax* and vmMin*. So shall we change the MAX-ACCESS of these >> two objects to read-write? It depends on the hypervisor >> implementation whether these objects as well as vmMax* and vmMin* >> can be changed without persisted. It also dependes on a guest OS >> whether vmCur* can be changed for running virtual machines. >>=20 >> Could you give us your comments on this? >=20 > I would be okay with that given my previous related comments and the > appropriate verbiage. >=20 > Joe >=20 >>=20 >> Thank you, >> Hirochika >>=20 >>=20 >> On Aug 22, 2013, at 3:27 AM, Joe Marcus Clarke = wrote: >>=20 >>> On 8/20/13 2:37 AM, Juergen Schoenwaelder wrote: >>>> On Mon, Aug 19, 2013 at 04:38:28PM -0400, Joe Marcus Clarke wrote: >>>>>>=20 >>>>>> We seem to agree on the general scope. Now we have to determine = which >>>>>> objects reasonably have a MAX-ACCESS or read-write. For me, it = seems >>>>>> that vmAutoStart likely should indeed be read-only. However, as = far as >>>>>> I know, Xen allows to change vmMinCpuNumber, vmMaxCpuNumber, = vmMinMem, >>>>>> and vmMaxMem at runtime without touching persistent config state. >>>>>=20 >>>>> If the WG's intent is to leave them as RW (and I can see that = certain >>>>> HV's allow this sans persistence), then there should be stronger >>>>> guidance (I think) that indicates that these are operational-only >>>>> objects and the new values should not be persisted. But that may = be too >>>>> messy. >>>=20 >>> Sorry for the delay. I've been in meetings this week. >>>=20 >>>>=20 >>>> There is already text like this: >>>>=20 >>>> Changes to this object may not persist across restarts of the >>>> hypervisor. >>>>=20 >>>> What is your proposal to make this clearer / stronger? >>>=20 >>> This leaves it open to one persisting it. You could use normative >>> language and say, MUST NOT persist... >>>=20 >>>>=20 >>>>> Is there a strong push from operators to toggle these values via = SNMP? >>>>=20 >>>> Remeber that this is a MAX-ACCESS. RFC 2578 section 7.3 says that = it >>>> 'defines whether it makes "protocol sense" to read, write and/or >>>> create an instance of the object, or to include its value in a >>>> notification'. The compliance statement vmReadOnlyCompliances says >>>> that write access is not required to be implemented. I believe this = is >>>> how we commonly do things in a MIB module - we allow read-write >>>> implementations but we do not require read-write implementations. >>>> Hence, I prefer to make no changes (except perhaps vmAutoStart but = I >>>> need to check whether there are hypervisors that actually allow to >>>> change autostart behaviour of the running instance without touching >>>> persistent config - this might actually be possible). >>>=20 >>> That's fair. I was not aware of the ability to adjust VM CPU and = memory >>> on the fly without touching the config. That said, I struggle to >>> understand the use case of doing this via SNMP versus a more = reliable API. >>>=20 >>> I would also ask that some language be added to the compliance = section >>> like you have in Section 3.2 about only implementing read-write if = the >>> changes can be made dynamically and independent of the config. >>>=20 >>> Joe >>>=20 >>>>=20 >>>> /js >>>>=20 >>>=20 >>>=20 >>> --=20 >>> Joe Marcus Clarke, CCIE #5384, | | >>> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >>> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >>> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >>> Email: jclarke@cisco.com >>>=20 >>> = --------------------------------------------------------------------------= -- >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>>=20 >>=20 >=20 >=20 > --=20 > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > = --------------------------------------------------------------------------= -- >=20 --=20 Hirochika Asai , The University of Tokyo From bclaise@cisco.com Thu Oct 10 02:22:55 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B786921F9EDA for ; Thu, 10 Oct 2013 02:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r78uQYnE1i9I for ; Thu, 10 Oct 2013 02:22:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC2021F9E9C for ; Thu, 10 Oct 2013 02:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4182; q=dns/txt; s=iport; t=1381396970; x=1382606570; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=0GRHmcV47AvWFN1sq8JcJz8HFuIn38LgXZnu0AqLH5A=; b=PeV/oB/NbtA7QLn4tK0se4rKFA4RZ27JxxUmOXD2C/9m7XpUIrHbW2f/ 4g0OkkLIljd7CIVbpzVhc2nOl1C7g+C2MsFKm6gEnouHJX7WmBTybrrKU CiMc78BDfrFRJLTO+jiclGtX36aUQ4KzFJmPn8ywh6v1uFjIixp58/Fbk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEFABdxVlKQ/khM/2dsb2JhbABZgwc4iVe4GoEfFm0HgiYBAQR4EQ8dFg8JAwIBAgFFBg0IAQGIAgy5GQSPToQjA5gFhjiLSoMmOg X-IronPort-AV: E=Sophos;i="4.90,1070,1371081600"; d="scan'208,217";a="160522399" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2013 09:22:48 +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 r9A9MhUw012968 for ; Thu, 10 Oct 2013 09:22:45 GMT Message-ID: <525671E3.2010308@cisco.com> Date: Thu, 10 Oct 2013 11:22:43 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <52493407.5000103@cisco.com> In-Reply-To: <52493407.5000103@cisco.com> X-Forwarded-Message-Id: <52493407.5000103@cisco.com> Content-Type: multipart/alternative; boundary="------------010809010803010701090404" Subject: [OPSAWG] CAPWAP work will remain in OPSAWG (as opposed to a short-lived WG) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 09:22:55 -0000 This is a multi-part message in MIME format. --------------010809010803010701090404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Looking at the different CAPWAP related drafts (https://datatracker.ietf.org/doc/search/?name=capwap&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), there were discussions whether we should keep the CAPWAP work in OPSAWG, or create a short-lived WG dedicated to CAPWAP. Regarding a new CAPWAP related WG: Pros: might attract more people Pros: might attract more review, specifically from people outside the IETF (in the case, the IEEE is relevant) Cons: more admin on my side (but this one really doesn't count) Cons: a new WG is not a guarantee for success. Cons: we're a little bit late already Then, I reduced this list to what's important for the IETF mission: The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. From there, only one entry is left: Pros: might attract more review, specifically from people outside the IETF (in the case, the IEEE is relevant) And I believe that we could achieve the same result by highlighting CAPWAP as an area of coordination between the IESG/IEEE. During the last call on September 30th, Dan (as the IEEE liaison) and I did just that. Conclusion: The CAPWAP work will remain in the OPSAWG Regards, Benoit --------------010809010803010701090404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Looking at the different CAPWAP related drafts (https://datatracker.ietf.org/doc/search/?name=capwap&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), there were discussions whether we should keep the CAPWAP work in OPSAWG, or create a short-lived WG dedicated to CAPWAP.

Regarding a new CAPWAP related WG:
Pros: might attract more people
Pros: might attract more review, specifically from people outside the IETF (in the case, the IEEE is relevant)

Cons: more admin on my side (but this one really doesn't count)
Cons: a new WG is not a guarantee for success.
Cons: we're a little bit late already
Then, I reduced this list to what's important for the IETF mission:
The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
From there, only one entry is left:
Pros: might attract more review, specifically from people outside the IETF (in the case, the IEEE is relevant)
And I believe that we could achieve the same result by highlighting CAPWAP as an area of coordination between the IESG/IEEE.
During the last call on September 30th, Dan (as the IEEE liaison) and I did just that.

Conclusion: The CAPWAP work will remain in the OPSAWG

Regards, Benoit
--------------010809010803010701090404-- From sdanda@cisco.com Thu Oct 10 07:59:24 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD6F21E80ED for ; Thu, 10 Oct 2013 07:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCEMEcjbF-6R for ; Thu, 10 Oct 2013 07:59:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 512FA21E8118 for ; Thu, 10 Oct 2013 07:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7991; q=dns/txt; s=iport; t=1381417156; x=1382626756; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qaLFqbWAM5E+lENwAYeQY4TfEePcVlgXaBKkoOdYnpM=; b=ATEpcfksdgBWOJPqL2DSowXIdsNumqHRq6WiX/Di7yXXS43LAmvt5yH2 IyRBJTgHwAejhMGqAH9x4D2bZJ42NVoaD5yloLCt8ab9iSBOzTMhxeINW WbRz0ROyrK6OUXNF9f/Bbom3ok3ezyKc6sGe0Glc7btyywIZI43UeKcYQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFANu/VlKtJXG8/2dsb2JhbABPAQYDgwc4UsBdS4EiFnSCJQEBAQQBAQE3NAQTBAIBCA4DAQMBAQsLAQEBBgkHJwsUAwYIAQEEARACCAGHawMPDK9dCIlwjXwIAYERDxIXBgQHAQEFgweBBAOqB4MkQIEoAgcXIg X-IronPort-AV: E=Sophos;i="4.90,1072,1371081600"; d="scan'208";a="267515178" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 10 Oct 2013 14:59:13 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9AExD0l031646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 14:59:13 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 09:59:13 -0500 From: "Satyanarayana Danda (sdanda)" To: David Harrington , "opsawg@ietf.org" Thread-Topic: [OPSAWG] quick review of draft-sdanda-localauth-mib-00 Thread-Index: Ac66tzPY3aNzZIATTfCsFa1wgLaJ9ALEP8WQ Date: Thu, 10 Oct 2013 14:59:12 +0000 Message-ID: References: <009001cebac4$6b8ef390$42acdab0$@comcast.net> In-Reply-To: <009001cebac4$6b8ef390$42acdab0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.107.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] quick review of draft-sdanda-localauth-mib-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:59:24 -0000 Hi David, Thanks a lot for your time in reviewing the initial draft and your valuable= comments. Taken care all your comments and incorporated in the following updated draf= t. Please find answers in line with [Satya] for each of the comments you had a= nd let us know if you have further comments on the same. http://www.ietf.org/internet-drafts/draft-sdanda-localauth-mib-01.txt Thanks Satya=20 -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= David Harrington Sent: Thursday, September 26, 2013 7:57 PM To: opsawg@ietf.org Subject: [OPSAWG] quick review of draft-sdanda-localauth-mib-00 Hi, I spotted this document announcement and thought I'd take a quick look. I h= ave some comments. --- Technical comments --- 1) I have a concern about making authenticated usernames accessible via a M= IB. This would be very valuable information to an attacker. Most login mechanisms requiring a username/password pair don't identify whe= n the username matches but the password doesn't, to avoid giving an attacke= r an indication they found a valid username.=20 The Security Considerations section has only boilerplate text, with no real= discussion of the security vulnerabilities from publishing such authentica= tion information in a MIB. [Satya] Username as an identity in the network transport would mostly be a = clear test.=20 If it is not via MIB, they might do it via packet capture or any other mea= ns. With knowing username, we can mitigate the risk from an attacker by enforc= ing strong password encryption schemes. =09 We have mentioned the same under 'Security considerations' section. =20 The Security Considerations section doesn't follow the guidelines described= at https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security. The MIB module contains information that is potentially sensitive, and thos= e tables and objects should be listed with a description of why they are se= nsitive. [Satya] We have incorporated the changes as per the guidelines. The need for a standards-track module for locally authenticated users is de= scribed in one or two sentences. I think the need should be justified with = discussion of applicable environments and use cases. [Satya] We have updated the applicable environment and uses-cases. The applicable environment is the Central controller where Information pro= vided by this MIB is used to manage Local authentication information on the= controller. One of the use-cases would be to monitor user access on multiple vendor de= vices like - user login/logout notifications=20 - user account lifetime expiry notifications - User account creation/deletion notifications I think this is the single most important point in my comments. All the res= t of my comments are immaterial if the need of such a standards-track MIB m= odule cannot be justified. 2) Terminology (section 3) adopts the definitions from an Experimental docu= ment [RFC2903] "Generic AAA Architecture" . This document was written by an= IRTF WG. I am not aware that this document and its definitions and mechani= sms have been adopted by the IETF. It is Experimental and not an IETF stand= ards-track document.=20 draft-sdanda-localauth-mib has an Intended Status of standards track. This = normative dependence on an Experimental draft might be problematic. It woul= d be helpful to at least identify which terminology from RFC2903 is adopted= by this document. That way, readers/reviewers might be able to recommend a= different document to use for terminology. [Satya] We wanted to refer 'Authentication' which is relevant for this MIB.= Please let us know if something else can be referred for the same. 3) For compatibility with RFC4181 " Guidelines for Authors and Reviewers of= MIB Documents", Appendix C, I recommend naming the module "LOCAL-AUTH-MIB"= , and using an object naming prefix of localAuth rather than lau. This woul= d also help object name expansions such as lauUserName =3D> localAuthUserUs= erName. [Satya] Corrected this in the new version of the draft. 4) Part of the description of this module states " it is useful collect Aut= hentication logs at the network element". Logging has some issues associate= d with it, such as privacy and the relation to wiretapping [RFC2804], and t= his document doesn't touch upon those issues. If the primary use case is fo= r logging, it would be good to include such a discussion, or to mention the= issues and point to other documents that include discussion of the issues.= Such discussions have been had in the syslog WG, and are currently being d= iscussed in the behave WG regarding CGN logging. [Satya] Thanks for pointing this, we feel this is not relevant and hence re= moved the same from the draft. 5) I think this document could use a good RFC4181 review by the authors. On= quick look, I see some usages I would question, such as 5a) lauUserLoginSuccessCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the number of times, the user logged-in successfully." ::=3D { lauUserEntry 6 } If this is counting, why not use a counter32? [Satya] Yes, changed and updated in the new version of the draft. 5b) To make a standards-rack module useful across vendors/models, etc., des= criptions should describe or recommend what information should be included = in a field. lauUserDescription OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the description of the local user." ::=3D { lauUserEntry 12 } So is this where we should put descriptions of the user like ugly, attracti= ve, tall, short, fat, skinny. And so on? ;-) What type of information shoul= d operators put into this field? How should an NMS or operator expect to use the information found in this f= ield? (and if it isn't useable by an NMS or operator, why are we publishing it in= a MIB?) [Satya] Agree, it doesn't make much sense to NMS applications about knowing= the description of the user account and hence removed in the updated versi= on of the draft. 5c) lauUserPasswordLifetime OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the expiry duration of the password of the local user." ::=3D { lauUserEntry 13 } Are implementers free to choose the UNITS? Or should this be standardized? [Satya] the minimum value for an user account lifetime could be in Secs. He= nce we would recommend the UNITS in Secs as the metric to use for this obj= ect. --- Editorial comments --- 1) This draft could use a good review for its English. Some of the sentence= s are difficult to understand. [Satya] Rephrased the sentences where ever there is a possible confusion of= understanding. 2) " Comments should be made directly to the WSPA mailing list at opsawg@ie= tf.org." - what is the WSPA mailing list? I don't think opsawg@ietf.org is = the WSPA mailing list. [Satya] Corrected this to reflect the right Working Group alias. 3) The description clause of the MODULE-IDENTITY includes a GLOSSARY; this = doesn't seem the right place for a glossary. The glossary here contains onl= y two terms, but the description also uses terms like SSH and dot1x.=20 [Satya] We have added description of SSH and DOT1x in the Glossary section = of the updated draft. David Harrington dbharrington@comcast.net +1-603-828-1401 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From internet-drafts@ietf.org Fri Oct 11 17:41:45 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA67921F9BEF; Fri, 11 Oct 2013 17:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKanneuNj32X; Fri, 11 Oct 2013 17:41:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBD121E8103; Fri, 11 Oct 2013 17:41:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131012004142.16020.15921.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2013 17:41:42 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-hybridmac-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 00:41:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : IEEE 802.11 MAC Profile for CAPWAP Author(s) : Chunju Shao Hui Deng Rajesh S. Pazhyannur Farooq Bari Rong Zhang Satoru Matsushima Filename : draft-ietf-opsawg-capwap-hybridmac-01.txt Pages : 11 Date : 2013-10-11 Abstract: The CAPWAP protocol defines two modes of operation for IEEE 802.11 WTPs: Split and Local MAC (medium access control), as described in [RFC5415],[RFC5416]. Specifically, [RFC5416] describes in detail the division of labor between WTP and AC in the Split and Local MAC modes. Unfortunately, there are many functions that have not yet been clearly defined whether they belong to the WTP or the AC. For example IEEE 802.11 encryption is specified as located in either in the AC or the WTP with no clear way to negotiate where it should be located. This lack of specification leads to interoperability between AC and WTP when AC and WTP come from different vendors. To solve this problem, this specification defines the concept of IEEE 802.11 MAC profile where each profile refers to a table containing an unambigous division of labor between WTP and AC. The profile is used as follows: the WTP informs the AC of the supported profiles and the AC selects the profile when it configures the WTP. 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-capwap-hybridmac-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 panda@hongo.wide.ad.jp Sun Oct 13 20:05:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7C911E81DD for ; Sun, 13 Oct 2013 20:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.204 X-Spam-Level: * X-Spam-Status: No, score=1.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiG6dLVDOezn for ; Sun, 13 Oct 2013 20:05:16 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id B342B11E81DB for ; Sun, 13 Oct 2013 20:05:15 -0700 (PDT) Received: from [157.82.5.127] (unknown [157.82.5.127]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id DA9E4108E8B7; Mon, 14 Oct 2013 12:05:13 +0900 (JST) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Hirochika Asai Date: Mon, 14 Oct 2013 12:05:13 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> To: "opsawg@ietf.org" X-Mailer: Apple Mail (2.1510) Subject: [OPSAWG] Fwd: New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 03:05:21 -0000 Hi folks, Thanks to comments from the mailing list, we've uploaded new version of our I-D: http://tools.ietf.org/html/draft-asai-vmm-mib-05 We would like to submit our I-D as a working group draft soon and have a discussion in the next IETF as a working group draft. Chairs, could you please poll for adoption as a working group item on the mailing list? I've already noticed an error: RFC4133 must be RFC6933. Please let us know if you find any other errors. These errors will be corrected in the next version (the first version for working group draft if adopted). Here, I summarize the updates from the previous version. * According to the thread Joe-1 Modified a paragraph as follows: The design of this MIB module has been derived from enterprise specific MIB modules, namely a MIB module for managing guests of the Xen hypervisor, a MIB module for managing virtual machines controlled by the VMware hypervisor, and a MIB module using the libvirt programming interface to access different hypervisors. + However, this MIB module attempts to generalize + the managed objects to support other hypervisors. * According to the thread Joe-2 Added description of an example of hypervisor-specific case using ENTITY-MIB, but not modified the MIB definition. * According to the thread Joe-3 vmAutoStart --> read-only vmCur* --> read-write vm*Mem vm*Cpu --> description w/ MUST NOT: "Changes to these objects = MUST NOT persist" * According to the thread Joe-5 For the network portion of the hypervisor, added a note on a case equipping virtual switches on the hypervisor as follows: The objects related to virtual switches are not also included in this MIB module though virtual switches shall be placed on a hypervisor. This is because the virtual network interfaces are the lowest abstraction of network resources allocated to a virtual machine. Instead of including the objects related to virtual switches, for example, BRIDGE-MIB and Q-BRIDGE-MIB could be used. * According to the thread Joe-7 Added Notifications for shuttingDown, resuming suspending, migrating, = and blocked # I think we still need discussion at this point. * Others Modified VirtualMachineOperState to be more clear. Revised the description of VirtualMachine*Index. Fixed some typos. Best regards, Hirochika Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-asai-vmm-mib-05.txt > Date: October 13, 2013 3:19:14 PM GMT+09:00 > To: Yuji Sekiya , Cathy Zhou = , Tina Tsou , = Keiichi Shima , Juergen Schoenwaelder = , Michael MacFaden = , Hirochika Asai , Hiroshi Esaki = >=20 >=20 > A new version of I-D, draft-asai-vmm-mib-05.txt > has been successfully submitted by Hirochika Asai and posted to the > IETF repository. >=20 > Filename: draft-asai-vmm-mib > Revision: 05 > Title: Management Information Base for Virtual = Machines Controlled by a Hypervisor > Creation date: 2013-10-13 > Group: Individual Submission > Number of pages: 56 > URL: = http://www.ietf.org/internet-drafts/draft-asai-vmm-mib-05.txt > Status: http://datatracker.ietf.org/doc/draft-asai-vmm-mib > Htmlized: http://tools.ietf.org/html/draft-asai-vmm-mib-05 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-asai-vmm-mib-05 >=20 > 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). >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 --=20 Hirochika Asai , The University of Tokyo From mrm@vmware.com Mon Oct 14 06:47:50 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A206B21E8165 for ; Mon, 14 Oct 2013 06:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q59j3V-uFhG for ; Mon, 14 Oct 2013 06:47:45 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7883921E8168 for ; Mon, 14 Oct 2013 06:47:45 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id D1D6428D6D; Mon, 14 Oct 2013 06:47:44 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id CE0D3402B4; Mon, 14 Oct 2013 06:47:44 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id BD248E0100; Mon, 14 Oct 2013 06:47:44 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Mon, 14 Oct 2013 06:47:44 -0700 (PDT) Date: Mon, 14 Oct 2013 06:47:44 -0700 (PDT) From: Michael MacFaden To: Hirochika Asai Message-ID: <1193937661.420734.1381758464561.JavaMail.root@vmware.com> In-Reply-To: <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: New Version Notification for draft-asai-vmm-mib-05.txt Thread-Index: wVkujEFyLV7cpVH/F3OT833huhJ0KQ== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 13:47:50 -0000 Asai-san writes: > This is because the virtual network interfaces are > the lowest abstraction of network resources allocated > to a virtual machine. > Instead of including the objects related to virtual switches, > for example, BRIDGE-MIB > and Q-BRIDGE-MIB could be used. Just checking, you meant for this to be an informative reference right? I'd prefer if we change the example mib module to the IEEE mib module. RFC 4188 is the last of its kind. IETF gave this mib module and most layer 2 related mibs over to IEEE. ESXi for example implements IEEE8021-Q-BRIDGE-MIB, REVISION 200810150000Z. Thanks, Mike MacFaden From rpazhyan@cisco.com Mon Oct 14 07:46:23 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7ACC11E813F for ; Mon, 14 Oct 2013 07:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GNFkuAFlgT3 for ; Mon, 14 Oct 2013 07:46:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A0B0611E8140 for ; Mon, 14 Oct 2013 07:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3046; q=dns/txt; s=iport; t=1381761978; x=1382971578; h=from:to:subject:date:message-id:mime-version; bh=snwRANOHEuz539luACNQ1BtQxoV90V0cOjpQSURfB50=; b=VPn52sdrhMTYlo5JGjQtW++bqiJnM+syMFYst1/KrFPPFC+JoioFGlF4 vv0sZaEvoIIyuxyFsBAC+b0x0AP2PfYsjD76m2ALM/GEu7lknl5O7ahhB 2N/CCqQ/8BjcrVRSULdMeA0K/qhZzzVpoeDHGpvQkCrC/ahHh9vHY15vw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAAgDXFKtJXG8/2dsb2JhbABZgkNEOFLBb4EkFnSCJwEELV4BDB5WJgEEG4d9AQycQaE1BI8hLYMqgQQDqgeDJIIp X-IronPort-AV: E=Sophos;i="4.93,492,1378857600"; d="scan'208,217";a="271876662" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 14 Oct 2013 14:46:18 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9EEkH9M022883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 14 Oct 2013 14:46:17 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.202]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 09:46:17 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "opsawg@ietf.org" Thread-Topic: Seeking comments on draft "IEEE 802.11 MAC Profile for CAPWAP" Thread-Index: Ac7I7CILQDZSqPp7TqGmZS+kMlC6OQ== Date: Mon, 14 Oct 2013 14:46:17 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320EC9109@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.13] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320EC9109xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: [OPSAWG] Seeking comments on draft "IEEE 802.11 MAC Profile for CAPWAP" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:46:24 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320EC9109xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings... We have submitted a new version of the draft (previously titled "Hybrid MAC= -Model for CAPWAP". While solving the same problem as in the original draft, this takes a diffe= rent approach. We introduce a new element IEEE 802.11 MAC Profile. This pro= file defines the functional split between the MAC and AC. The idea of usin= g profiles was based on discussion in the last working groups meeting as we= ll as offline meetings with other participants. While somewhat similar to m= ode defined in RFC 5416, this solves the problem with the ambiguity in the = mode definitions in RFC 5416 as well as enables different functional splits= to be defined in the future. The link to the draft is https://datatracker.= ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac We are soliciting comments and feedback. Thanks Regards Rajesh --_000_4ED2E36A22261145861BAB2C24088B4320EC9109xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greetings…
 
We have submitted a new version of the draft (previously titled “= ;Hybrid MAC-Model for CAPWAP”.
While solving the same problem as in the original draft, this takes a different ap= proach. We introduce a new element IEEE 802.11 MAC Profile. This profile de= fines the functional split between the MAC and AC.  The idea of using profiles was based on discussion in the= last working groups meeting as well as offline meetings with other partici= pants. While somewhat similar to mode defined in RFC 5416, this solves the = problem with the ambiguity in the mode definitions in RFC 5416 as well as enables different functional splits to b= e defined in the future. T= he link to the draft is = https://datatracker.ietf.org/doc/draft-i= etf-opsawg-capwap-hybridmac
 
We are soliciting comments and feedback.
 
Thanks
 
Regards
 
Rajesh
 
 --_000_4ED2E36A22261145861BAB2C24088B4320EC9109xmbalnx09ciscoc_-- From tom.taylor.stds@gmail.com Mon Oct 14 17:29:52 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6DF21F93B9 for ; Mon, 14 Oct 2013 17:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-WC30W5prYC for ; Mon, 14 Oct 2013 17:29:52 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1604D21F935A for ; Mon, 14 Oct 2013 17:29:51 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so15857068iec.2 for ; Mon, 14 Oct 2013 17:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hWexkuxEnfOy4X7wqftBNQDySieouBS4zLenXi3/3gc=; b=XL8sW6p/vKTnLYPlnWT4591MLVjR/JZhaKmYBlFjZJwnuTK9Tt8SaDn3zd/b61SeZX +4yxq/zujEl5RbWTUK/Hvf4lKcUdI7BLpBePfQEX1NfJEyOetRiAPRs//O5K+w+r21bI fBrdWeIt4cNajVCHnHc9lv8GXuxE2b9he5eJgXxjTaYb5yLsoiShpQJ2cU6tNImxJXAV o/4NNArAqvsCTYS3G9QKbbmsGsjGUVcqw7GZN+rKzV32CyZAy5dfO5ZSi/BeQeSqUAkO 0XP8ujtXpSsF7/0cxWITEKdjttb9WecNKkjI8qpUH8fZqSRspwon/priHW3WlWh/w+Lc 4kjA== X-Received: by 10.50.2.67 with SMTP id 3mr14983841igs.41.1381796990441; Mon, 14 Oct 2013 17:29:50 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id cy15sm568095igc.1.2013.10.14.17.29.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Oct 2013 17:29:49 -0700 (PDT) Message-ID: <525C8C78.6090304@gmail.com> Date: Mon, 14 Oct 2013 20:29:44 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Warren Kumari References: <5245BC81.3030809@gmail.com> <5B23BF80-BB0C-4EB0-869C-FFB2605921BE@kumari.net> In-Reply-To: <5B23BF80-BB0C-4EB0-869C-FFB2605921BE@kumari.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Plea for action: draft-schoenw-opsawg-nm-dhc-04 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 00:29:52 -0000 Sorry I haven't replied. I called on colleagues who knew the context better for help, but first vacation and now, pressure to complete other drafts has prevented them from giving any attention to this. Until the use case becomes clearer I guess I'll let it rest. Tom Taylor On 30/09/2013 5:38 PM, Warren Kumari wrote: > > On Sep 27, 2013, at 1:12 PM, Tom Taylor wrote: > >> No I have no intention of seeking another meeting slot for this little document. But I do ask whether people can approve it in principle, so we can put through the necessary Standards Action to get the DHCP/DHCPv6 options in place. >> >> Again, this is about DHCP options to tell a router where to find two management entities, the SYSLOG Collector and the SNMP Notification Receiver, for use primarily in configuring mobile backhaul. > > > > I must admit to being a little confused by this draft / the use case. > > The draft says: > "The Dynamic Host Configuration Protocol (DHCPv4 [RFC2131] and DHCPv6 > [RFC3315]) is a relevant tool for this purpose. It provides a number > of existing options to allow a node to acquire its configuration file > and to locate key servers in the network. " > > Presumably the node connects to $something and downloads a (node specific) config file -- why is the SYSLOG and SNMP devices not simply defined in the config file? > > Or, is the intent that the nodes will all download the *same* config file, and then use DHCP options to provide the node specific bits? > > If the latter, is [DNS, Hostname, SYSLOG, SNMP] the only things that differ between nodes? What about interface names / addresses / ssh keys / etc? > I'm so not a mobile operator, so maybe I'm just not understanding what sorts of things these nodes do and so what sort of node specific config they need. > > I'm not disagreeing with the concept, I'm more intrigued… > > > W > ... From cathy.zhou@huawei.com Mon Oct 14 19:53:54 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE1E21E8142 for ; Mon, 14 Oct 2013 19:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUyrYOC+KqiC for ; Mon, 14 Oct 2013 19:53:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 866D821E80B6 for ; Mon, 14 Oct 2013 19:53:47 -0700 (PDT) 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 AZC02077; Tue, 15 Oct 2013 02:53:46 +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.146.0; Tue, 15 Oct 2013 03:52:57 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 15 Oct 2013 03:53:45 +0100 Received: from SZXEML513-MBS.china.huawei.com ([169.254.8.106]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.03.0146.000; Tue, 15 Oct 2013 10:53:38 +0800 From: "Zhouqian (Cathy)" To: Tom Taylor , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Comments on draft-xjz-nfv-model-problem-statement-00.txt Thread-Index: AQHOw5YvUFq3jEz1dEuVUGS9u7+YUpn1GDBQ Date: Tue, 15 Oct 2013 02:53:37 +0000 Message-ID: References: <52530FF9.9080904@gmail.com> In-Reply-To: <52530FF9.9080904@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Mark.Durrett@overturenetworks.com" , "Prayson.Pate@overturenetworks.com" Subject: Re: [OPSAWG] Comments on draft-xjz-nfv-model-problem-statement-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 02:53:54 -0000 Hi Tom, Sorry for the later reply and thanks for your comments. Please see inline. Best Regards, Cathy > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Tuesday, October 08, 2013 3:48 AM > To: opsawg@ietf.org > Cc: Mark.Durrett@overturenetworks.com; > Prayson.Pate@overturenetworks.com > Subject: [OPSAWG] Comments on > draft-xjz-nfv-model-problem-statement-00.txt >=20 > While looking this draft over, I was concerned about the relationship > between Network Function Virtualization (NFV) and SDN, and whether the > proposal meant that the IETF would be working on a regional model (ETSI > oriented) which overlapped with models being developed and implemented > by other organizations.=20 In my understanding, ETSI will focus on the information model only . It wil= l not=20 describe the detailed protocol and data models, which may be the work of ot= her=20 SDOs, e.g., IETF, OASIS and etc., if we'd like to use the protocols/languag= es from=20 these SDOs. >checking out the web for background information > (couldn't find the cited ETSI references), I found this nice comparison > table. I reproduce it from Prayson Pate's blog at >=20 > http://www.overturenetworks.com/blog/tags/network-function-virtualizati > on >=20 > with kind permission of Overture. If it represents the general > understanding of the relationship between the two technologies, my > concerns are met. >=20 > As a general comment, the subject area proposed seems huge. I imagine > any charter items would be scoped much more narrowly, so it's a question > of figuring out priorities. Maybe the name seems a bit huge, we can determine it later. But the scope i= s not=20 huge actually. We will not work on all the NFV data models, rather, we only= focus=20 on three parts: NFV Service, VNF Forwarding Graph and VNF. To define the YA= NG=20 data models of the three elements is our ultimate goal. >=20 >=20 > Tom Taylor >=20 >=20 > Basic Concept >=20 > SDN Separate control and data, centralize control > and programmability of network >=20 > NFV Relocate network functions from dedicated > appliances to generic servers >=20 > Target Location >=20 > SDN Campus, data center / cloud >=20 > NFV Service provider network >=20 > Target Device >=20 > SDN Commodity servers and switches >=20 > NFV Same >=20 > Initial Applications >=20 > SDN Cloud orchestration and networking >=20 > NFV Routers, Firewalls, gateways, CDN, > WAN accelerators, SLA assurance >=20 > New Protocols >=20 > SDN OpenFlow >=20 > NFV None >=20 > Formalization >=20 > SDN Open Networking Foundation (ONF) >=20 > NFV ETSI NFV Working Group > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From panda@hongo.wide.ad.jp Tue Oct 15 00:29:02 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8013C21E81B3 for ; Tue, 15 Oct 2013 00:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.004 X-Spam-Level: * X-Spam-Status: No, score=1.004 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOX5zDbRzIxe for ; Tue, 15 Oct 2013 00:28:56 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id B35E411E810A for ; Tue, 15 Oct 2013 00:28:56 -0700 (PDT) Received: from [157.82.7.5] (unknown [157.82.7.5]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 68EE6108E8B7; Tue, 15 Oct 2013 16:28:55 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <1193937661.420734.1381758464561.JavaMail.root@vmware.com> Date: Tue, 15 Oct 2013 16:28:57 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <3456AAED-1E67-4AB5-ABA3-686E1CFAD13E@hongo.wide.ad.jp> References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <1193937661.420734.1381758464561.JavaMail.root@vmware.com> To: Michael MacFaden X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 07:29:02 -0000 Dear Mike, Thank you for pointing that out. I'll remove RFC4188 and RFC4363 from normative references and add them to informative references in order to make sure these are informative. Thank you. Hirochika On Oct 14, 2013, at 10:47 PM, Michael MacFaden wrote: >=20 > Asai-san writes: >=20 >> This is because the virtual network interfaces are >> the lowest abstraction of network resources allocated >> to a virtual machine. >> Instead of including the objects related to virtual switches, >> for example, BRIDGE-MIB >> and Q-BRIDGE-MIB could be used. >=20 > Just checking, you meant for this to be an informative reference = right? > I'd prefer if we change the example mib module to the IEEE mib module. > RFC 4188 is the last of its kind. IETF gave this mib module and most = layer 2 related mibs > over to IEEE. ESXi for example implements IEEE8021-Q-BRIDGE-MIB, = REVISION 200810150000Z. >=20 > Thanks, > Mike MacFaden >=20 --=20 Hirochika Asai , The University of Tokyo From jclarke@cisco.com Tue Oct 15 07:42:38 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DEA21E81CC for ; Tue, 15 Oct 2013 07:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALyzDgf4i1gf for ; Tue, 15 Oct 2013 07:42:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 844CF21E80BB for ; Tue, 15 Oct 2013 07:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5659; q=dns/txt; s=iport; t=1381848146; x=1383057746; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=feDXkMZVSvw50NGzyOsiYuqpArWqxy2PsHhMKVtht0Y=; b=MkvnzIvvJEySKYnI1Kt9lmfiPKLc4FSQ4VC3XjCvlxinN814/v9/sowq mkgMGU8uPh2M4pIIWhAvBvYx4/l5ZotdND0fdUp4JTL20SIPPuVQ2g6G0 SyTMJgsOKkJu3LUSYQPmCxTFPyWfq96+5AYKMiIWE+1pH821neOo/dilt 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFANRTXVKtJV2Z/2dsb2JhbABXA4MHOEzCK4EgFnSCJQEBAQMBJxE2CQEPAgsOAgEDAQIBCRYPCQMCAQIBCTQIBgEMBgIBAQULh2wGBwW9KgSNfYE5FwYLhBQDmASBL5BTg0AggSsJFwM X-IronPort-AV: E=Sophos;i="4.93,499,1378857600"; d="scan'208";a="272323305" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2013 14:42:23 +0000 Received: from rtp-jclarke-8919.cisco.com (rtp-jclarke-8919.cisco.com [10.117.46.170]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FEgMhC010397; Tue, 15 Oct 2013 14:42:22 GMT Message-ID: <525D544E.1030507@cisco.com> Date: Tue, 15 Oct 2013 10:42:22 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Hirochika Asai , "opsawg@ietf.org" References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> In-Reply-To: <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:42:39 -0000 On 10/13/13 11:05 PM, Hirochika Asai wrote: > Hi folks, > > Thanks to comments from the mailing list, we've uploaded new version > of our I-D: http://tools.ietf.org/html/draft-asai-vmm-mib-05 > > We would like to submit our I-D as a working group draft soon and > have a discussion in the next IETF as a working group draft. > Chairs, could you please poll for adoption as a working group item > on the mailing list? > > I've already noticed an error: RFC4133 must be RFC6933. Please let > us know if you find any other errors. These errors will be > corrected in the next version (the first version for working group > draft if adopted). Overall, I like the changes. Thanks! NIT: VirtualMachineAdminState: The destroy(5) state really doesn't match in terms of tense. What about destroyed(5)? That said, since this is something one can set, perhaps present tense like run, pause, suspend, etc. make sense. Thanks for fleshing out the state definitions :-). NIT (maybe a minor issue): VirtualMachineAutoStart: Again, tense. Here, I think past tense works best since we decided this would reflect a read-only state. I think enabled and disabled work best. In terms of the new notifications, why enumerate all states as notifications? My original comment suggested a single state change notification where the new and previous state would be available as objects (note: this would require the definition of a previous state object). It just seems like the way you've implemented it would be harder to scale if new states need to be added in the future. Joe > > > Here, I summarize the updates from the previous version. > > * According to the thread Joe-1 > Modified a paragraph as follows: > > The design of this MIB module has been derived from enterprise > specific MIB modules, namely a MIB module for managing guests of the > Xen hypervisor, a MIB module for managing virtual machines controlled > by the VMware hypervisor, and a MIB module using the libvirt > programming interface to access different hypervisors. > + However, this MIB module attempts to generalize > + the managed objects to support other hypervisors. > > * According to the thread Joe-2 > Added description of an example of hypervisor-specific case > using ENTITY-MIB, but not modified the MIB definition. > > * According to the thread Joe-3 > vmAutoStart --> read-only > vmCur* --> read-write > vm*Mem vm*Cpu --> description w/ MUST NOT: "Changes to these objects MUST NOT persist" > > * According to the thread Joe-5 > For the network portion of the hypervisor, added a note on a case > equipping virtual switches on the hypervisor as follows: > The objects related to virtual switches > are not also included in this MIB module > though virtual switches shall be placed on a hypervisor. > This is because the virtual network interfaces are > the lowest abstraction of network resources allocated > to a virtual machine. > Instead of including the objects related to virtual switches, > for example, BRIDGE-MIB > and Q-BRIDGE-MIB could be used. > > * According to the thread Joe-7 > Added Notifications for shuttingDown, resuming suspending, migrating, and blocked > # I think we still need discussion at this point. > > * Others > Modified VirtualMachineOperState to be more clear. > Revised the description of VirtualMachine*Index. > Fixed some typos. > > > Best regards, > Hirochika > > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-asai-vmm-mib-05.txt >> Date: October 13, 2013 3:19:14 PM GMT+09:00 >> To: Yuji Sekiya , Cathy Zhou , Tina Tsou , Keiichi Shima , Juergen Schoenwaelder , Michael MacFaden , Hirochika Asai , Hiroshi Esaki >> >> >> A new version of I-D, draft-asai-vmm-mib-05.txt >> has been successfully submitted by Hirochika Asai and posted to the >> IETF repository. >> >> Filename: draft-asai-vmm-mib >> Revision: 05 >> Title: Management Information Base for Virtual Machines Controlled by a Hypervisor >> Creation date: 2013-10-13 >> Group: Individual Submission >> Number of pages: 56 >> URL: http://www.ietf.org/internet-drafts/draft-asai-vmm-mib-05.txt >> Status: http://datatracker.ietf.org/doc/draft-asai-vmm-mib >> Htmlized: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-asai-vmm-mib-05 >> >> 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). >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From shima@wide.ad.jp Thu Oct 17 01:55:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A27D11E8114 for ; Thu, 17 Oct 2013 01:55:20 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkJbk2cen5un for ; Thu, 17 Oct 2013 01:55:19 -0700 (PDT) Received: from sh.wide.ad.jp (sh.wide.ad.jp [IPv6:2001:200:0:1001::6]) by ietfa.amsl.com (Postfix) with ESMTP id 402BC11E80F9 for ; Thu, 17 Oct 2013 01:55:16 -0700 (PDT) Received: from [IPv6:2001:240:11e:c01:970:33f6:da3:a215] ([IPv6:2001:240:11e:c01:970:33f6:da3:a215]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.21) with ESMTP id r9H8tDQb007021 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 17 Oct 2013 17:55:13 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Keiichi SHIMA In-Reply-To: <525D544E.1030507@cisco.com> Date: Thu, 17 Oct 2013 17:55:13 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <525D544E.1030507@cisco.com> To: Joe Marcus Clarke X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 08:55:21 -0000 Hello, On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: > In terms of the new notifications, why enumerate all states as = notifications? My original comment suggested a single state change = notification where the new and previous state would be available as = objects (note: this would require the definition of a previous state = object). It just seems like the way you've implemented it would be = harder to scale if new states need to be added in the future. Ah, I misunderstood your comment. I did the change actually. Consolidating all the notification messages (maybe we will have two = eventually, one is for a per VM notification, and the other is for a = bulk notification) may be reasonable. # we can even unify a per vm notification and a bulk notification, but = maybe it is not a good idea? If there is no strong opinion for not to unify the notification = messages, then we will do the change and resubmit an updated version = before the cut-off date (next Monday). --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: > On 10/13/13 11:05 PM, Hirochika Asai wrote: >> Hi folks, >>=20 >> Thanks to comments from the mailing list, we've uploaded new version >> of our I-D: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>=20 >> We would like to submit our I-D as a working group draft soon and >> have a discussion in the next IETF as a working group draft. >> Chairs, could you please poll for adoption as a working group item >> on the mailing list? >>=20 >> I've already noticed an error: RFC4133 must be RFC6933. Please let >> us know if you find any other errors. These errors will be >> corrected in the next version (the first version for working group >> draft if adopted). >=20 > Overall, I like the changes. Thanks! >=20 > NIT: VirtualMachineAdminState: >=20 > The destroy(5) state really doesn't match in terms of tense. What = about destroyed(5)? That said, since this is something one can set, = perhaps present tense like run, pause, suspend, etc. make sense. >=20 > Thanks for fleshing out the state definitions :-). >=20 > NIT (maybe a minor issue): VirtualMachineAutoStart: >=20 > Again, tense. Here, I think past tense works best since we decided = this would reflect a read-only state. I think enabled and disabled work = best. >=20 > In terms of the new notifications, why enumerate all states as = notifications? My original comment suggested a single state change = notification where the new and previous state would be available as = objects (note: this would require the definition of a previous state = object). It just seems like the way you've implemented it would be = harder to scale if new states need to be added in the future. >=20 > Joe >=20 >>=20 >>=20 >> Here, I summarize the updates from the previous version. >>=20 >> * According to the thread Joe-1 >> Modified a paragraph as follows: >>=20 >> The design of this MIB module has been derived from enterprise >> specific MIB modules, namely a MIB module for managing guests of the >> Xen hypervisor, a MIB module for managing virtual machines controlled >> by the VMware hypervisor, and a MIB module using the libvirt >> programming interface to access different hypervisors. >> + However, this MIB module attempts to generalize >> + the managed objects to support other hypervisors. >>=20 >> * According to the thread Joe-2 >> Added description of an example of hypervisor-specific case >> using ENTITY-MIB, but not modified the MIB definition. >>=20 >> * According to the thread Joe-3 >> vmAutoStart --> read-only >> vmCur* --> read-write >> vm*Mem vm*Cpu --> description w/ MUST NOT: "Changes to these objects = MUST NOT persist" >>=20 >> * According to the thread Joe-5 >> For the network portion of the hypervisor, added a note on a case >> equipping virtual switches on the hypervisor as follows: >> The objects related to virtual switches >> are not also included in this MIB module >> though virtual switches shall be placed on a hypervisor. >> This is because the virtual network interfaces are >> the lowest abstraction of network resources allocated >> to a virtual machine. >> Instead of including the objects related to virtual switches, >> for example, BRIDGE-MIB >> and Q-BRIDGE-MIB could be used. >>=20 >> * According to the thread Joe-7 >> Added Notifications for shuttingDown, resuming suspending, migrating, = and blocked >> # I think we still need discussion at this point. >>=20 >> * Others >> Modified VirtualMachineOperState to be more clear. >> Revised the description of VirtualMachine*Index. >> Fixed some typos. >>=20 >>=20 >> Best regards, >> Hirochika >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-asai-vmm-mib-05.txt >>> Date: October 13, 2013 3:19:14 PM GMT+09:00 >>> To: Yuji Sekiya , Cathy Zhou = , Tina Tsou , = Keiichi Shima , Juergen Schoenwaelder = , Michael MacFaden = , Hirochika Asai , Hiroshi Esaki = >>>=20 >>>=20 >>> A new version of I-D, draft-asai-vmm-mib-05.txt >>> has been successfully submitted by Hirochika Asai and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-asai-vmm-mib >>> Revision: 05 >>> Title: Management Information Base for Virtual = Machines Controlled by a Hypervisor >>> Creation date: 2013-10-13 >>> Group: Individual Submission >>> Number of pages: 56 >>> URL: = http://www.ietf.org/internet-drafts/draft-asai-vmm-mib-05.txt >>> Status: http://datatracker.ietf.org/doc/draft-asai-vmm-mib >>> Htmlized: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-asai-vmm-mib-05 >>>=20 >>> 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). >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>=20 >=20 >=20 > --=20 > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > = --------------------------------------------------------------------------= -- > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From j.schoenwaelder@jacobs-university.de Thu Oct 17 02:17:26 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666B621F92B5 for ; Thu, 17 Oct 2013 02:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZOIUGdTuVce for ; Thu, 17 Oct 2013 02:17:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0111E8243 for ; Thu, 17 Oct 2013 02:17:16 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CA1420026; Thu, 17 Oct 2013 11:17:15 +0200 (CEST) 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 BEBoj2k2p-IN; Thu, 17 Oct 2013 11:17:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5099B20017; Thu, 17 Oct 2013 11:17:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E53CA28DD2DD; Thu, 17 Oct 2013 11:17:08 +0200 (CEST) Date: Thu, 17 Oct 2013 11:17:08 +0200 From: Juergen Schoenwaelder To: Keiichi SHIMA Message-ID: <20131017091708.GA31344@elstar.local> Mail-Followup-To: Keiichi SHIMA , Joe Marcus Clarke , opsawg@ietf.org References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <525D544E.1030507@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 09:17:26 -0000 On Thu, Oct 17, 2013 at 05:55:13PM +0900, Keiichi SHIMA wrote: > Hello, > > On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: > > > In terms of the new notifications, why enumerate all states as notifications? My original comment suggested a single state change notification where the new and previous state would be available as objects (note: this would require the definition of a previous state object). It just seems like the way you've implemented it would be harder to scale if new states need to be added in the future. > > Ah, I misunderstood your comment. I did the change actually. > > Consolidating all the notification messages (maybe we will have two eventually, one is for a per VM notification, and the other is for a bulk notification) may be reasonable. > > # we can even unify a per vm notification and a bulk notification, but maybe it is not a good idea? > > If there is no strong opinion for not to unify the notification messages, then we will do the change and resubmit an updated version before the cut-off date (next Monday). > I had this design (generic state change notifications) in my original MIB module but then I got convinced by Michael that many real-world applications prefer to have the notification type be specific so that they can react to the different state changes by simply looking at the notification type (without having to look into the notification payload). This is why we got to the current design. We should be careful here and take care to produce something that existing notification receivers find 'easy' to process. The number of states we have should be small and ideally not change over time, so the implementation costs on the agent side likely are not big. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From shima@wide.ad.jp Thu Oct 17 02:38:26 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696AD11E8271 for ; Thu, 17 Oct 2013 02:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+EbCjwyBu2H for ; Thu, 17 Oct 2013 02:38:25 -0700 (PDT) Received: from sh.wide.ad.jp (sh.wide.ad.jp [IPv6:2001:200:0:1001::6]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8F011E8278 for ; Thu, 17 Oct 2013 02:38:15 -0700 (PDT) Received: from [IPv6:2001:240:11e:c01:970:33f6:da3:a215] ([IPv6:2001:240:11e:c01:970:33f6:da3:a215]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.21) with ESMTP id r9H9cDQZ005656 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 17 Oct 2013 18:38:14 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Keiichi SHIMA In-Reply-To: <20131017091708.GA31344@elstar.local> Date: Thu, 17 Oct 2013 18:38:13 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <23E87CB3-097A-45EB-8146-2B8E749E9394@wide.ad.jp> References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <525D544E.1030507@cisco.com> <20131017091708.GA31344@elstar.local> To: Joe Marcus Clarke , Juergen Schoenwaelder X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 09:38:26 -0000 Hello Juergen and Joe, >> If there is no strong opinion for not to unify the notification = messages, then we will do the change and resubmit an updated version = before the cut-off date (next Monday). >>=20 >=20 > I had this design (generic state change notifications) in my original > MIB module but then I got convinced by Michael that many real-world > applications prefer to have the notification type be specific so that > they can react to the different state changes by simply looking at the > notification type (without having to look into the notification > payload). This is why we got to the current design. >=20 > We should be careful here and take care to produce something that > existing notification receivers find 'easy' to process. The number of > states we have should be small and ideally not change over time, so > the implementation costs on the agent side likely are not big. I think this is a good point. Joe, do you have any strong objection for the above approach? If you = can live with either ways, then we will keep the current style. --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/10/17, at 18:17, Juergen Schoenwaelder = wrote: > On Thu, Oct 17, 2013 at 05:55:13PM +0900, Keiichi SHIMA wrote: >> Hello, >>=20 >> On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: >>=20 >>> In terms of the new notifications, why enumerate all states as = notifications? My original comment suggested a single state change = notification where the new and previous state would be available as = objects (note: this would require the definition of a previous state = object). It just seems like the way you've implemented it would be = harder to scale if new states need to be added in the future. >>=20 >> Ah, I misunderstood your comment. I did the change actually. >>=20 >> Consolidating all the notification messages (maybe we will have two = eventually, one is for a per VM notification, and the other is for a = bulk notification) may be reasonable. >>=20 >> # we can even unify a per vm notification and a bulk notification, = but maybe it is not a good idea? >>=20 >> If there is no strong opinion for not to unify the notification = messages, then we will do the change and resubmit an updated version = before the cut-off date (next Monday). >>=20 >=20 > I had this design (generic state change notifications) in my original > MIB module but then I got convinced by Michael that many real-world > applications prefer to have the notification type be specific so that > they can react to the different state changes by simply looking at the > notification type (without having to look into the notification > payload). This is why we got to the current design. >=20 > We should be careful here and take care to produce something that > existing notification receivers find 'easy' to process. The number of > states we have should be small and ideally not change over time, so > the implementation costs on the agent side likely are not big. >=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 From shima@wide.ad.jp Thu Oct 17 03:55:22 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737E611E8162 for ; Thu, 17 Oct 2013 03:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXTSsBfTDxeX for ; Thu, 17 Oct 2013 03:55:21 -0700 (PDT) Received: from sh.wide.ad.jp (sh.wide.ad.jp [IPv6:2001:200:0:1001::6]) by ietfa.amsl.com (Postfix) with ESMTP id 7F77711E8174 for ; Thu, 17 Oct 2013 03:55:17 -0700 (PDT) Received: from [IPv6:2001:240:11e:c01:970:33f6:da3:a215] ([IPv6:2001:240:11e:c01:970:33f6:da3:a215]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.21) with ESMTP id r9HAtGIv012405 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 17 Oct 2013 19:55:16 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Keiichi SHIMA In-Reply-To: <525D544E.1030507@cisco.com> Date: Thu, 17 Oct 2013 19:55:16 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4289DA69-E42A-495E-B7B7-E72EA53AD81F@wide.ad.jp> References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <525D544E.1030507@cisco.com> To: Joe Marcus Clarke X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 10:55:22 -0000 Hi, On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: > NIT: VirtualMachineAdminState: >=20 > The destroy(5) state really doesn't match in terms of tense. What = about destroyed(5)? That said, since this is something one can set, = perhaps present tense like run, pause, suspend, etc. make sense. The original intention of the naming of VirtualMachineAdminState was, = 'to transit the operation state of a virtual machine to X by setting its = admin state as X'. For example, when we set 'suspended' to the admin = state of a virtual machine, then the virtual machine will start = transition to the suspended operation state. We intentionally used the = same state names here. That is because the tense is past. For the 'destroy' admin state, since we didn't have any operation state = of a destroyed virtual machine (that is same as the shutdown operation = state), we didn't pay any attention to the naming. I can live with = either destroy(5) or destroyed(5). It is a matter of taste to me. > NIT (maybe a minor issue): VirtualMachineAutoStart: >=20 > Again, tense. Here, I think past tense works best since we decided = this would reflect a read-only state. I think enabled and disabled work = best. Do you mean changing the name to something like = 'VirtualMachineAutoStartEnabled'? Here again, I don't have any strong = opinion on this. I am open to change the name, if most people agree on = this. Regards, --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: > On 10/13/13 11:05 PM, Hirochika Asai wrote: >> Hi folks, >>=20 >> Thanks to comments from the mailing list, we've uploaded new version >> of our I-D: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>=20 >> We would like to submit our I-D as a working group draft soon and >> have a discussion in the next IETF as a working group draft. >> Chairs, could you please poll for adoption as a working group item >> on the mailing list? >>=20 >> I've already noticed an error: RFC4133 must be RFC6933. Please let >> us know if you find any other errors. These errors will be >> corrected in the next version (the first version for working group >> draft if adopted). >=20 > Overall, I like the changes. Thanks! >=20 > NIT: VirtualMachineAdminState: >=20 > The destroy(5) state really doesn't match in terms of tense. What = about destroyed(5)? That said, since this is something one can set, = perhaps present tense like run, pause, suspend, etc. make sense. >=20 > Thanks for fleshing out the state definitions :-). >=20 > NIT (maybe a minor issue): VirtualMachineAutoStart: >=20 > Again, tense. Here, I think past tense works best since we decided = this would reflect a read-only state. I think enabled and disabled work = best. >=20 > In terms of the new notifications, why enumerate all states as = notifications? My original comment suggested a single state change = notification where the new and previous state would be available as = objects (note: this would require the definition of a previous state = object). It just seems like the way you've implemented it would be = harder to scale if new states need to be added in the future. >=20 > Joe >=20 >>=20 >>=20 >> Here, I summarize the updates from the previous version. >>=20 >> * According to the thread Joe-1 >> Modified a paragraph as follows: >>=20 >> The design of this MIB module has been derived from enterprise >> specific MIB modules, namely a MIB module for managing guests of the >> Xen hypervisor, a MIB module for managing virtual machines controlled >> by the VMware hypervisor, and a MIB module using the libvirt >> programming interface to access different hypervisors. >> + However, this MIB module attempts to generalize >> + the managed objects to support other hypervisors. >>=20 >> * According to the thread Joe-2 >> Added description of an example of hypervisor-specific case >> using ENTITY-MIB, but not modified the MIB definition. >>=20 >> * According to the thread Joe-3 >> vmAutoStart --> read-only >> vmCur* --> read-write >> vm*Mem vm*Cpu --> description w/ MUST NOT: "Changes to these objects = MUST NOT persist" >>=20 >> * According to the thread Joe-5 >> For the network portion of the hypervisor, added a note on a case >> equipping virtual switches on the hypervisor as follows: >> The objects related to virtual switches >> are not also included in this MIB module >> though virtual switches shall be placed on a hypervisor. >> This is because the virtual network interfaces are >> the lowest abstraction of network resources allocated >> to a virtual machine. >> Instead of including the objects related to virtual switches, >> for example, BRIDGE-MIB >> and Q-BRIDGE-MIB could be used. >>=20 >> * According to the thread Joe-7 >> Added Notifications for shuttingDown, resuming suspending, migrating, = and blocked >> # I think we still need discussion at this point. >>=20 >> * Others >> Modified VirtualMachineOperState to be more clear. >> Revised the description of VirtualMachine*Index. >> Fixed some typos. >>=20 >>=20 >> Best regards, >> Hirochika >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-asai-vmm-mib-05.txt >>> Date: October 13, 2013 3:19:14 PM GMT+09:00 >>> To: Yuji Sekiya , Cathy Zhou = , Tina Tsou , = Keiichi Shima , Juergen Schoenwaelder = , Michael MacFaden = , Hirochika Asai , Hiroshi Esaki = >>>=20 >>>=20 >>> A new version of I-D, draft-asai-vmm-mib-05.txt >>> has been successfully submitted by Hirochika Asai and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-asai-vmm-mib >>> Revision: 05 >>> Title: Management Information Base for Virtual = Machines Controlled by a Hypervisor >>> Creation date: 2013-10-13 >>> Group: Individual Submission >>> Number of pages: 56 >>> URL: = http://www.ietf.org/internet-drafts/draft-asai-vmm-mib-05.txt >>> Status: http://datatracker.ietf.org/doc/draft-asai-vmm-mib >>> Htmlized: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-asai-vmm-mib-05 >>>=20 >>> 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). >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>=20 >=20 >=20 > --=20 > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > = --------------------------------------------------------------------------= -- > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From mrm@vmware.com Thu Oct 17 05:49:00 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A5221F994C for ; Thu, 17 Oct 2013 05:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDg5sGpyCOql for ; Thu, 17 Oct 2013 05:48:56 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 44DD411E8133 for ; Thu, 17 Oct 2013 05:48:56 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id BC23C2971C; Thu, 17 Oct 2013 05:48:53 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id B843DB02E3; Thu, 17 Oct 2013 05:48:53 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id A3C6EE004D; Thu, 17 Oct 2013 05:48:53 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Thu, 17 Oct 2013 05:48:53 -0700 (PDT) To: jclarke@cisco.com,j.schoenwaelder@jacobs-university.de,shima@wide.ad.jp Date: Thu, 17 Oct 2013 05:48:53 -0700 (PDT) X-Mailer: TouchDown X-Mailer: Zimbra 8.0.3_GA_5664 (MobileSync - TouchDown(MSRPC)/8.1.00052/) MIME-Version: 1.0 Message-ID: <758105933.4598171.1382014133461.JavaMail.root@zcs-prod-mbox-9.vmware.com> Content-Type: multipart/mixed;boundary="__1382014130115TOUCHDOWN_BOUNDARY__" From: Michael MacFaden In-Reply-To: <23E87CB3-097A-45EB-8146-2B8E749E9394@wide.ad.jp> References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <525D544E.1030507@cisco.com> <20131017091708.GA31344@elstar.local> <23E87CB3-097A-45EB-8146-2B8E749E9394@wide.ad.jp> Thread-Topic: New Version Notification for draft-asai-vmm-mib-05.txt Thread-Index: n8B5GW58X09cngcU/UeqSXfiPTD0dA== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] =?utf-8?q?New_Version_Notification_for_draft-asai-vmm-mi?= =?utf-8?q?b-05=2Etxt?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 12:49:00 -0000 --__1382014130115TOUCHDOWN_BOUNDARY__ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes and I continue to hold that generic notifications are not useful in pra= ctice. It causes intrroperability problems. Mike Sent from my Android phone using TouchDown (www.nitrodesk.com) -----Original Message----- From: Keiichi SHIMA [shima@wide.ad.jp] Received: Thursday, 17 Oct 2013, 2:38am To: Joe Marcus Clarke [jclarke@cisco.com]; Juergen Schoenwaelder [j.schoenw= aelder@jacobs-university.de] CC: opsawg@ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.tx= t Hello Juergen and Joe, >> If there is no strong opinion for not to unify the notification messages= , then we will do the change and resubmit an updated version before the cut= -off date (next Monday). >>=20 >=20 > I had this design (generic state change notifications) in my original > MIB module but then I got convinced by Michael that many real-world > applications prefer to have the notification type be specific so that > they can react to the different state changes by simply looking at the > notification type (without having to look into the notification > payload). This is why we got to the current design. >=20 > We should be careful here and take care to produce something that > existing notification receivers find 'easy' to process. The number of > states we have should be small and ideally not change over time, so > the implementation costs on the agent side likely are not big. I think this is a good point. Joe, do you have any strong objection for the above approach? If you can l= ive with either ways, then we will keep the current style. --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/10/17, at 18:17, Juergen Schoenwaelder wrote: > On Thu, Oct 17, 2013 at 05:55:13PM +0900, Keiichi SHIMA wrote: >> Hello, >>=20 >> On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: >>=20 >>> In terms of the new notifications, why enumerate all states as notifica= tions? My original comment suggested a single state change notification wh= ere the new and previous state would be available as objects (note: this wo= uld require the definition of a previous state object). It just seems like= the way you've implemented it would be harder to scale if new states need = to be added in the future. >>=20 >> Ah, I misunderstood your comment. I did the change actually. >>=20 >> Consolidating all the notification messages (maybe we will have two even= tually, one is for a per VM notification, and the other is for a bulk notif= ication) may be reasonable. >>=20 >> # we can even unify a per vm notification and a bulk notification, but m= aybe it is not a good idea? >>=20 >> If there is no strong opinion for not to unify the notification messages= , then we will do the change and resubmit an updated version before the cut= -off date (next Monday). >>=20 >=20 > I had this design (generic state change notifications) in my original > MIB module but then I got convinced by Michael that many real-world > applications prefer to have the notification type be specific so that > they can react to the different state changes by simply looking at the > notification type (without having to look into the notification > payload). This is why we got to the current design. >=20 > We should be careful here and take care to produce something that > existing notification receivers find 'easy' to process. The number of > states we have should be small and ideally not change over time, so > the implementation costs on the agent side likely are not big. >=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 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --__1382014130115TOUCHDOWN_BOUNDARY__-- From jclarke@cisco.com Thu Oct 17 11:59:52 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EED811E826B for ; Thu, 17 Oct 2013 11:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKXZmBylpVC1 for ; Thu, 17 Oct 2013 11:59:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A424D11E82CA for ; Thu, 17 Oct 2013 11:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2427; q=dns/txt; s=iport; t=1382036363; x=1383245963; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=f11Pw079cEYX7WiBC+CMmwOzVulDuoKnYEPlwoI1KsU=; b=a4lMUoch4M36QbkPWEW3/Yd8VAqYGCxzgHhFrDPKzTjYh8rSYk+wa1UV DXFlKdqF67OfC4NnLcWSVQ79lZoJWnAycYBXgVgcQ+h3aWWdwzZATxMTV awTYWpMTsJzCrAtE9HCFdT9mPB21GO+Oed/+HBfd20rEP/D8wVoKXjsT2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAFwyYFKtJV2b/2dsb2JhbABXA4MHvxOBKRZ0giUBAQEEOD8BDwILGAkWDwkDAgECAQk8BgEMBgIBAYgCwHoEjgSBORcRhBUDmAaSBINAIIE0 X-IronPort-AV: E=Sophos;i="4.93,516,1378857600"; d="scan'208";a="273455942" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 17 Oct 2013 18:59:09 +0000 Received: from rtp-jclarke-8919.cisco.com (rtp-jclarke-8919.cisco.com [10.117.46.170]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9HIx95n015118; Thu, 17 Oct 2013 18:59:09 GMT Message-ID: <5260337E.1040806@cisco.com> Date: Thu, 17 Oct 2013 14:59:10 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Keiichi SHIMA , opsawg@ietf.org References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <525D544E.1030507@cisco.com> <20131017091708.GA31344@elstar.local> In-Reply-To: <20131017091708.GA31344@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 18:59:52 -0000 On 10/17/13 5:17 AM, Juergen Schoenwaelder wrote: > On Thu, Oct 17, 2013 at 05:55:13PM +0900, Keiichi SHIMA wrote: >> Hello, >> >> On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: >> >>> In terms of the new notifications, why enumerate all states as notifications? My original comment suggested a single state change notification where the new and previous state would be available as objects (note: this would require the definition of a previous state object). It just seems like the way you've implemented it would be harder to scale if new states need to be added in the future. >> >> Ah, I misunderstood your comment. I did the change actually. >> >> Consolidating all the notification messages (maybe we will have two eventually, one is for a per VM notification, and the other is for a bulk notification) may be reasonable. >> >> # we can even unify a per vm notification and a bulk notification, but maybe it is not a good idea? >> >> If there is no strong opinion for not to unify the notification messages, then we will do the change and resubmit an updated version before the cut-off date (next Monday). >> > > I had this design (generic state change notifications) in my original > MIB module but then I got convinced by Michael that many real-world > applications prefer to have the notification type be specific so that > they can react to the different state changes by simply looking at the > notification type (without having to look into the notification > payload). This is why we got to the current design. > > We should be careful here and take care to produce something that > existing notification receivers find 'easy' to process. The number of > states we have should be small and ideally not change over time, so > the implementation costs on the agent side likely are not big. Okay. Good to know the back story. I know we have precedence for the consolidated approach as well. If we feel that the states won't change, then listing them out shouldn't be a scalability issue. Joe > > /js > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From jclarke@cisco.com Thu Oct 17 12:04:13 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EB611E82A2 for ; Thu, 17 Oct 2013 12:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTIwoaXpshVp for ; Thu, 17 Oct 2013 12:04:08 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8411E812A for ; Thu, 17 Oct 2013 12:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8391; q=dns/txt; s=iport; t=1382036642; x=1383246242; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=X4brzqEQGoIYQp0aGdKyo1pvZC4GCTOGuAv9aqEduS4=; b=dQg7Ya46cwbD3TtOTsZBB2k1LUmXeiJLuSSNQXx+wWuVRMXkZgvi8Xsu Pjivpb1SfIUQXBVkuG2jAPtHbpu0/pEyLyLJ1Ugiw132ySt1hoX0gpnC4 yU1twUjvPcbQ1G5B8mfIMEffZPEo2TVqFkvGDSHzvx901LzFg8kRLZH+i o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAIUzYFKtJV2d/2dsb2JhbABTBAODBzhMgy+6FUuBKRZ0giUBAQEDAQEBASAECwEFNgkBAQ4CCQIQAQMBAgECAgUWCwICCQMCAQIBCQwoCAYNAQUCAQEFC4dsBgcFkk2bXJJEBIEljF8XgSIQBwYLglmBPAOYBoEvkFWDQCCBKwkXAw X-IronPort-AV: E=Sophos;i="4.93,516,1378857600"; d="scan'208";a="273249347" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 17 Oct 2013 19:04:01 +0000 Received: from rtp-jclarke-8919.cisco.com (rtp-jclarke-8919.cisco.com [10.117.46.170]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9HJ40bv023275; Thu, 17 Oct 2013 19:04:01 GMT Message-ID: <526034A2.7090801@cisco.com> Date: Thu, 17 Oct 2013 15:04:02 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Keiichi SHIMA References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <525D544E.1030507@cisco.com> <4289DA69-E42A-495E-B7B7-E72EA53AD81F@wide.ad.jp> In-Reply-To: <4289DA69-E42A-495E-B7B7-E72EA53AD81F@wide.ad.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 19:04:13 -0000 On 10/17/13 6:55 AM, Keiichi SHIMA wrote: > Hi, > > On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: > >> NIT: VirtualMachineAdminState: >> > >> The destroy(5) state really doesn't match in terms of tense. What about destroyed(5)? That said, since this is something one can set, perhaps present tense like run, pause, suspend, etc. make sense. > > The original intention of the naming of VirtualMachineAdminState was, 'to transit the operation state of a virtual machine to X by setting its admin state as X'. For example, when we set 'suspended' to the admin state of a virtual machine, then the virtual machine will start transition to the suspended operation state. We intentionally used the same state names here. That is because the tense is past. > > For the 'destroy' admin state, since we didn't have any operation state of a destroyed virtual machine (that is same as the shutdown operation state), we didn't pay any attention to the naming. I can live with either destroy(5) or destroyed(5). It is a matter of taste to me. I think destroy(5) sounds better, but I'll admit it is a nit. > > >> NIT (maybe a minor issue): VirtualMachineAutoStart: >> >> Again, tense. Here, I think past tense works best since we decided this would reflect a read-only state. I think enabled and disabled work best. > > Do you mean changing the name to something like 'VirtualMachineAutoStartEnabled'? Here again, I don't have any strong opinion on this. I am open to change the name, if most people agree on this. No, TC stays the same, but the tense of the states should change to: unknown(1) enabled(2) disabled(3) Since the associated object is now read-only. Joe > > Regards, > --- > Keiichi SHIMA (島 慶一) > WIDE project > Research Laboratory, IIJ Innovation Institute, Inc > > > > On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: > >> On 10/13/13 11:05 PM, Hirochika Asai wrote: >>> Hi folks, >>> >>> Thanks to comments from the mailing list, we've uploaded new version >>> of our I-D: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>> >>> We would like to submit our I-D as a working group draft soon and >>> have a discussion in the next IETF as a working group draft. >>> Chairs, could you please poll for adoption as a working group item >>> on the mailing list? >>> >>> I've already noticed an error: RFC4133 must be RFC6933. Please let >>> us know if you find any other errors. These errors will be >>> corrected in the next version (the first version for working group >>> draft if adopted). >> >> Overall, I like the changes. Thanks! >> >> NIT: VirtualMachineAdminState: >> >> The destroy(5) state really doesn't match in terms of tense. What about destroyed(5)? That said, since this is something one can set, perhaps present tense like run, pause, suspend, etc. make sense. >> >> Thanks for fleshing out the state definitions :-). >> >> NIT (maybe a minor issue): VirtualMachineAutoStart: >> >> Again, tense. Here, I think past tense works best since we decided this would reflect a read-only state. I think enabled and disabled work best. >> >> In terms of the new notifications, why enumerate all states as notifications? My original comment suggested a single state change notification where the new and previous state would be available as objects (note: this would require the definition of a previous state object). It just seems like the way you've implemented it would be harder to scale if new states need to be added in the future. >> >> Joe >> >>> >>> >>> Here, I summarize the updates from the previous version. >>> >>> * According to the thread Joe-1 >>> Modified a paragraph as follows: >>> >>> The design of this MIB module has been derived from enterprise >>> specific MIB modules, namely a MIB module for managing guests of the >>> Xen hypervisor, a MIB module for managing virtual machines controlled >>> by the VMware hypervisor, and a MIB module using the libvirt >>> programming interface to access different hypervisors. >>> + However, this MIB module attempts to generalize >>> + the managed objects to support other hypervisors. >>> >>> * According to the thread Joe-2 >>> Added description of an example of hypervisor-specific case >>> using ENTITY-MIB, but not modified the MIB definition. >>> >>> * According to the thread Joe-3 >>> vmAutoStart --> read-only >>> vmCur* --> read-write >>> vm*Mem vm*Cpu --> description w/ MUST NOT: "Changes to these objects MUST NOT persist" >>> >>> * According to the thread Joe-5 >>> For the network portion of the hypervisor, added a note on a case >>> equipping virtual switches on the hypervisor as follows: >>> The objects related to virtual switches >>> are not also included in this MIB module >>> though virtual switches shall be placed on a hypervisor. >>> This is because the virtual network interfaces are >>> the lowest abstraction of network resources allocated >>> to a virtual machine. >>> Instead of including the objects related to virtual switches, >>> for example, BRIDGE-MIB >>> and Q-BRIDGE-MIB could be used. >>> >>> * According to the thread Joe-7 >>> Added Notifications for shuttingDown, resuming suspending, migrating, and blocked >>> # I think we still need discussion at this point. >>> >>> * Others >>> Modified VirtualMachineOperState to be more clear. >>> Revised the description of VirtualMachine*Index. >>> Fixed some typos. >>> >>> >>> Best regards, >>> Hirochika >>> >>> >>> Begin forwarded message: >>> >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for draft-asai-vmm-mib-05.txt >>>> Date: October 13, 2013 3:19:14 PM GMT+09:00 >>>> To: Yuji Sekiya , Cathy Zhou , Tina Tsou , Keiichi Shima , Juergen Schoenwaelder , Michael MacFaden , Hirochika Asai , Hiroshi Esaki >>>> >>>> >>>> A new version of I-D, draft-asai-vmm-mib-05.txt >>>> has been successfully submitted by Hirochika Asai and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-asai-vmm-mib >>>> Revision: 05 >>>> Title: Management Information Base for Virtual Machines Controlled by a Hypervisor >>>> Creation date: 2013-10-13 >>>> Group: Individual Submission >>>> Number of pages: 56 >>>> URL: http://www.ietf.org/internet-drafts/draft-asai-vmm-mib-05.txt >>>> Status: http://datatracker.ietf.org/doc/draft-asai-vmm-mib >>>> Htmlized: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-asai-vmm-mib-05 >>>> >>>> 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). >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>> >> >> >> -- >> Joe Marcus Clarke, CCIE #5384, | | >> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >> Email: jclarke@cisco.com >> >> ---------------------------------------------------------------------------- >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From melinda.shore@gmail.com Thu Oct 17 14:10:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DF411E8151 for ; Thu, 17 Oct 2013 14:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmrHY4i+5IvQ for ; Thu, 17 Oct 2013 14:10:58 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id D8A9521F9399 for ; Thu, 17 Oct 2013 14:10:55 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id bj1so3372246pad.7 for ; Thu, 17 Oct 2013 14:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jZxUns+Ugqe/pNOu/gY1xycLeEd+QGWCFRO23pdjS0o=; b=tBYZE8+alkAz4wyIx3aliYeoU353prJog151fJv+Kr6XM4nZuhrwkHz+Ozyb+aMLa7 JdEmFudvfsO7xSODAl0wKWpC+7ze8mjcWs6jozPna3J8HMqoU3Am0Iaud0AwLlb147E/ 4oyJar/JvQ3ILiOk5U/IbFGVhI9CSUtdv/Xm/ZkzY8nkBNObQpLPPCdzbhjJ4Aa1OTfz IwBEwS8Mlg0m0m0KTC73xYVrOZmI6oUkaQXuRLt5t1XTvIf7zuvcSLXqgVSZHhuIA5QM rgLJpciYyDT74E0W3gTItMsXvTyLc78CBSh/a+LD6IMYMvIlymTFd0MeTsi/aTMm+TIS 2OKg== X-Received: by 10.66.180.200 with SMTP id dq8mr19788pac.104.1382044255523; Thu, 17 Oct 2013 14:10:55 -0700 (PDT) Received: from spandex.local (63-140-89-93.dynamic.dsl.acsalaska.net. [63.140.89.93]) by mx.google.com with ESMTPSA id qw8sm99889603pbb.27.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 14:10:54 -0700 (PDT) Message-ID: <5260525C.9050108@gmail.com> Date: Thu, 17 Oct 2013 13:10:52 -0800 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: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> In-Reply-To: <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 21:10:59 -0000 On 10/13/13 7:05 PM, Hirochika Asai wrote: > We would like to submit our I-D as a working group draft soon and > have a discussion in the next IETF as a working group draft. > Chairs, could you please poll for adoption as a working group item > on the mailing list? Just a note that we haven't forgotten about you! I think we're generally not very comfortable that we've got an appropriate level of VM/hypervisor expertise in the IETF to provide thorough, expert review of the document, although clearly we've got very deep SNMP/MIB expertise. So, we've contacted some people who are not regular IETF participants for feedback, and we're waiting to hear from them. You may recall from recent meetings that we're making an effort to improve document quality, and here's what Benoit outlined during our session at IETF 86: 1. reach out to other people for review, 2. potentially put the bar higher for WG adoption (like in BMWG) 3. solicit reviews from chairs and AD 4. if no feedback, kill it. Demonstrate support. 5. bring the expert to the WG, e.g., as guest speaker. Melinda From haibin.song@huawei.com Thu Oct 17 20:47:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329B511E8126 for ; Thu, 17 Oct 2013 20:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W82S4c0Kvji7 for ; Thu, 17 Oct 2013 20:47:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD8921F9A45 for ; Thu, 17 Oct 2013 20:47:15 -0700 (PDT) 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 AWX30081; Fri, 18 Oct 2013 03:47:14 +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.146.0; Fri, 18 Oct 2013 04:46:26 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 04:47:13 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0146.000; Fri, 18 Oct 2013 11:47:07 +0800 From: "Songhaibin (A)" To: "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-song-opsawg-virtual-network-function-config-01.txt Thread-Index: AQHOy7NMwQHs+5vPWUeZvL3ngpS6Npn50bTg Date: Fri, 18 Oct 2013 03:47:06 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Cao Zhen \(CZ\)" Subject: [OPSAWG] FW: New Version Notification for draft-song-opsawg-virtual-network-function-config-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 03:47:27 -0000 SGksDQoNClRoaXMgZHJhZnQgaGFzIGJlZW4gdXBkYXRlZCB0byBhZGRyZXNzIHRoZSBjb21tZW50 cyBmcm9tIENhbyBaaGVuLiBJZiBhbnlvbmUgaGFzIGFueSBmdXJ0aGVyIGNvbW1lbnRzLCBwbGVh c2UgbGV0IG1lIGtub3cuIA0KDQpUaGFuayB5b3UsDQoNCi1IYWliaW4NCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxOCwgMjAx MyAxMTozNyBBTQ0KVG86IFNvbmdoYWliaW4gKEEpOyBDYW8gWmhlbjsgWmhlbiBDYW8NClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc29uZy1vcHNhd2ctdmlydHVh bC1uZXR3b3JrLWZ1bmN0aW9uLWNvbmZpZy0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtc29uZy1vcHNhd2ctdmlydHVhbC1uZXR3b3JrLWZ1bmN0aW9uLWNvbmZpZy0wMS50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSGFpYmluIFNvbmcgYW5kIHBv c3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1zb25nLW9w c2F3Zy12aXJ0dWFsLW5ldHdvcmstZnVuY3Rpb24tY29uZmlnDQpSZXZpc2lvbjoJIDAxDQpUaXRs ZToJCSBUaGUgUHJvYmxlbXMgb2YgVmlydHVhbCBOZXR3b3JrIEZ1bmN0aW9uIENvbmZpZ3VyYXRp b24NCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTE4DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCk51bWJlciBvZiBwYWdlczogOQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zb25nLW9wc2F3Zy12aXJ0dWFsLW5ldHdvcmst ZnVuY3Rpb24tY29uZmlnLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNvbmctb3BzYXdnLXZpcnR1YWwtbmV0d29yay1mdW5jdGlv bi1jb25maWcNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc29uZy1vcHNhd2ctdmlydHVhbC1uZXR3b3JrLWZ1bmN0aW9uLWNvbmZpZy0wMQ0KRGlmZjog ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zb25nLW9w c2F3Zy12aXJ0dWFsLW5ldHdvcmstZnVuY3Rpb24tY29uZmlnLTAxDQoNCkFic3RyYWN0Og0KICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHByb2JsZW0gc3BhY2Ugb2YgcmVtb3RlIHNlcnZp Y2UNCiAgIGluc3RhbGxhdGlvbiBhbmQgY29uZmlndXJhdGlvbiBpbiB0aGUgcHJvdmlkZXIncyBu ZXR3b3JrIHRocm91Z2ggYQ0KICAgY2VudHJhbGl6ZWQgbWFuYWdlbWVudCBzeXN0ZW0uICBUaGlz IGlzIGEgdHlwaWNhbCBzY2VuYXJpbyBmb3INCiAgIHZpcnR1YWwgZnVuY3Rpb24gaW5zdGFsbGF0 aW9uIGFuZCBkeW5hbWljIGNvbmZpZ3VyYXRpb24gaW4gbmV0d29yaw0KICAgZnVuY3Rpb24gdmly dHVhbGl6YXRpb24gKE5GVikgY29udGV4dC4gIEl0IGlzIGFsc28gYSB0eXBpY2FsIHNjZW5hcmlv DQogICBpbiBjbG91ZCBjb21wdXRpbmcgZW52aXJvbm1lbnQgd2hlcmUgZW5kIHVzZXJzIGRvIG5v dCBoYXZlIHRvIGluc3RhbGwNCiAgIGFwcGxpY2F0aW9ucyBpbiB0aGVpciBlbmQgaG9zdHMsIGJ1 dCBjYW4gaW5zdGFsbCB0aGVpciBvd24gZmVhdHVyZWQNCiAgIHBvd2VyZnVsIHNvZnR3YXJlIGFw cGxpY2F0aW9uIGluIHRoZSBjbG91ZC4gIFRoaXMgc3BlY2lmaWNhdGlvbiBhbHNvDQogICBpZGVu dGlmaWVzIHRoZSBzY29wZSB0aGF0IG5lZWRzIHN0YW5kYXJkaXphdGlvbiBiYXNlZCBvbiB0aGUN CiAgIHByb2JsZW1zLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From victor@jvknet.com Thu Oct 17 21:21:30 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC2911E8168 for ; Thu, 17 Oct 2013 21:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARCwNOX+Om+W for ; Thu, 17 Oct 2013 21:21:25 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9F95A11E8153 for ; Thu, 17 Oct 2013 21:21:22 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id e14so5608543iej.11 for ; Thu, 17 Oct 2013 21:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=wdIXP9tPAaQDjts5JWdPSBJkkLIVE0qf2OP9GcVvUOY=; b=ApM7Qt5sk8zElpPmsdx4ppAsv4xZhoUjMCSDJgNHBVrsofvryq8SUApEc48UDlwkTD Rpk0AkmgemPavcph4Kiq3a8Yunm4yKjAV79DTBUek+7t+uN3im9nGW6swX0Su57Cn3wO E+7vQMM7ZDVqFpezj5QMlz5FOU/r9/xpUZsVLy1ZaMh6/C9FxPbqo761xz9ukxPqDdCz T99yrwDRfYXGUSkFy74GbSw7YfcigV+elVaI+1a2Ehy1AxtlMf87w+L801fNX98vMcJm c8gv5G3ZX5iKsaRxJpKs8oaa/n7DPIavjugkFwpejb/SevHO2uc0ySdVfBFZF5FoGWhe ITNQ== X-Gm-Message-State: ALoCoQlpQUtATs+XVpsZLs8DXk9gjMY8pOdjhP7xDP/XrGdbZ0hr3OWsYq1cVk3G9FnQ+6NoLZoW X-Received: by 10.50.62.211 with SMTP id a19mr1217665igs.18.1382070081670; Thu, 17 Oct 2013 21:21:21 -0700 (PDT) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPSA id hv5sm11412532igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 17 Oct 2013 21:21:20 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 18 Oct 2013 00:21:15 -0400 From: Victor Kuarsingh To: Benoit Claise , Message-ID: Thread-Topic: AD review: draft-ietf-opsawg-lsn-deployment-03 In-Reply-To: <5252A194.6030700@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3464900479_2575662" Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-lsn-deployment-03 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 04:21:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3464900479_2575662 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Benoit, Thanks for the thorough review. I will split my response into three sections to address the various ares you commented on. (1). As for section 3 (network deployment requirements list and subsequent explanation), I will add text which clarifies this list expanded and described in the following sub-sections [new text on updated I-D] (2). Editorial comments at the tail end of the email [will review and make the updates to text] (3). As for you comments on RFC6888, the ones specified in this document are incremental to those. The "requirements" as stated here are ones related a deployment architecture (based on experience gained in actually going through the process). There are different then those listed in RFC6888 which concentrate on the NAT function itself. Here (in document) we concentrate on architectural/deployment requirements for deploying a system using NAT44. So by extension, no direct reference was made to RFC4787, RFC5328 or RFC5508 since these are more appropriate for someone building a CGN function. The reason for the references in section 3.7 and 3.8 are related to the fact that there is overlap between the architectural requirements and the the functional (NAT44/CGN function) requirement of the CGN box/device itself. This was in regard to (1) NAT logging which is both a requirement as stated in RFC6888 for the implemented of CGN box/device, but also a architectural requirement for an operator needed to facilitate the needs of the business. In section 3.8 there is mention of support for bulk port allocation. This again is a architectural requirement (to deal with practical scaling issues in real CGN deployments and ability to successful log) and as stated in RFC6888 a CGN device level requirement. Since there was existing text in RFC6888 which deal with NAT logging and port allocation (I.e. REQ-14 in RFC6888), we thought references to that RFC were appropriate. So, I will make updates on point 1 and 2 above. As for point 3, if you are satisfied with this explanation, then I can let it be. If you think you want to see text that specifically describes what I have put in my point 3 above, then I can do that as well. Regards, Victor K From: Benoit Claise Date: Mon, 07 Oct 2013 13:57:08 +0200 To: Cc: "opsawg@ietf.org" Subject: AD review: draft-ietf-opsawg-lsn-deployment-03 Resent-To: , Victor Kuarsingh Dear authors, - Section 3. CGN Network Deployment Requirements If a service provider is considering a CGN deployment with a provider NAT44 function, there are a number of basic architectural requirements which are of importance. Preliminary architectural requirements may require all or some of the following from the incoming CGN system: Then there is a long list of points. I spent some time on each point, making sure I understood it. Then, reading further, I realized that each point is expanded in the sub section. This should be explained up front. - I see Section 3 CGN Network Deployment Requirements What is the link with the requirements in rfc6888? Yes, there are a few references, for example in section 3.7 and 3.8 for specific requirements, but what about the other requirements. So the requirements in this document are 1. on top of the RFC6888 2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment 3. a complete different set Btw, RFC6888 lists: > > 3 . Requirements for CGNs > What follows is a list of requirements for CGNs. They are in > addition to those found in other documents such as [RFC4787 > ], > [RFC5382 ], and [RFC5508 > ]. > Again, same question for these extra RFCs. Editorial: Abstract OLD: This document provides a practical integration model which allows the CGN platform to be integrated into the network meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. NEW: This document provides a practical integration model which allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. Section 1. Introduction OLD: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 addresses caches run out on the local local operator. NEW: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 addresses caches run out on the local operator. Section 2. Motivation OLD: The ability to replace IPv4-Only equipment may be out of the control of the operator, and even when it's in the administrative control; it poses both cost and technical challenges as operators build out massive programs for equipment retirement or upgrade. NEW: The ability to replace IPv4-only equipment may be out of the control of the operator, and even when it's in the administrative control, it poses both cost and technical challenges as operators build out massive programs for equipment retirement or upgrade. Section 2. Motivation OLD: This will include solving a number of challenges since subscribers who's connections require translation will have network routing and flow needs which are different from legacy IPv4 connections. NEW: This will include solving a number of challenges since subscribers whose connections require translation will have network routing and flow needs which are different from legacy IPv4 connections. Section 3.3 CGN By-Pass OLD: CGN By-pass can be accomplished in many ways, but a simplistic, deterministic and scalable model is preferred. NEW: CGN by-pass can be accomplished in many ways, but a simplistic, deterministic and scalable model is preferred. Section 3.5. Flexible Deployment Options OLD: Depending on hardware capabilities, security practices and IPv4 address availability, the translation environments my need to be segmented and/or scaled over time to meet organic IPv4 demand growth. NEW: Depending on hardware capabilities, security practices and IPv4 address availability, the translation environments may need to be segmented and/or scaled over time to meet organic IPv4 demand growth. - Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment Options Something weird with the section format, at least in the html version - A couple of acronyms - Flexibility should include integration options for common access technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ ASN-GW), and direct Ethernet; - expand large-scale NAT (LSN) Regards, Benoit --B_3464900479_2575662 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Benoit,

=
Thanks for the thorough review. I will split my response into three sec= tions to address the various ares you commented on.

(1).  As for section 3 (network deployment requirements list and subse= quent explanation), I will add text which clarifies this list expanded and d= escribed in the following sub-sections [new text on updated I-D]
<= br>
(2). Editorial comments at the tail end of the email [will rev= iew and make the updates to text]

(3).  As for= you comments on RFC6888, the ones specified in this document are incrementa= l to those.   The "requirements" as stated here are ones related a depl= oyment architecture (based on experience gained in actually going through th= e process).  There are different then those listed in RFC6888 which con= centrate on the NAT function itself.  Here (in document) we concentrate= on architectural/deployment requirements for deploying a system using NAT44= .  So by extension, no direct reference was made to RFC4787, RFC5328 or= RFC5508 since these are more appropriate for someone building a CGN functio= n.

The reason for the references in section 3.7 and= 3.8 are related to the fact that there is overlap between the architectural= requirements and the the functional (NAT44/CGN function) requirement of the= CGN box/device itself.  This was in regard to (1) NAT logging which is= both a requirement as stated in RFC6888 for the implemented of CGN box/devi= ce, but also a architectural requirement for an operator needed to facilitat= e the needs of the business.  In section 3.8 there is mention of suppor= t for bulk port allocation.  This again is a architectural requirement = (to deal with practical scaling issues in real CGN deployments and ability t= o successful log) and as stated in RFC6888 a CGN device level requirement.

Since there was existing text in RFC6888 which deal = with NAT logging and port allocation (I.e. REQ-14 in RFC6888), we thought re= ferences to that RFC were appropriate.

So, I will m= ake updates on point 1 and 2 above.  As for point 3, if you are satisfi= ed with this explanation, then I can let it be.  If you think you want = to see text that specifically describes what I have put in my point 3 above,= then I can do that as well.

Regards,
Victor K

From: <= /span> Benoit Claise <bclaise@cisco.co= m>
Date: Mon, 07 Oct 2013 1= 3:57:08 +0200
To: <draft-ietf-opsawg-lsn-d= eployment@tools.ietf.org>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: AD review: draft-ietf-opsawg-lsn-deployment-03
Resent-To: <john.cianfarani@rci.rogers.com>, Victor Kuarsingh &= lt;victor@jvknet.com>

Dear authors,

- Section 3. CGN Network Deployment Requirements 
   If a service provider is considering a CGN de=
ployment with a provider
   NAT44 function, there are a number of basic architectural
   requirements which are of importance.  Preliminary architectural
   requirements may require all or some of the following from the
   incoming CGN system:

Then there is a long list of points.
I spent some time on each point, making sure I understood it.
Then, reading further, I realized that each point is expanded in the sub se=
ction. 
This should be explained up front.

- I see Section 3 CGN Network Deployment Requirements
What is the link with the requirements in rfc6888?
Yes, there are a few references, for example in section 3.7 and 3.8 for specific requirements, but what about the other requirements. So the requirements in this document are
    1. on top of the RFC6888
    2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment
    3. a complete different set

Btw, RFC6888 lists: 
3.  Requirements for CGNs
   What follows is a lis=
t of requirements for CGNs.  They are in
   addition to those found in other documents such as [RFC4787],
   [RFC5382], and [RFC5508].
Again, same question for these extra RFCs.


Editorial:

Abstract
OLD:
   This
   document provides a practical integration model which allows the CGN
   platform to be integrated into the network meeting the connectivity
   needs of the subscriber while being mindful of not disrupting
   existing services and meeting the technical challenges that CGN
   brings.

NEW:
   This
   document provides a practical integration model which allows the CGN
   platform to be integrated into the network, meeting the connectiv=
ity
   needs of the subscriber while being mindful of not disrupting
   existing services and meeting the technical challenges that CGN
   brings.

Section 1. Introduction
OLD:
To face this challenge, operators may need to deploy CGN (Carrie=
r
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local local
   operator. 

NEW:
To face this challenge, operators may need to deploy CGN (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local
   operator.

Section 2. Motivation

OLD:
   The ability to replace IPv4-Only equipment may be out of the =
control
   of the operator, and even when it's in the administrative control; it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade. 

NEW:
   The ability to replace IPv4-only equipment may be out of the cont=
rol
   of the operator, and even when it's in the administrative control, it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade.

Section 2. Motivation

OLD:
   This will include solving a number of chall=
enges
   since subscribers who's connections require translation will have
   network routing and flow needs which are different from legacy IPv4
   connections.

NEW:
   This will include solving a number of challenges
   since subscribers whose connections require translation will have=
   network routing and flow needs which are different from legacy IPv4
   connections.

Section 3.3 CGN By-Pass

OLD:
   CGN
   By-pass can be accomplished in many ways, but a simplistic,
   deterministic and scalable model is preferred.

NEW:
   CGN
   by-pass can be accomplished in many ways, but a simplistic,
   deterministic and scalable model is preferred.


Section 3.5.  Flexible Deployment Options

OLD:
   Depending on hardware capabilities, security practices and IPv4
   address availability, the translation environments my need to be
   segmented and/or scaled over time to meet organic IPv4 demand growth.

NEW:
   Depending on hardware capabilities, security practices and IPv4
   address availability, the translation environments may need to be
   segmented and/or scaled over time to meet organic IPv4 demand growth.
- Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment Options
Something weird with the section format, at least in the html version

- A couple of acronyms
      - Flexibility should include integration=
 options for common access
      technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/
      ASN-GW), and direct Ethernet;
	
    - expand large-scale NAT (LSN)

Regards, Benoit

--B_3464900479_2575662-- From shima@wide.ad.jp Thu Oct 17 23:33:55 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4B321F9F23 for ; Thu, 17 Oct 2013 23:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-qtfA72gE4m for ; Thu, 17 Oct 2013 23:33:54 -0700 (PDT) Received: from sh.wide.ad.jp (sh.wide.ad.jp [IPv6:2001:200:0:1001::6]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9BE21F9F2B for ; Thu, 17 Oct 2013 23:33:52 -0700 (PDT) Received: from [IPv6:2001:240:11e:c01:970:33f6:da3:a215] ([IPv6:2001:240:11e:c01:970:33f6:da3:a215]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.21) with ESMTP id r9I6XoY6016079 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 18 Oct 2013 15:33:51 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Keiichi SHIMA In-Reply-To: <526034A2.7090801@cisco.com> Date: Fri, 18 Oct 2013 15:33:50 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <3C61DF63-48C7-42E0-91B2-E6673CCCCD51@wide.ad.jp> References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <525D544E.1030507@cisco.com> <4289DA69-E42A-495E-B7B7-E72EA53AD81F@wide.ad.jp> <526034A2.7090801@cisco.com> To: Joe Marcus Clarke X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 06:33:55 -0000 Joe, > No, TC stays the same, but the tense of the states should change to: >=20 > unknown(1) > enabled(2) > disabled(3) >=20 > Since the associated object is now read-only. It makes sense. I'm OK to update the above values. Any objections from other authors? --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/10/18, at 4:04, Joe Marcus Clarke wrote: > On 10/17/13 6:55 AM, Keiichi SHIMA wrote: >> Hi, >>=20 >> On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: >>=20 >>> NIT: VirtualMachineAdminState: >>>=20 >>=20 >>> The destroy(5) state really doesn't match in terms of tense. What = about destroyed(5)? That said, since this is something one can set, = perhaps present tense like run, pause, suspend, etc. make sense. >>=20 >> The original intention of the naming of VirtualMachineAdminState was, = 'to transit the operation state of a virtual machine to X by setting its = admin state as X'. For example, when we set 'suspended' to the admin = state of a virtual machine, then the virtual machine will start = transition to the suspended operation state. We intentionally used the = same state names here. That is because the tense is past. >>=20 >> For the 'destroy' admin state, since we didn't have any operation = state of a destroyed virtual machine (that is same as the shutdown = operation state), we didn't pay any attention to the naming. I can live = with either destroy(5) or destroyed(5). It is a matter of taste to me. >=20 > I think destroy(5) sounds better, but I'll admit it is a nit. >=20 >>=20 >>=20 >>> NIT (maybe a minor issue): VirtualMachineAutoStart: >>>=20 >>> Again, tense. Here, I think past tense works best since we decided = this would reflect a read-only state. I think enabled and disabled work = best. >>=20 >> Do you mean changing the name to something like = 'VirtualMachineAutoStartEnabled'? Here again, I don't have any strong = opinion on this. I am open to change the name, if most people agree on = this. >=20 > No, TC stays the same, but the tense of the states should change to: >=20 > unknown(1) > enabled(2) > disabled(3) >=20 > Since the associated object is now read-only. >=20 > Joe >=20 >>=20 >> Regards, >> --- >> Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) >> WIDE project >> Research Laboratory, IIJ Innovation Institute, Inc = >>=20 >>=20 >>=20 >> On 2013/10/15, at 23:42, Joe Marcus Clarke wrote: >>=20 >>> On 10/13/13 11:05 PM, Hirochika Asai wrote: >>>> Hi folks, >>>>=20 >>>> Thanks to comments from the mailing list, we've uploaded new = version >>>> of our I-D: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>>>=20 >>>> We would like to submit our I-D as a working group draft soon and >>>> have a discussion in the next IETF as a working group draft. >>>> Chairs, could you please poll for adoption as a working group item >>>> on the mailing list? >>>>=20 >>>> I've already noticed an error: RFC4133 must be RFC6933. Please let >>>> us know if you find any other errors. These errors will be >>>> corrected in the next version (the first version for working group >>>> draft if adopted). >>>=20 >>> Overall, I like the changes. Thanks! >>>=20 >>> NIT: VirtualMachineAdminState: >>>=20 >>> The destroy(5) state really doesn't match in terms of tense. What = about destroyed(5)? That said, since this is something one can set, = perhaps present tense like run, pause, suspend, etc. make sense. >>>=20 >>> Thanks for fleshing out the state definitions :-). >>>=20 >>> NIT (maybe a minor issue): VirtualMachineAutoStart: >>>=20 >>> Again, tense. Here, I think past tense works best since we decided = this would reflect a read-only state. I think enabled and disabled work = best. >>>=20 >>> In terms of the new notifications, why enumerate all states as = notifications? My original comment suggested a single state change = notification where the new and previous state would be available as = objects (note: this would require the definition of a previous state = object). It just seems like the way you've implemented it would be = harder to scale if new states need to be added in the future. >>>=20 >>> Joe >>>=20 >>>>=20 >>>>=20 >>>> Here, I summarize the updates from the previous version. >>>>=20 >>>> * According to the thread Joe-1 >>>> Modified a paragraph as follows: >>>>=20 >>>> The design of this MIB module has been derived from enterprise >>>> specific MIB modules, namely a MIB module for managing guests of = the >>>> Xen hypervisor, a MIB module for managing virtual machines = controlled >>>> by the VMware hypervisor, and a MIB module using the libvirt >>>> programming interface to access different hypervisors. >>>> + However, this MIB module attempts to generalize >>>> + the managed objects to support other hypervisors. >>>>=20 >>>> * According to the thread Joe-2 >>>> Added description of an example of hypervisor-specific case >>>> using ENTITY-MIB, but not modified the MIB definition. >>>>=20 >>>> * According to the thread Joe-3 >>>> vmAutoStart --> read-only >>>> vmCur* --> read-write >>>> vm*Mem vm*Cpu --> description w/ MUST NOT: "Changes to these = objects MUST NOT persist" >>>>=20 >>>> * According to the thread Joe-5 >>>> For the network portion of the hypervisor, added a note on a case >>>> equipping virtual switches on the hypervisor as follows: >>>> The objects related to virtual switches >>>> are not also included in this MIB module >>>> though virtual switches shall be placed on a hypervisor. >>>> This is because the virtual network interfaces are >>>> the lowest abstraction of network resources allocated >>>> to a virtual machine. >>>> Instead of including the objects related to virtual switches, >>>> for example, BRIDGE-MIB >>>> and Q-BRIDGE-MIB could be used. >>>>=20 >>>> * According to the thread Joe-7 >>>> Added Notifications for shuttingDown, resuming suspending, = migrating, and blocked >>>> # I think we still need discussion at this point. >>>>=20 >>>> * Others >>>> Modified VirtualMachineOperState to be more clear. >>>> Revised the description of VirtualMachine*Index. >>>> Fixed some typos. >>>>=20 >>>>=20 >>>> Best regards, >>>> Hirochika >>>>=20 >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: New Version Notification for draft-asai-vmm-mib-05.txt >>>>> Date: October 13, 2013 3:19:14 PM GMT+09:00 >>>>> To: Yuji Sekiya , Cathy Zhou = , Tina Tsou , = Keiichi Shima , Juergen Schoenwaelder = , Michael MacFaden = , Hirochika Asai , Hiroshi Esaki = >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-asai-vmm-mib-05.txt >>>>> has been successfully submitted by Hirochika Asai and posted to = the >>>>> IETF repository. >>>>>=20 >>>>> Filename: draft-asai-vmm-mib >>>>> Revision: 05 >>>>> Title: Management Information Base for Virtual = Machines Controlled by a Hypervisor >>>>> Creation date: 2013-10-13 >>>>> Group: Individual Submission >>>>> Number of pages: 56 >>>>> URL: = http://www.ietf.org/internet-drafts/draft-asai-vmm-mib-05.txt >>>>> Status: = http://datatracker.ietf.org/doc/draft-asai-vmm-mib >>>>> Htmlized: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-asai-vmm-mib-05 >>>>>=20 >>>>> 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). >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>> -- >>> Joe Marcus Clarke, CCIE #5384, | | >>> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >>> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >>> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >>> Email: jclarke@cisco.com >>>=20 >>> = --------------------------------------------------------------------------= -- >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >=20 >=20 > --=20 > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > = --------------------------------------------------------------------------= -- From bclaise@cisco.com Fri Oct 18 03:28:12 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14B411E8171 for ; Fri, 18 Oct 2013 03:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8gJObPwCBZS for ; Fri, 18 Oct 2013 03:28:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A65A821F9983 for ; Fri, 18 Oct 2013 03:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24824; q=dns/txt; s=iport; t=1382092082; x=1383301682; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=A8AttbnQp/uATNriCRtni0M03qU+3f/P1trgA96/ufc=; b=Yy7Yk5Ok+QAbABnPUuABjtzeYjV9JPMR+thHGMDreHByV0aVLLupCcsS cG+jKyf4TXd+MPWcuArcE7o+rt1P3H9CbYm+e/qdBm66xYcaGWPyGIGUv tKBNsGvf20vgzJGPI+gubZgMp43sFNb50/0LxoDs3JIVJ3IcgFyxVHSH9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYGAJEMYVKQ/khL/2dsb2JhbABagkNEOIlYrEyIRYElFnSCJQEBAQRnBQ0QCxEBAgECCh4HDwI1AwYIBg0BBQIBAYgCDMBdjgiBOAwFB4QpA5gJgS+FDItMgyY6gTQ X-IronPort-AV: E=Sophos;i="4.93,521,1378857600"; d="scan'208,217";a="160786268" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2013 10:28:00 +0000 Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9IARujY022541; Fri, 18 Oct 2013 10:27:57 GMT Message-ID: <52610D2C.70405@cisco.com> Date: Fri, 18 Oct 2013 12:27:56 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Victor Kuarsingh References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050101040909050400000505" Cc: "opsawg@ietf.org" , draft-ietf-opsawg-lsn-deployment@tools.ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-lsn-deployment-03 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 10:28:13 -0000 This is a multi-part message in MIME format. --------------050101040909050400000505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Victor, See in-line. > Benoit, > > Thanks for the thorough review. I will split my response into three > sections to address the various ares you commented on. > > (1). As for section 3 (network deployment requirements list and > subsequent explanation), I will add text which clarifies this list > expanded and described in the following sub-sections [new text on > updated I-D] > > (2). Editorial comments at the tail end of the email [will review and > make the updates to text] > > (3). As for you comments on RFC6888, the ones specified in this > document are incremental to those. > The "requirements" as stated here are ones related a deployment > architecture (based on experience gained in actually going through the > process). There are different then those listed in RFC6888 which > concentrate on the NAT function itself. > Here (in document) we concentrate on architectural/deployment > requirements for deploying a system using NAT44. So by extension, no > direct reference was made to RFC4787, RFC5328 or RFC5508 since these > are more appropriate for someone building a CGN function. > > The reason for the references in section 3.7 and 3.8 are related to > the fact that there is overlap between the architectural requirements > and the the functional (NAT44/CGN function) requirement of the CGN > box/device itself. This was in regard to (1) NAT logging which is > both a requirement as stated in RFC6888 for the implemented of CGN > box/device, but also a architectural requirement for an operator > needed to facilitate the needs of the business. In section 3.8 there > is mention of support for bulk port allocation. This again is a > architectural requirement (to deal with practical scaling issues in > real CGN deployments and ability to successful log) and as stated in > RFC6888 a CGN device level requirement. > > Since there was existing text in RFC6888 which deal with NAT logging > and port allocation (I.e. REQ-14 in RFC6888), we thought references to > that RFC were appropriate. > > So, I will make updates on point 1 and 2 above. As for point 3, if > you are satisfied with this explanation, then I can let it be. If you > think you want to see text that specifically describes what I have put > in my point 3 above, then I can do that as well. From your draft, the paragraphs referring to RFC 6888 are: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888 ] to help extend the connectivity matrix once IPv4 addresses caches run out on the local local operator. ... Operators may need to keep track of this information (securely) to meet regulatory and/or legal obligations._Further information_ can be found in [RFC6888 ] with respect to CGN logging requirements (Logging Section). ... 3.8. _Additional _CGN Requirements The CGN platform will also need to meet the needs of additional requirements such as Bulk Port Allocation and other CGN device specific functions._These additional requirements_ are captured within [RFC6888 ]. The last paragraph ("additional" in the title and "these additional requirements") is my source of confusion I guess, and led to the question in my review So the requirements in this document are 1. on top of the RFC6888 2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment 3. a complete different set You must already be compliant with RFC 6888. As you wrote: "As for you comments on RFC6888, the ones specified in this document are _incremental _to those" And now you have some additional CGN requirements ... but those requirements are already captured into RFC 6888 ... to which you're already complaint. So what are those additional to? Regards, Benoit > > Regards, > > Victor K > > From: Benoit Claise > > Date: Mon, 07 Oct 2013 13:57:08 +0200 > To: > > Cc: "opsawg@ietf.org " > > Subject: AD review: draft-ietf-opsawg-lsn-deployment-03 > Resent-To: >, Victor Kuarsingh > > > > Dear authors, > > - Section 3. CGN Network Deployment Requirements > If a service provider is considering a CGN deployment with a provider > NAT44 function, there are a number of basic architectural > requirements which are of importance. Preliminary architectural > requirements may require all or some of the following from the > incoming CGN system: > > Then there is a long list of points. > I spent some time on each point, making sure I understood it. > Then, reading further, I realized that each point is expanded in the sub section. > This should be explained up front. > > - I see Section 3 CGN Network Deployment Requirements > What is the link with the requirements in rfc6888? > Yes, there are a few references, for example in section 3.7 and 3.8 > for specific requirements, but what about the other requirements. So > the requirements in this document are > 1. on top of the RFC6888 > 2. a subset of those that are important for > draft-ietf-opsawg-lsn-deployment > 3. a complete different set > > Btw, RFC6888 lists: > > > 3 . Requirements > for CGNs > > What follows is a list of requirements for CGNs. They are in > addition to those found in other documents such as [RFC4787 ], > [RFC5382 ], and [RFC5508 ]. > > Again, same question for these extra RFCs. > > _ > Editorial:_ > > Abstract > OLD: > This > document provides a practical integration model which allows the CGN > platform to be integrated into the network meeting the connectivity > needs of the subscriber while being mindful of not disrupting > existing services and meeting the technical challenges that CGN > brings. > > NEW: > This > document provides a practical integration model which allows the CGN > platform to be integrated into the_network,_ meeting the connectivity > needs of the subscriber while being mindful of not disrupting > existing services and meeting the technical challenges that CGN > brings. > > Section 1. Introduction > OLD: > To face this challenge, operators may need to deploy CGN (Carrier > Grade NAT) as described in [RFC6888] to help extend the connectivity > matrix once IPv4 addresses caches run out on the local local > operator. > > NEW: > To face this challenge, operators may need to deploy CGN (Carrier > Grade NAT) as described in [RFC6888] to help extend the connectivity > matrix once IPv4 addresses caches run out on the local > operator. > > Section 2. Motivation > > OLD: > The ability to replace IPv4-Only equipment may be out of the control > of the operator, and even when it's in the administrative control; it > poses both cost and technical challenges as operators build out > massive programs for equipment retirement or upgrade. > > NEW: > The ability to replace_IPv4-only_ equipment may be out of the control > of the operator, and even when it's in the administrative_control,_ it > poses both cost and technical challenges as operators build out > massive programs for equipment retirement or upgrade. > > Section 2. Motivation > > OLD: > This will include solving a number of challenges > since subscribers who's connections require translation will have > network routing and flow needs which are different from legacy IPv4 > connections. > > NEW: > This will include solving a number of challenges > since subscribers_whose_connections require translation will have network routing and flow needs which are different from legacy IPv4 > connections. > > Section 3.3 CGN By-Pass > > OLD: > CGN > By-pass can be accomplished in many ways, but a simplistic, > deterministic and scalable model is preferred. > > NEW: > CGN > by-pass can be accomplished in many ways, but a simplistic, > deterministic and scalable model is preferred. > > > Section 3.5. Flexible Deployment Options > > OLD: > Depending on hardware capabilities, security practices and IPv4 > address availability, the translation environments my need to be > segmented and/or scaled over time to meet organic IPv4 demand growth. > > NEW: > Depending on hardware capabilities, security practices and IPv4 > address availability, the translation environments may need to be > segmented and/or scaled over time to meet organic IPv4 demand growth. > > > - Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN > Attachment Options > Something weird with the section format, at least in the html version > > - A couple of acronyms > - Flexibility should include integration options for common access > technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ > ASN-GW), and direct Ethernet; > > - expand large-scale NAT (LSN) > > Regards, Benoit > --------------050101040909050400000505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Victor,

See in-line.
Benoit,

Thanks for the thorough review. I will split my response into three sections to address the various ares you commented on.

(1).  As for section 3 (network deployment requirements list and subsequent explanation), I will add text which clarifies this list expanded and described in the following sub-sections [new text on updated I-D]

(2). Editorial comments at the tail end of the email [will review and make the updates to text]

(3).  As for you comments on RFC6888, the ones specified in this document are incremental to those. 
The "requirements" as stated here are ones related a deployment architecture (based on experience gained in actually going through the process).  There are different then those listed in RFC6888 which concentrate on the NAT function itself. 
Here (in document) we concentrate on architectural/deployment requirements for deploying a system using NAT44.  So by extension, no direct reference was made to RFC4787, RFC5328 or RFC5508 since these are more appropriate for someone building a CGN function.

The reason for the references in section 3.7 and 3.8 are related to the fact that there is overlap between the architectural requirements and the the functional (NAT44/CGN function) requirement of the CGN box/device itself.  This was in regard to (1) NAT logging which is both a requirement as stated in RFC6888 for the implemented of CGN box/device, but also a architectural requirement for an operator needed to facilitate the needs of the business.  In section 3.8 there is mention of support for bulk port allocation.  This again is a architectural requirement (to deal with practical scaling issues in real CGN deployments and ability to successful log) and as stated in RFC6888 a CGN device level requirement.

Since there was existing text in RFC6888 which deal with NAT logging and port allocation (I.e. REQ-14 in RFC6888), we thought references to that RFC were appropriate.

So, I will make updates on point 1 and 2 above.  As for point 3, if you are satisfied with this explanation, then I can let it be.  If you think you want to see text that specifically describes what I have put in my point 3 above, then I can do that as well.

From your draft, the paragraphs referring to RFC 6888 are:
   To face this challenge, operators may need to deploy CGN (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local local
   operator.
     ...
   Operators may need to keep track of this information (securely) to
   meet regulatory and/or legal obligations.  Further information can be
   found in [RFC6888] with respect to CGN logging requirements (Logging
   Section).
     ...

   3.8.  Additional CGN Requirements
   The CGN platform will also need to meet the needs of additional
   requirements such as Bulk Port Allocation and other CGN device
   specific functions.  These additional requirements are captured
   within [RFC6888].

The last paragraph ("additional" in the title and "these additional requirements") is my source of confusion I guess, and led to the question in my review
So the requirements in this document are
    1. on top of the RFC6888
    2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment
    3. a complete different set
You must already be compliant with RFC 6888. As you wrote: "As for you comments on RFC6888, the ones specified in this document are incremental to those"
And now you have some additional CGN requirements ... but those requirements are already captured into RFC 6888 ... to which you're already complaint. So what are those additional to?

Regards, Benoit

Regards,

Victor K

From: Benoit Claise <bclaise@cisco.com>
Date: Mon, 07 Oct 2013 13:57:08 +0200
To: <draft-ietf-opsawg-lsn-deployment@tools.ietf.org>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: AD review: draft-ietf-opsawg-lsn-deployment-03
Resent-To: <john.cianfarani@rci.rogers.com>, Victor Kuarsingh <victor@jvknet.com>

Dear authors,

- Section 3. CGN Network Deployment Requirements 
   If a service provider is considering a CGN deployment with a provider
   NAT44 function, there are a number of basic architectural
   requirements which are of importance.  Preliminary architectural
   requirements may require all or some of the following from the
   incoming CGN system:

Then there is a long list of points.
I spent some time on each point, making sure I understood it.
Then, reading further, I realized that each point is expanded in the sub section. 
This should be explained up front.

- I see Section 3 CGN Network Deployment Requirements
What is the link with the requirements in rfc6888?
Yes, there are a few references, for example in section 3.7 and 3.8 for specific requirements, but what about the other requirements. So the requirements in this document are
    1. on top of the RFC6888
    2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment
    3. a complete different set

Btw, RFC6888 lists: 
3.  Requirements for CGNs
   What follows is a list of requirements for CGNs.  They are in
   addition to those found in other documents such as [RFC4787],
   [RFC5382], and [RFC5508].
Again, same question for these extra RFCs.


Editorial:

Abstract
OLD:
   This
   document provides a practical integration model which allows the CGN
   platform to be integrated into the network meeting the connectivity
   needs of the subscriber while being mindful of not disrupting
   existing services and meeting the technical challenges that CGN
   brings.

NEW:
   This
   document provides a practical integration model which allows the CGN
   platform to be integrated into the network, meeting the connectivity
   needs of the subscriber while being mindful of not disrupting
   existing services and meeting the technical challenges that CGN
   brings.

Section 1. Introduction
OLD:
To face this challenge, operators may need to deploy CGN (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local local
   operator. 

NEW:
To face this challenge, operators may need to deploy CGN (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local
   operator.

Section 2. Motivation

OLD:
   The ability to replace IPv4-Only equipment may be out of the control
   of the operator, and even when it's in the administrative control; it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade. 

NEW:
   The ability to replace IPv4-only equipment may be out of the control
   of the operator, and even when it's in the administrative control, it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade.

Section 2. Motivation

OLD:
   This will include solving a number of challenges
   since subscribers who's connections require translation will have
   network routing and flow needs which are different from legacy IPv4
   connections.

NEW:
   This will include solving a number of challenges
   since subscribers whose connections require translation will have   network routing and flow needs which are different from legacy IPv4
   connections.

Section 3.3 CGN By-Pass

OLD:
   CGN
   By-pass can be accomplished in many ways, but a simplistic,
   deterministic and scalable model is preferred.

NEW:
   CGN
   by-pass can be accomplished in many ways, but a simplistic,
   deterministic and scalable model is preferred.


Section 3.5.  Flexible Deployment Options

OLD:
   Depending on hardware capabilities, security practices and IPv4
   address availability, the translation environments my need to be
   segmented and/or scaled over time to meet organic IPv4 demand growth.

NEW:
   Depending on hardware capabilities, security practices and IPv4
   address availability, the translation environments may need to be
   segmented and/or scaled over time to meet organic IPv4 demand growth.
- Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment Options
Something weird with the section format, at least in the html version

- A couple of acronyms
      - Flexibility should include integration options for common access
      technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/
      ASN-GW), and direct Ethernet;
	
    - expand large-scale NAT (LSN)

Regards, Benoit

--------------050101040909050400000505-- From victor@jvknet.com Fri Oct 18 05:42:53 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470B511E822C for ; Fri, 18 Oct 2013 05:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOpGNmu8eynM for ; Fri, 18 Oct 2013 05:42:48 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC8111E81A7 for ; Fri, 18 Oct 2013 05:42:44 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id w8so610773qac.4 for ; Fri, 18 Oct 2013 05:42:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=RhAxtuXGrFgaq7JQzeTJGhEXF1rNtN8S9xrSG3VDKQk=; b=kkF4lYSD94spdXaxblTklAVM4LJqA0mXuGJ3T6+Ad8l2fCLbxM+ME4gnfy4iWTBT1I liAsa/EogH+G7PwA5BEhEDh5nRO5oYUxguQlHa2krwUKzVOWUlWDUEiQExN8Ol9uP34n 3wBieFk2aFted0mxv7VZVKOxMzdlw9COnb44o1z6W3ztapsN9+gVDq97Zm9NmdIyxPax fs4IbsfHPVcAEMgmx0D3smlfzNyhp95mApYCG89M0sDbQPzgkW/Zaob13srIye+JCiib J7UIRxWNxBuZIeq/X3Kf9th1dkiQ9il8L1uH9W/M0gwFmfMCx2D+vB/i57BkGpwzY4zu 63SQ== X-Gm-Message-State: ALoCoQlIx7uo9pPUvQaW7U+VhpR+nwNh8lCpqy39Oh9WMpPon5JiEjRBtS5vEHsq5RhDGCQ9c9Pi X-Received: by 10.224.161.146 with SMTP id r18mr4087594qax.57.1382100160518; Fri, 18 Oct 2013 05:42:40 -0700 (PDT) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPSA id k4sm4998435qaa.8.2013.10.18.05.42.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 18 Oct 2013 05:42:39 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 18 Oct 2013 08:42:34 -0400 From: Victor Kuarsingh To: Benoit Claise Message-ID: Thread-Topic: AD review: draft-ietf-opsawg-lsn-deployment-03 In-Reply-To: <52610D2C.70405@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3464930559_2594020" Cc: "opsawg@ietf.org" , draft-ietf-opsawg-lsn-deployment@tools.ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-lsn-deployment-03 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 12:42:53 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3464930559_2594020 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Benoit, Ok, I see your point of confusion. If 3.8 was called, "Base CGN Requirements", and the text was modified a bit to not that other architectural requirements are actually covered in RFC6888, would this help remove the confusion and bring some clarity? Regards, Victor K From: Benoit Claise Date: Fri, 18 Oct 2013 12:27:56 +0200 To: Victor Kuarsingh Cc: , "opsawg@ietf.org" Subject: Re: AD review: draft-ietf-opsawg-lsn-deployment-03 Hi Victor, See in-line. > > Benoit, > > > > > Thanks for the thorough review. I will split my response into three sections > to address the various ares you commented on. > > > > > (1). As for section 3 (network deployment requirements list and subsequent > explanation), I will add text which clarifies this list expanded and described > in the following sub-sections [new text on updated I-D] > > > > > (2). Editorial comments at the tail end of the email [will review and make the > updates to text] > > > > > (3). As for you comments on RFC6888, the ones specified in this document are > incremental to those. > > > > The "requirements" as stated here are ones related a deployment architecture > (based on experience gained in actually going through the process). There are > different then those listed in RFC6888 which concentrate on the NAT function > itself. > > > > Here (in document) we concentrate on architectural/deployment requirements for > deploying a system using NAT44. So by extension, no direct reference was made > to RFC4787, RFC5328 or RFC5508 since these are more appropriate for someone > building a CGN function. > > > > > The reason for the references in section 3.7 and 3.8 are related to the fact > that there is overlap between the architectural requirements and the the > functional (NAT44/CGN function) requirement of the CGN box/device itself. > This was in regard to (1) NAT logging which is both a requirement as stated in > RFC6888 for the implemented of CGN box/device, but also a architectural > requirement for an operator needed to facilitate the needs of the business. > In section 3.8 there is mention of support for bulk port allocation. This > again is a architectural requirement (to deal with practical scaling issues in > real CGN deployments and ability to successful log) and as stated in RFC6888 a > CGN device level requirement. > > > > > Since there was existing text in RFC6888 which deal with NAT logging and port > allocation (I.e. REQ-14 in RFC6888), we thought references to that RFC were > appropriate. > > > > > So, I will make updates on point 1 and 2 above. As for point 3, if you are > satisfied with this explanation, then I can let it be. If you think you want > to see text that specifically describes what I have put in my point 3 above, > then I can do that as well. > From your draft, the paragraphs referring to RFC 6888 are: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888 ] to help extend the connectivity matrix once IPv4 addresses caches run out on the local local operator. ... Operators may need to keep track of this information (securely) to meet regulatory and/or legal obligations. Further information can be found in [RFC6888 ] with respect to CGN logging requirements (Logging Section). ... 3.8. Additional CGN Requirements The CGN platform will also need to meet the needs of additional requirements such as Bulk Port Allocation and other CGN device specific functions. These additional requirements are captured within [RFC6888 ]. The last paragraph ("additional" in the title and "these additional requirements") is my source of confusion I guess, and led to the question in my review > So the requirements in this document are > 1. on top of the RFC6888 > 2. a subset of those that are important for > draft-ietf-opsawg-lsn-deployment > 3. a complete different set > You must already be compliant with RFC 6888. As you wrote: "As for you comments on RFC6888, the ones specified in this document are incremental to those" And now you have some additional CGN requirements ... but those requirements are already captured into RFC 6888 ... to which you're already complaint. So what are those additional to? Regards, Benoit > > > > > Regards, > > > > > Victor K > > > > > From: Benoit Claise > Date: Mon, 07 Oct 2013 13:57:08 +0200 > To: > Cc: "opsawg@ietf.org" > Subject: AD review: draft-ietf-opsawg-lsn-deployment-03 > Resent-To: , Victor Kuarsingh > > > > > > > > Dear authors, > > > - Section 3. CGN Network Deployment Requirements > > If a service provider is considering a CGN deployment with a provider > NAT44 function, there are a number of basic architectural > requirements which are of importance. Preliminary architectural > requirements may require all or some of the following from the > incoming CGN system: > > Then there is a long list of points. > I spent some time on each point, making sure I understood it. > Then, reading further, I realized that each point is expanded in the sub > section. > This should be explained up front. > > - I see Section 3 CGN Network Deployment Requirements > What is the link with the requirements in rfc6888? > Yes, there are a few references, for example in section 3.7 and 3.8 for > specific requirements, but what about the other requirements. So the > requirements in this document are > 1. on top of the RFC6888 > 2. a subset of those that are important for > draft-ietf-opsawg-lsn-deployment > 3. a complete different set > > Btw, RFC6888 lists: >> >> 3 . Requirements for CGNs >> What follows is a list of requirements for CGNs. They are in >> addition to those found in other documents such as [RFC4787 >> ], >> [RFC5382 ], and [RFC5508 >> ]. >> > > Again, same question for these extra RFCs. > > > Editorial: > > Abstract > OLD: > > This > document provides a practical integration model which allows the CGN > platform to be integrated into the network meeting the connectivity > needs of the subscriber while being mindful of not disrupting > existing services and meeting the technical challenges that CGN > brings. > > NEW: > This > document provides a practical integration model which allows the CGN > platform to be integrated into the network, meeting the connectivity > needs of the subscriber while being mindful of not disrupting > existing services and meeting the technical challenges that CGN > brings. > > Section 1. Introduction > OLD: > > To face this challenge, operators may need to deploy CGN (Carrier > Grade NAT) as described in [RFC6888] to help extend the connectivity > matrix once IPv4 addresses caches run out on the local local > operator. > > NEW: > To face this challenge, operators may need to deploy CGN (Carrier > Grade NAT) as described in [RFC6888] to help extend the connectivity > matrix once IPv4 addresses caches run out on the local > operator. > > Section 2. Motivation > > OLD: > > The ability to replace IPv4-Only equipment may be out of the control > of the operator, and even when it's in the administrative control; it > poses both cost and technical challenges as operators build out > massive programs for equipment retirement or upgrade. > > NEW: > The ability to replace IPv4-only equipment may be out of the control > of the operator, and even when it's in the administrative control, it > poses both cost and technical challenges as operators build out > massive programs for equipment retirement or upgrade. > > Section 2. Motivation > > OLD: > > > This will include solving a number of challenges > since subscribers who's connections require translation will have > network routing and flow needs which are different from legacy IPv4 > connections. > > NEW: > This will include solving a number of challenges > since subscribers whose connections require translation will have network > routing and flow needs which are different from legacy IPv4 > connections. > > Section 3.3 CGN By-Pass > > OLD: > CGN > By-pass can be accomplished in many ways, but a simplistic, > deterministic and scalable model is preferred. > > NEW: > CGN > by-pass can be accomplished in many ways, but a simplistic, > deterministic and scalable model is preferred. > > > Section 3.5. Flexible Deployment Options > > OLD: > Depending on hardware capabilities, security practices and IPv4 > address availability, the translation environments my need to be > segmented and/or scaled over time to meet organic IPv4 demand growth. > > NEW: > Depending on hardware capabilities, security practices and IPv4 > address availability, the translation environments may need to be > segmented and/or scaled over time to meet organic IPv4 demand growth. > > > - Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN > Attachment Options > Something weird with the section format, at least in the html version > > - A couple of acronyms > > - Flexibility should include integration options for common access > technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ > ASN-GW), and direct Ethernet; > > - expand large-scale NAT (LSN) > > > Regards, Benoit > > > > > --B_3464930559_2594020 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Benoit,

=
Ok, I see your point of confusion.  If 3.8 was called, "Base CGN R= equirements", and the text was modified a bit to not that other architectura= l requirements are actually covered in RFC6888, would this help remove the c= onfusion and bring some clarity?

Regards,

Victor K

Fro= m: Benoit Claise <bclaise@cisc= o.com>
Date: Fri, 18 Oct 20= 13 12:27:56 +0200
To: Victor Kuars= ingh <victor@jvknet.com>
Cc: <draft-ietf-opsawg-lsn-deployment@tools.ietf= .org>, "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: AD review: draft-ietf-opsawg-lsn-deployment= -03

Hi Victor,

See in-line.
Benoit,

Thanks for the thorough review. I will split my response into three sections to address the various ares you commented on.

(1).  As for section 3 (network deployment requirements lis= t and subsequent explanation), I will add text which clarifies this list expanded and described in the following sub-sections [new text on updated I-D]

(2). Editorial comments at the tail end of the email [will review and make the updates to text]

(3).  As for you comments on RFC6888, the ones specified in= this document are incremental to those. 
The "requirements" as stated here are ones related a deployment architecture (based on experience gained in actually going through the process).  There are different then those listed in RFC6888 which concentrate on the NAT function itself.&nbs= p;
Here (in document) we concentrate on architectural/deployment requirements for deploying a system using NAT44.  So by extension, no direct reference was made to RFC4787, RFC5328 or RFC5508 since these are more appropriate for someone building a CGN function.

The reason for the references in section 3.7 and 3.8 are related to the fact that there is overlap between the architectural requirements and the the functional (NAT44/CGN function) requirement of the CGN box/device itself.  This was = in regard to (1) NAT logging which is both a requirement as stated in RFC6888 for the implemented of CGN box/device, but also a architectural requirement for an operator needed to facilitate the needs of the business.  In section 3.8 there is mention of= support for bulk port allocation.  This again is a architectur= al requirement (to deal with practical scaling issues in real CGN deployments and ability to successful log) and as stated in RFC6888 a CGN device level requirement.

Since there was existing text in RFC6888 which deal with NAT logging and port allocation (I.e. REQ-14 in RFC6888), we thought references to that RFC were appropriate.

So, I will make updates on point 1 and 2 above.  As for poi= nt 3, if you are satisfied with this explanation, then I can let it be.  If you think you want to see text that specifically describes what I have put in my point 3 above, then I can do that as well.

From your draft, the paragraphs referring to RFC 6888 are:
   To face this challenge, operators may need to d=
eploy CGN (Carrier
   Grade NAT) as described in [RFC68=
88] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local local
   operator.
     ...
   Operators may need to keep track of this inform=
ation (securely) to
   meet regulatory and/or legal obligations.  Further information ca=
n be
   found in [RFC6888] with respe=
ct to CGN logging requirements (Logging
   Section).
     ...

   3.8.  Addi=
tional CGN Requirements
   The CGN platform will also need to meet the nee=
ds of additional
   requirements such as Bulk Port Allocation and other CGN device
   specific functions.  These additional requirements are captured
   within [RFC6888].

The last paragraph ("additional" in the title and "these additional requirements") is my source of confusion I guess, and led to the question in my review
So the requirements in this document are
    1. on top of the RFC6888
    2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment
    3. a complete different set
You must already be compliant with RFC 6888. As you wrote: "As for you comments on RFC6888, the ones specified in this document are inc= remental to those"
And now you have some additional CGN requirements ... but those requirements are already captured into RFC 6888 ... to which you're already complaint. So what are those additional to?

Regards, Benoit

Regards,

Victor K

From: Benoit Claise <bclaise@cisco.com>
Date: Mon, 07 Oct 2013 13:57:08 +0200
To: <draft-= ietf-opsawg-lsn-deployment@tools.ietf.org>
Cc: "opsawg@ietf.org" <opsaw= g@ietf.org>
Subject: AD review: draft-ietf-opsawg-lsn-deployment-03
Resent-To: <john.cianfarani@= rci.rogers.com>, Victor Kuarsingh <victor@jvknet.com>

Dear authors,

- Section 3. CGN Network Deployment Requirements 
   If a service provider is considering =
a CGN deployment with a provider
   NAT44 function, there are a number of basic architectural
   requirements which are of importance.  Preliminary architectural
   requirements may require all or some of the following from the
   incoming CGN system:

Then there is a long list of points.
I spent some time on each point, making sure I understood it.
Then, reading further, I realized that each point is expanded in the sub se=
ction. 
This should be explained up front.

- I see Section 3 CGN Network Deployment Requirements
What is the link with the requirements in rfc6888?
Yes, there are a few references, for example in section 3.7 and 3.8 for specific requirements, but what about the other requirements. So the requirements in this document are
    1. on top of the RFC6888
    2. a subset of those that are important fo= r draft-ietf-opsawg-lsn-deployment
    3. a complete different set

Btw, RFC6888 lists: 
3.  Requirements for CGNs
   What follows =
is a list of requirements for CGNs.  They are in
   addition to those found in other documents such as [RFC4787],
   [RFC5382], and [RFC5508].
Again, same question for these extra RFC=
s.


Editorial:

Abstract
OLD:
   This
   document provides a practical integration model which allows the CGN
   platform to be integrated into the network meeting the connectivity
   needs of the subscriber while being mindful of not disrupting
   existing services and meeting the technical challenges that CGN
   brings.

NEW:
   This
   document provides a practical integration model which allows the CGN
   platform to be integrated into the network, meeting the connectiv=
ity
   needs of the subscriber while being mindful of not disrupting
   existing services and meeting the technical challenges that CGN
   brings.

Section 1. Introduction
OLD:
To face this challenge, operators may need to deploy CGN=
 (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local local
   operator. 

NEW:
To face this challenge, operators may need to deploy CGN (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local
   operator.

Section 2. Motivation

OLD:
   The ability to replace IPv4-Only equipment may be out=
 of the control
   of the operator, and even when it's in the administrative control; it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade. 

NEW:
   The ability to replace IPv4-only equipment may be out of the cont=
rol
   of the operator, and even when it's in the administrative control, it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade.

Section 2. Motivation

OLD:
   This will include solving a number =
of challenges
   since subscribers who's connections require translation will have
   network routing and flow needs which are different from legacy IPv4
   connections.

NEW:
   This will include solving a number of challenges
   since subscribers whose connections require translation will have=
   network routing and flow needs which are different from legacy IPv4
   connections.

Section 3.3 CGN By-Pass

OLD:
   CGN
   By-pass can be accomplished in many ways, but a simplistic,
   deterministic and scalable model is preferred.

NEW:
   CGN
   by-pass can be accomplished in many ways, but a simplistic,
   deterministic and scalable model is preferred.


Section 3.5.  Flexible Deployment Options

OLD:
   Depending on hardware capabilities, security practices and IPv4
   address availability, the translation environments my need to be
   segmented and/or scaled over time to meet organic IPv4 demand growth.

NEW:
   Depending on hardware capabilities, security practices and IPv4
   address availability, the translation environments may need to be
   segmented and/or scaled over time to meet organic IPv4 demand growth.
- Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment Options
Something weird with the section format, at least in the html version

- A couple of acronyms
      - Flexibility should include int=
egration options for common access
      technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/
      ASN-GW), and direct Ethernet;
	
    - expand large-scale NAT (LSN)

Regards, Benoit

--B_3464930559_2594020-- From bclaise@cisco.com Fri Oct 18 05:47:28 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B403411E822E for ; Fri, 18 Oct 2013 05:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+JHvTu+iYA6 for ; Fri, 18 Oct 2013 05:47:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 56EDB11E8295 for ; Fri, 18 Oct 2013 05:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30056; q=dns/txt; s=iport; t=1382100438; x=1383310038; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=WRr06zYMOGkb6y7BmUtNCEcofnIYsDZsw/D+vXa6iNA=; b=Ip38PXzYZluX67jxC5rchqAeWZgS99JUtIlzbgkOyKvY08nIY1t1O0d5 uI27YEpluU8mYw70aBvCcI1+tlzzCPclrxFLqfG4dJLNAIAXaSypBFqlU zdObLpJIu1ziyObRBicfILjJifAPP4ueNEKpYpuZfGwUh6OaYjZbIt+EF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAI0tYVKQ/khL/2dsb2JhbABagkNEOIlYtRqBJBZ0giUBAQEEZwUMARALEQECAQIKFgEHBwkDAgECATQDBggGDQEFAgEBiAIMwFWODYE4DAUHhCkDmAmBL4UMi0yDJjqBNA X-IronPort-AV: E=Sophos;i="4.93,522,1378857600"; d="scan'208,217";a="160790497" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2013 12:47:01 +0000 Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9ICkuAm002138; Fri, 18 Oct 2013 12:46:57 GMT Message-ID: <52612DC0.3020007@cisco.com> Date: Fri, 18 Oct 2013 14:46:56 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Victor Kuarsingh References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040100080008090009000606" Cc: "opsawg@ietf.org" , draft-ietf-opsawg-lsn-deployment@tools.ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-lsn-deployment-03 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 12:47:29 -0000 This is a multi-part message in MIME format. --------------040100080008090009000606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Victor, > Benoit, > > Ok, I see your point of confusion. If 3.8 was called, "Base CGN > Requirements", and the text was modified a bit to not that other > architectural requirements are actually covered in RFC6888, would this > help remove the confusion and bring some clarity? Yes, thanks. Regards, Benoit > > Regards, > > Victor K > > From: Benoit Claise > > Date: Fri, 18 Oct 2013 12:27:56 +0200 > To: Victor Kuarsingh > > Cc: >, > "opsawg@ietf.org " > > Subject: Re: AD review: draft-ietf-opsawg-lsn-deployment-03 > > Hi Victor, > > See in-line. >> Benoit, >> >> Thanks for the thorough review. I will split my response into three >> sections to address the various ares you commented on. >> >> (1). As for section 3 (network deployment requirements list and >> subsequent explanation), I will add text which clarifies this list >> expanded and described in the following sub-sections [new text on >> updated I-D] >> >> (2). Editorial comments at the tail end of the email [will review and >> make the updates to text] >> >> (3). As for you comments on RFC6888, the ones specified in this >> document are incremental to those. >> The "requirements" as stated here are ones related a deployment >> architecture (based on experience gained in actually going through >> the process). There are different then those listed in RFC6888 which >> concentrate on the NAT function itself. >> Here (in document) we concentrate on architectural/deployment >> requirements for deploying a system using NAT44. So by extension, no >> direct reference was made to RFC4787, RFC5328 or RFC5508 since these >> are more appropriate for someone building a CGN function. >> >> The reason for the references in section 3.7 and 3.8 are related to >> the fact that there is overlap between the architectural requirements >> and the the functional (NAT44/CGN function) requirement of the CGN >> box/device itself. This was in regard to (1) NAT logging which is >> both a requirement as stated in RFC6888 for the implemented of CGN >> box/device, but also a architectural requirement for an operator >> needed to facilitate the needs of the business. In section 3.8 there >> is mention of support for bulk port allocation. This again is a >> architectural requirement (to deal with practical scaling issues in >> real CGN deployments and ability to successful log) and as stated in >> RFC6888 a CGN device level requirement. >> >> Since there was existing text in RFC6888 which deal with NAT logging >> and port allocation (I.e. REQ-14 in RFC6888), we thought references >> to that RFC were appropriate. >> >> So, I will make updates on point 1 and 2 above. As for point 3, if >> you are satisfied with this explanation, then I can let it be. If >> you think you want to see text that specifically describes what I >> have put in my point 3 above, then I can do that as well. > > From your draft, the paragraphs referring to RFC 6888 are: > To face this challenge, operators may need to deploy CGN (Carrier > Grade NAT) as described in [RFC6888 ] to help extend the connectivity > matrix once IPv4 addresses caches run out on the local local > operator. > ... > Operators may need to keep track of this information (securely) to > meet regulatory and/or legal obligations._Further information_ can be > found in [RFC6888 ] with respect to CGN logging requirements (Logging > Section). > ... > > > 3.8. _Additional _CGN Requirements > > The CGN platform will also need to meet the needs of additional > requirements such as Bulk Port Allocation and other CGN device > specific functions._These additional requirements_ are captured > within [RFC6888 ]. > > The last paragraph ("additional" in the title and "these additional > requirements") is my source of confusion I guess, and led to the > question in my review > > So the requirements in this document are > 1. on top of the RFC6888 > 2. a subset of those that are important for > draft-ietf-opsawg-lsn-deployment > 3. a complete different set > > You must already be compliant with RFC 6888. As you wrote: "As for you > comments on RFC6888, the ones specified in this document are > _incremental _to those" > And now you have some additional CGN requirements ... but those > requirements are already captured into RFC 6888 ... to which you're > already complaint. So what are those additional to? > > Regards, Benoit >> >> Regards, >> >> Victor K >> >> From: Benoit Claise > >> Date: Mon, 07 Oct 2013 13:57:08 +0200 >> To: > > >> Cc: "opsawg@ietf.org " > > >> Subject: AD review: draft-ietf-opsawg-lsn-deployment-03 >> Resent-To: > >, Victor Kuarsingh >> > >> >> Dear authors, >> >> - Section 3. CGN Network Deployment Requirements >> If a service provider is considering a CGN deployment with a provider >> NAT44 function, there are a number of basic architectural >> requirements which are of importance. Preliminary architectural >> requirements may require all or some of the following from the >> incoming CGN system: >> >> Then there is a long list of points. >> I spent some time on each point, making sure I understood it. >> Then, reading further, I realized that each point is expanded in the sub section. >> This should be explained up front. >> >> - I see Section 3 CGN Network Deployment Requirements >> What is the link with the requirements in rfc6888? >> Yes, there are a few references, for example in section 3.7 and 3.8 >> for specific requirements, but what about the other requirements. So >> the requirements in this document are >> 1. on top of the RFC6888 >> 2. a subset of those that are important for >> draft-ietf-opsawg-lsn-deployment >> 3. a complete different set >> >> Btw, RFC6888 lists: >> >> >> 3 . >> Requirements for CGNs >> >> What follows is a list of requirements for CGNs. They are in >> addition to those found in other documents such as [RFC4787 ], >> [RFC5382 ], and [RFC5508 ]. >> >> Again, same question for these extra RFCs. >> >> _ >> Editorial:_ >> >> Abstract >> OLD: >> This >> document provides a practical integration model which allows the CGN >> platform to be integrated into the network meeting the connectivity >> needs of the subscriber while being mindful of not disrupting >> existing services and meeting the technical challenges that CGN >> brings. >> >> NEW: >> This >> document provides a practical integration model which allows the CGN >> platform to be integrated into the_network,_ meeting the connectivity >> needs of the subscriber while being mindful of not disrupting >> existing services and meeting the technical challenges that CGN >> brings. >> >> Section 1. Introduction >> OLD: >> To face this challenge, operators may need to deploy CGN (Carrier >> Grade NAT) as described in [RFC6888] to help extend the connectivity >> matrix once IPv4 addresses caches run out on the local local >> operator. >> >> NEW: >> To face this challenge, operators may need to deploy CGN (Carrier >> Grade NAT) as described in [RFC6888] to help extend the connectivity >> matrix once IPv4 addresses caches run out on the local >> operator. >> >> Section 2. Motivation >> >> OLD: >> The ability to replace IPv4-Only equipment may be out of the control >> of the operator, and even when it's in the administrative control; it >> poses both cost and technical challenges as operators build out >> massive programs for equipment retirement or upgrade. >> >> NEW: >> The ability to replace_IPv4-only_ equipment may be out of the control >> of the operator, and even when it's in the administrative_control,_ it >> poses both cost and technical challenges as operators build out >> massive programs for equipment retirement or upgrade. >> >> Section 2. Motivation >> >> OLD: >> This will include solving a number of challenges >> since subscribers who's connections require translation will have >> network routing and flow needs which are different from legacy IPv4 >> connections. >> >> NEW: >> This will include solving a number of challenges >> since subscribers_whose_connections require translation will have network routing and flow needs which are different from legacy IPv4 >> connections. >> >> Section 3.3 CGN By-Pass >> >> OLD: >> CGN >> By-pass can be accomplished in many ways, but a simplistic, >> deterministic and scalable model is preferred. >> >> NEW: >> CGN >> by-pass can be accomplished in many ways, but a simplistic, >> deterministic and scalable model is preferred. >> >> >> Section 3.5. Flexible Deployment Options >> >> OLD: >> Depending on hardware capabilities, security practices and IPv4 >> address availability, the translation environments my need to be >> segmented and/or scaled over time to meet organic IPv4 demand growth. >> >> NEW: >> Depending on hardware capabilities, security practices and IPv4 >> address availability, the translation environments may need to be >> segmented and/or scaled over time to meet organic IPv4 demand growth. >> >> >> - Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN >> Attachment Options >> Something weird with the section format, at least in the html version >> >> - A couple of acronyms >> - Flexibility should include integration options for common access >> technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ >> ASN-GW), and direct Ethernet; >> >> - expand large-scale NAT (LSN) >> >> Regards, Benoit >> > --------------040100080008090009000606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Victor,
Benoit,

Ok, I see your point of confusion.  If 3.8 was called, "Base CGN Requirements", and the text was modified a bit to not that other architectural requirements are actually covered in RFC6888, would this help remove the confusion and bring some clarity?
Yes, thanks.

Regards, Benoit

Regards,

Victor K

From: Benoit Claise <bclaise@cisco.com>
Date: Fri, 18 Oct 2013 12:27:56 +0200
To: Victor Kuarsingh <victor@jvknet.com>
Cc: <draft-ietf-opsawg-lsn-deployment@tools.ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: AD review: draft-ietf-opsawg-lsn-deployment-03

Hi Victor,

See in-line.
Benoit,

Thanks for the thorough review. I will split my response into three sections to address the various ares you commented on.

(1).  As for section 3 (network deployment requirements list and subsequent explanation), I will add text which clarifies this list expanded and described in the following sub-sections [new text on updated I-D]

(2). Editorial comments at the tail end of the email [will review and make the updates to text]

(3).  As for you comments on RFC6888, the ones specified in this document are incremental to those. 
The "requirements" as stated here are ones related a deployment architecture (based on experience gained in actually going through the process).  There are different then those listed in RFC6888 which concentrate on the NAT function itself. 
Here (in document) we concentrate on architectural/deployment requirements for deploying a system using NAT44.  So by extension, no direct reference was made to RFC4787, RFC5328 or RFC5508 since these are more appropriate for someone building a CGN function.

The reason for the references in section 3.7 and 3.8 are related to the fact that there is overlap between the architectural requirements and the the functional (NAT44/CGN function) requirement of the CGN box/device itself.  This was in regard to (1) NAT logging which is both a requirement as stated in RFC6888 for the implemented of CGN box/device, but also a architectural requirement for an operator needed to facilitate the needs of the business.  In section 3.8 there is mention of support for bulk port allocation.  This again is a architectural requirement (to deal with practical scaling issues in real CGN deployments and ability to successful log) and as stated in RFC6888 a CGN device level requirement.

Since there was existing text in RFC6888 which deal with NAT logging and port allocation (I.e. REQ-14 in RFC6888), we thought references to that RFC were appropriate.

So, I will make updates on point 1 and 2 above.  As for point 3, if you are satisfied with this explanation, then I can let it be.  If you think you want to see text that specifically describes what I have put in my point 3 above, then I can do that as well.

From your draft, the paragraphs referring to RFC 6888 are:
   To face this challenge, operators may need to deploy CGN (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local local
   operator.
     ...
   Operators may need to keep track of this information (securely) to
   meet regulatory and/or legal obligations.  Further information can be
   found in [RFC6888] with respect to CGN logging requirements (Logging
   Section).
     ...

   3.8.  Additional CGN Requirements
   The CGN platform will also need to meet the needs of additional
   requirements such as Bulk Port Allocation and other CGN device
   specific functions.  These additional requirements are captured
   within [RFC6888].

The last paragraph ("additional" in the title and "these additional requirements") is my source of confusion I guess, and led to the question in my review
So the requirements in this document are
    1. on top of the RFC6888
    2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment
    3. a complete different set
You must already be compliant with RFC 6888. As you wrote: "As for you comments on RFC6888, the ones specified in this document are incremental to those"
And now you have some additional CGN requirements ... but those requirements are already captured into RFC 6888 ... to which you're already complaint. So what are those additional to?

Regards, Benoit

Regards,

Victor K

From: Benoit Claise <bclaise@cisco.com>
Date: Mon, 07 Oct 2013 13:57:08 +0200
To: <draft-ietf-opsawg-lsn-deployment@tools.ietf.org>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: AD review: draft-ietf-opsawg-lsn-deployment-03
Resent-To: <john.cianfarani@rci.rogers.com>, Victor Kuarsingh <victor@jvknet.com>

Dear authors,

- Section 3. CGN Network Deployment Requirements 
   If a service provider is considering a CGN deployment with a provider
   NAT44 function, there are a number of basic architectural
   requirements which are of importance.  Preliminary architectural
   requirements may require all or some of the following from the
   incoming CGN system:

Then there is a long list of points.
I spent some time on each point, making sure I understood it.
Then, reading further, I realized that each point is expanded in the sub section. 
This should be explained up front.

- I see Section 3 CGN Network Deployment Requirements
What is the link with the requirements in rfc6888?
Yes, there are a few references, for example in section 3.7 and 3.8 for specific requirements, but what about the other requirements. So the requirements in this document are
    1. on top of the RFC6888
    2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment
    3. a complete different set

Btw, RFC6888 lists: 
3.  Requirements for CGNs
   What follows is a list of requirements for CGNs.  They are in
   addition to those found in other documents such as [RFC4787],
   [RFC5382], and [RFC5508].
Again, same question for these extra RFCs.


Editorial:

Abstract
OLD:
   This
   document provides a practical integration model which allows the CGN
   platform to be integrated into the network meeting the connectivity
   needs of the subscriber while being mindful of not disrupting
   existing services and meeting the technical challenges that CGN
   brings.

NEW:
   This
   document provides a practical integration model which allows the CGN
   platform to be integrated into the network, meeting the connectivity
   needs of the subscriber while being mindful of not disrupting
   existing services and meeting the technical challenges that CGN
   brings.

Section 1. Introduction
OLD:
To face this challenge, operators may need to deploy CGN (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local local
   operator. 

NEW:
To face this challenge, operators may need to deploy CGN (Carrier
   Grade NAT) as described in [RFC6888] to help extend the connectivity
   matrix once IPv4 addresses caches run out on the local
   operator.

Section 2. Motivation

OLD:
   The ability to replace IPv4-Only equipment may be out of the control
   of the operator, and even when it's in the administrative control; it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade. 

NEW:
   The ability to replace IPv4-only equipment may be out of the control
   of the operator, and even when it's in the administrative control, it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade.

Section 2. Motivation

OLD:
   This will include solving a number of challenges
   since subscribers who's connections require translation will have
   network routing and flow needs which are different from legacy IPv4
   connections.

NEW:
   This will include solving a number of challenges
   since subscribers whose connections require translation will have   network routing and flow needs which are different from legacy IPv4
   connections.

Section 3.3 CGN By-Pass

OLD:
   CGN
   By-pass can be accomplished in many ways, but a simplistic,
   deterministic and scalable model is preferred.

NEW:
   CGN
   by-pass can be accomplished in many ways, but a simplistic,
   deterministic and scalable model is preferred.


Section 3.5.  Flexible Deployment Options

OLD:
   Depending on hardware capabilities, security practices and IPv4
   address availability, the translation environments my need to be
   segmented and/or scaled over time to meet organic IPv4 demand growth.

NEW:
   Depending on hardware capabilities, security practices and IPv4
   address availability, the translation environments may need to be
   segmented and/or scaled over time to meet organic IPv4 demand growth.
- Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment Options
Something weird with the section format, at least in the html version

- A couple of acronyms
      - Flexibility should include integration options for common access
      technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/
      ASN-GW), and direct Ethernet;
	
    - expand large-scale NAT (LSN)

Regards, Benoit


--------------040100080008090009000606-- From Tina.Tsou.Zouting@huawei.com Fri Oct 18 08:28:57 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC3611E82F3 for ; Fri, 18 Oct 2013 08:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.178 X-Spam-Level: X-Spam-Status: No, score=-5.178 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf6YDKqYv3Tl for ; Fri, 18 Oct 2013 08:28:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E19A711E81F3 for ; Fri, 18 Oct 2013 08:28:10 -0700 (PDT) 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 AWX81449; Fri, 18 Oct 2013 15:28:08 +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.146.0; Fri, 18 Oct 2013 16:27:16 +0100 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 16:28:05 +0100 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.123]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Fri, 18 Oct 2013 08:27:56 -0700 From: Tina TSOU To: Keiichi SHIMA Thread-Topic: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt Thread-Index: AQHOyydtQeYrjXyY3Eq5WVzS/ngyjZn5tlIAgADAugCAAB/hbg== Date: Fri, 18 Oct 2013 15:27:55 +0000 Message-ID: References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <525D544E.1030507@cisco.com> <4289DA69-E42A-495E-B7B7-E72EA53AD81F@wide.ad.jp> <526034A2.7090801@cisco.com>, <3C61DF63-48C7-42E0-91B2-E6673CCCCD51@wide.ad.jp> In-Reply-To: <3C61DF63-48C7-42E0-91B2-E6673CCCCD51@wide.ad.jp> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 15:28:58 -0000 RGVhciBTSElNQS1TYW4sDQpObyBvYmplY3Rpb24uDQoNClRoYW5rIHlvdSwNClRpbmENCg0KT24g T2N0IDE3LCAyMDEzLCBhdCAxMTozNCBQTSwgIktlaWljaGkgU0hJTUEiIDxzaGltYUB3aWRlLmFk LmpwPiB3cm90ZToNCg0KPiBKb2UsDQo+IA0KPj4gTm8sIFRDIHN0YXlzIHRoZSBzYW1lLCBidXQg dGhlIHRlbnNlIG9mIHRoZSBzdGF0ZXMgc2hvdWxkIGNoYW5nZSB0bzoNCj4+IA0KPj4gdW5rbm93 bigxKQ0KPj4gZW5hYmxlZCgyKQ0KPj4gZGlzYWJsZWQoMykNCj4+IA0KPj4gU2luY2UgdGhlIGFz c29jaWF0ZWQgb2JqZWN0IGlzIG5vdyByZWFkLW9ubHkuDQo+IA0KPiBJdCBtYWtlcyBzZW5zZS4N Cj4gDQo+IEknbSBPSyB0byB1cGRhdGUgdGhlIGFib3ZlIHZhbHVlcy4gIEFueSBvYmplY3Rpb25z IGZyb20gb3RoZXIgYXV0aG9ycz8NCj4gDQo+IC0tLQ0KPiBLZWlpY2hpIFNISU1BICiNdSCRY9K7 KQ0KPiBXSURFIHByb2plY3QgPHNoaW1hQHdpZGUuYWQuanA+DQo+IFJlc2VhcmNoIExhYm9yYXRv cnksIElJSiBJbm5vdmF0aW9uIEluc3RpdHV0ZSwgSW5jIDxrZWlpY2hpQGlpamxhYi5uZXQ+DQo+ IA0KPiANCj4gDQo+IE9uIDIwMTMvMTAvMTgsIGF0IDQ6MDQsIEpvZSBNYXJjdXMgQ2xhcmtlIDxq Y2xhcmtlQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPj4gT24gMTAvMTcvMTMgNjo1NSBBTSwgS2Vp aWNoaSBTSElNQSB3cm90ZToNCj4+PiBIaSwNCj4+PiANCj4+PiBPbiAyMDEzLzEwLzE1LCBhdCAy Mzo0MiwgSm9lIE1hcmN1cyBDbGFya2UgPGpjbGFya2VAY2lzY28uY29tPiB3cm90ZToNCj4+PiAN Cj4+Pj4gTklUOiBWaXJ0dWFsTWFjaGluZUFkbWluU3RhdGU6DQo+Pj4+IA0KPj4+IA0KPj4+PiBU aGUgZGVzdHJveSg1KSBzdGF0ZSByZWFsbHkgZG9lc24ndCBtYXRjaCBpbiB0ZXJtcyBvZiB0ZW5z ZS4gIFdoYXQgYWJvdXQgZGVzdHJveWVkKDUpPyAgVGhhdCBzYWlkLCBzaW5jZSB0aGlzIGlzIHNv bWV0aGluZyBvbmUgY2FuIHNldCwgcGVyaGFwcyBwcmVzZW50IHRlbnNlIGxpa2UgcnVuLCBwYXVz ZSwgc3VzcGVuZCwgZXRjLiBtYWtlIHNlbnNlLg0KPj4+IA0KPj4+IFRoZSBvcmlnaW5hbCBpbnRl bnRpb24gb2YgdGhlIG5hbWluZyBvZiBWaXJ0dWFsTWFjaGluZUFkbWluU3RhdGUgd2FzLCAndG8g dHJhbnNpdCB0aGUgb3BlcmF0aW9uIHN0YXRlIG9mIGEgdmlydHVhbCBtYWNoaW5lIHRvIFggYnkg c2V0dGluZyBpdHMgYWRtaW4gc3RhdGUgYXMgWCcuICBGb3IgZXhhbXBsZSwgd2hlbiB3ZSBzZXQg J3N1c3BlbmRlZCcgdG8gdGhlIGFkbWluIHN0YXRlIG9mIGEgdmlydHVhbCBtYWNoaW5lLCB0aGVu IHRoZSB2aXJ0dWFsIG1hY2hpbmUgd2lsbCBzdGFydCB0cmFuc2l0aW9uIHRvIHRoZSBzdXNwZW5k ZWQgb3BlcmF0aW9uIHN0YXRlLiAgV2UgaW50ZW50aW9uYWxseSB1c2VkIHRoZSBzYW1lIHN0YXRl IG5hbWVzIGhlcmUuICBUaGF0IGlzIGJlY2F1c2UgdGhlIHRlbnNlIGlzIHBhc3QuDQo+Pj4gDQo+ Pj4gRm9yIHRoZSAnZGVzdHJveScgYWRtaW4gc3RhdGUsIHNpbmNlIHdlIGRpZG4ndCBoYXZlIGFu eSBvcGVyYXRpb24gc3RhdGUgb2YgYSBkZXN0cm95ZWQgdmlydHVhbCBtYWNoaW5lICh0aGF0IGlz IHNhbWUgYXMgdGhlIHNodXRkb3duIG9wZXJhdGlvbiBzdGF0ZSksIHdlIGRpZG4ndCBwYXkgYW55 IGF0dGVudGlvbiB0byB0aGUgbmFtaW5nLiAgSSBjYW4gbGl2ZSB3aXRoIGVpdGhlciBkZXN0cm95 KDUpIG9yIGRlc3Ryb3llZCg1KS4gIEl0IGlzIGEgbWF0dGVyIG9mIHRhc3RlIHRvIG1lLg0KPj4g DQo+PiBJIHRoaW5rIGRlc3Ryb3koNSkgc291bmRzIGJldHRlciwgYnV0IEknbGwgYWRtaXQgaXQg aXMgYSBuaXQuDQo+PiANCj4+PiANCj4+PiANCj4+Pj4gTklUIChtYXliZSBhIG1pbm9yIGlzc3Vl KTogVmlydHVhbE1hY2hpbmVBdXRvU3RhcnQ6DQo+Pj4+IA0KPj4+PiBBZ2FpbiwgdGVuc2UuICBI ZXJlLCBJIHRoaW5rIHBhc3QgdGVuc2Ugd29ya3MgYmVzdCBzaW5jZSB3ZSBkZWNpZGVkIHRoaXMg d291bGQgcmVmbGVjdCBhIHJlYWQtb25seSBzdGF0ZS4gIEkgdGhpbmsgZW5hYmxlZCBhbmQgZGlz YWJsZWQgd29yayBiZXN0Lg0KPj4+IA0KPj4+IERvIHlvdSBtZWFuIGNoYW5naW5nIHRoZSBuYW1l IHRvIHNvbWV0aGluZyBsaWtlICdWaXJ0dWFsTWFjaGluZUF1dG9TdGFydEVuYWJsZWQnPyAgSGVy ZSBhZ2FpbiwgSSBkb24ndCBoYXZlIGFueSBzdHJvbmcgb3BpbmlvbiBvbiB0aGlzLiAgSSBhbSBv cGVuIHRvIGNoYW5nZSB0aGUgbmFtZSwgaWYgbW9zdCBwZW9wbGUgYWdyZWUgb24gdGhpcy4NCj4+ IA0KPj4gTm8sIFRDIHN0YXlzIHRoZSBzYW1lLCBidXQgdGhlIHRlbnNlIG9mIHRoZSBzdGF0ZXMg c2hvdWxkIGNoYW5nZSB0bzoNCj4+IA0KPj4gdW5rbm93bigxKQ0KPj4gZW5hYmxlZCgyKQ0KPj4g ZGlzYWJsZWQoMykNCj4+IA0KPj4gU2luY2UgdGhlIGFzc29jaWF0ZWQgb2JqZWN0IGlzIG5vdyBy ZWFkLW9ubHkuDQo+PiANCj4+IEpvZQ0KPj4gDQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiAtLS0N Cj4+PiBLZWlpY2hpIFNISU1BICiNdSCRY9K7KQ0KPj4+IFdJREUgcHJvamVjdCA8c2hpbWFAd2lk ZS5hZC5qcD4NCj4+PiBSZXNlYXJjaCBMYWJvcmF0b3J5LCBJSUogSW5ub3ZhdGlvbiBJbnN0aXR1 dGUsIEluYyA8a2VpaWNoaUBpaWpsYWIubmV0Pg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IE9uIDIw MTMvMTAvMTUsIGF0IDIzOjQyLCBKb2UgTWFyY3VzIENsYXJrZSA8amNsYXJrZUBjaXNjby5jb20+ IHdyb3RlOg0KPj4+IA0KPj4+PiBPbiAxMC8xMy8xMyAxMTowNSBQTSwgSGlyb2NoaWthIEFzYWkg d3JvdGU6DQo+Pj4+PiBIaSBmb2xrcywNCj4+Pj4+IA0KPj4+Pj4gVGhhbmtzIHRvIGNvbW1lbnRz IGZyb20gdGhlIG1haWxpbmcgbGlzdCwgd2UndmUgdXBsb2FkZWQgbmV3IHZlcnNpb24NCj4+Pj4+ IG9mIG91ciBJLUQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFzYWktdm1tLW1p Yi0wNQ0KPj4+Pj4gDQo+Pj4+PiBXZSB3b3VsZCBsaWtlIHRvIHN1Ym1pdCBvdXIgSS1EIGFzIGEg d29ya2luZyBncm91cCBkcmFmdCBzb29uIGFuZA0KPj4+Pj4gaGF2ZSBhIGRpc2N1c3Npb24gaW4g dGhlIG5leHQgSUVURiBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuDQo+Pj4+PiBDaGFpcnMsIGNv dWxkIHlvdSBwbGVhc2UgcG9sbCBmb3IgYWRvcHRpb24gYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0N Cj4+Pj4+IG9uIHRoZSBtYWlsaW5nIGxpc3Q/DQo+Pj4+PiANCj4+Pj4+IEkndmUgYWxyZWFkeSBu b3RpY2VkIGFuIGVycm9yOiBSRkM0MTMzIG11c3QgYmUgUkZDNjkzMy4gIFBsZWFzZSBsZXQNCj4+ Pj4+IHVzIGtub3cgaWYgeW91IGZpbmQgYW55IG90aGVyIGVycm9ycy4gIFRoZXNlIGVycm9ycyB3 aWxsIGJlDQo+Pj4+PiBjb3JyZWN0ZWQgaW4gdGhlIG5leHQgdmVyc2lvbiAodGhlIGZpcnN0IHZl cnNpb24gZm9yIHdvcmtpbmcgZ3JvdXANCj4+Pj4+IGRyYWZ0IGlmIGFkb3B0ZWQpLg0KPj4+PiAN Cj4+Pj4gT3ZlcmFsbCwgSSBsaWtlIHRoZSBjaGFuZ2VzLiAgVGhhbmtzIQ0KPj4+PiANCj4+Pj4g TklUOiBWaXJ0dWFsTWFjaGluZUFkbWluU3RhdGU6DQo+Pj4+IA0KPj4+PiBUaGUgZGVzdHJveSg1 KSBzdGF0ZSByZWFsbHkgZG9lc24ndCBtYXRjaCBpbiB0ZXJtcyBvZiB0ZW5zZS4gIFdoYXQgYWJv dXQgZGVzdHJveWVkKDUpPyAgVGhhdCBzYWlkLCBzaW5jZSB0aGlzIGlzIHNvbWV0aGluZyBvbmUg Y2FuIHNldCwgcGVyaGFwcyBwcmVzZW50IHRlbnNlIGxpa2UgcnVuLCBwYXVzZSwgc3VzcGVuZCwg ZXRjLiBtYWtlIHNlbnNlLg0KPj4+PiANCj4+Pj4gVGhhbmtzIGZvciBmbGVzaGluZyBvdXQgdGhl IHN0YXRlIGRlZmluaXRpb25zIDotKS4NCj4+Pj4gDQo+Pj4+IE5JVCAobWF5YmUgYSBtaW5vciBp c3N1ZSk6IFZpcnR1YWxNYWNoaW5lQXV0b1N0YXJ0Og0KPj4+PiANCj4+Pj4gQWdhaW4sIHRlbnNl LiAgSGVyZSwgSSB0aGluayBwYXN0IHRlbnNlIHdvcmtzIGJlc3Qgc2luY2Ugd2UgZGVjaWRlZCB0 aGlzIHdvdWxkIHJlZmxlY3QgYSByZWFkLW9ubHkgc3RhdGUuICBJIHRoaW5rIGVuYWJsZWQgYW5k IGRpc2FibGVkIHdvcmsgYmVzdC4NCj4+Pj4gDQo+Pj4+IEluIHRlcm1zIG9mIHRoZSBuZXcgbm90 aWZpY2F0aW9ucywgd2h5IGVudW1lcmF0ZSBhbGwgc3RhdGVzIGFzIG5vdGlmaWNhdGlvbnM/ICBN eSBvcmlnaW5hbCBjb21tZW50IHN1Z2dlc3RlZCBhIHNpbmdsZSBzdGF0ZSBjaGFuZ2Ugbm90aWZp Y2F0aW9uIHdoZXJlIHRoZSBuZXcgYW5kIHByZXZpb3VzIHN0YXRlIHdvdWxkIGJlIGF2YWlsYWJs ZSBhcyBvYmplY3RzIChub3RlOiB0aGlzIHdvdWxkIHJlcXVpcmUgdGhlIGRlZmluaXRpb24gb2Yg YSBwcmV2aW91cyBzdGF0ZSBvYmplY3QpLiAgSXQganVzdCBzZWVtcyBsaWtlIHRoZSB3YXkgeW91 J3ZlIGltcGxlbWVudGVkIGl0IHdvdWxkIGJlIGhhcmRlciB0byBzY2FsZSBpZiBuZXcgc3RhdGVz IG5lZWQgdG8gYmUgYWRkZWQgaW4gdGhlIGZ1dHVyZS4NCj4+Pj4gDQo+Pj4+IEpvZQ0KPj4+PiAN Cj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBIZXJlLCBJIHN1bW1hcml6ZSB0aGUgdXBkYXRlcyBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uLg0KPj4+Pj4gDQo+Pj4+PiAqIEFjY29yZGluZyB0byB0aGUg dGhyZWFkIEpvZS0xDQo+Pj4+PiBNb2RpZmllZCBhIHBhcmFncmFwaCBhcyBmb2xsb3dzOg0KPj4+ Pj4gDQo+Pj4+PiBUaGUgZGVzaWduIG9mIHRoaXMgTUlCIG1vZHVsZSBoYXMgYmVlbiBkZXJpdmVk IGZyb20gZW50ZXJwcmlzZQ0KPj4+Pj4gc3BlY2lmaWMgTUlCIG1vZHVsZXMsIG5hbWVseSBhIE1J QiBtb2R1bGUgZm9yIG1hbmFnaW5nIGd1ZXN0cyBvZiB0aGUNCj4+Pj4+IFhlbiBoeXBlcnZpc29y LCBhIE1JQiBtb2R1bGUgZm9yIG1hbmFnaW5nIHZpcnR1YWwgbWFjaGluZXMgY29udHJvbGxlZA0K Pj4+Pj4gYnkgdGhlIFZNd2FyZSBoeXBlcnZpc29yLCBhbmQgYSBNSUIgbW9kdWxlIHVzaW5nIHRo ZSBsaWJ2aXJ0DQo+Pj4+PiBwcm9ncmFtbWluZyBpbnRlcmZhY2UgdG8gYWNjZXNzIGRpZmZlcmVu dCBoeXBlcnZpc29ycy4NCj4+Pj4+ICsgSG93ZXZlciwgdGhpcyBNSUIgbW9kdWxlIGF0dGVtcHRz IHRvIGdlbmVyYWxpemUNCj4+Pj4+ICsgdGhlIG1hbmFnZWQgb2JqZWN0cyB0byBzdXBwb3J0IG90 aGVyIGh5cGVydmlzb3JzLg0KPj4+Pj4gDQo+Pj4+PiAqIEFjY29yZGluZyB0byB0aGUgdGhyZWFk IEpvZS0yDQo+Pj4+PiBBZGRlZCBkZXNjcmlwdGlvbiBvZiBhbiBleGFtcGxlIG9mIGh5cGVydmlz b3Itc3BlY2lmaWMgY2FzZQ0KPj4+Pj4gdXNpbmcgRU5USVRZLU1JQiwgYnV0IG5vdCBtb2RpZmll ZCB0aGUgTUlCIGRlZmluaXRpb24uDQo+Pj4+PiANCj4+Pj4+ICogQWNjb3JkaW5nIHRvIHRoZSB0 aHJlYWQgSm9lLTMNCj4+Pj4+IHZtQXV0b1N0YXJ0IC0tPiByZWFkLW9ubHkNCj4+Pj4+IHZtQ3Vy KiAtLT4gcmVhZC13cml0ZQ0KPj4+Pj4gdm0qTWVtIHZtKkNwdSAtLT4gZGVzY3JpcHRpb24gdy8g TVVTVCBOT1Q6ICJDaGFuZ2VzIHRvIHRoZXNlIG9iamVjdHMgTVVTVCBOT1QgcGVyc2lzdCINCj4+ Pj4+IA0KPj4+Pj4gKiBBY2NvcmRpbmcgdG8gdGhlIHRocmVhZCBKb2UtNQ0KPj4+Pj4gRm9yIHRo ZSBuZXR3b3JrIHBvcnRpb24gb2YgdGhlIGh5cGVydmlzb3IsIGFkZGVkIGEgbm90ZSBvbiBhIGNh c2UNCj4+Pj4+IGVxdWlwcGluZyB2aXJ0dWFsIHN3aXRjaGVzIG9uIHRoZSBoeXBlcnZpc29yIGFz IGZvbGxvd3M6DQo+Pj4+PiAgIFRoZSBvYmplY3RzIHJlbGF0ZWQgdG8gdmlydHVhbCBzd2l0Y2hl cw0KPj4+Pj4gICBhcmUgbm90IGFsc28gaW5jbHVkZWQgaW4gdGhpcyBNSUIgbW9kdWxlDQo+Pj4+ PiAgIHRob3VnaCB2aXJ0dWFsIHN3aXRjaGVzIHNoYWxsIGJlIHBsYWNlZCBvbiBhIGh5cGVydmlz b3IuDQo+Pj4+PiAgIFRoaXMgaXMgYmVjYXVzZSB0aGUgdmlydHVhbCBuZXR3b3JrIGludGVyZmFj ZXMgYXJlDQo+Pj4+PiAgIHRoZSBsb3dlc3QgYWJzdHJhY3Rpb24gb2YgbmV0d29yayByZXNvdXJj ZXMgYWxsb2NhdGVkDQo+Pj4+PiAgIHRvIGEgdmlydHVhbCBtYWNoaW5lLg0KPj4+Pj4gICBJbnN0 ZWFkIG9mIGluY2x1ZGluZyB0aGUgb2JqZWN0cyByZWxhdGVkIHRvIHZpcnR1YWwgc3dpdGNoZXMs DQo+Pj4+PiAgIGZvciBleGFtcGxlLCA8eHJlZiB0YXJnZXQ9IlJGQzQxODgiPkJSSURHRS1NSUI8 L3hyZWY+DQo+Pj4+PiAgIGFuZCA8eHJlZiB0YXJnZXQ9IlJGQzQzNjMiPlEtQlJJREdFLU1JQjwv eHJlZj4gY291bGQgYmUgdXNlZC4NCj4+Pj4+IA0KPj4+Pj4gKiBBY2NvcmRpbmcgdG8gdGhlIHRo cmVhZCBKb2UtNw0KPj4+Pj4gQWRkZWQgTm90aWZpY2F0aW9ucyBmb3Igc2h1dHRpbmdEb3duLCBy ZXN1bWluZyBzdXNwZW5kaW5nLCBtaWdyYXRpbmcsIGFuZCBibG9ja2VkDQo+Pj4+PiAjIEkgdGhp bmsgd2Ugc3RpbGwgbmVlZCBkaXNjdXNzaW9uIGF0IHRoaXMgcG9pbnQuDQo+Pj4+PiANCj4+Pj4+ ICogT3RoZXJzDQo+Pj4+PiBNb2RpZmllZCBWaXJ0dWFsTWFjaGluZU9wZXJTdGF0ZSB0byBiZSBt b3JlIGNsZWFyLg0KPj4+Pj4gUmV2aXNlZCB0aGUgZGVzY3JpcHRpb24gb2YgVmlydHVhbE1hY2hp bmUqSW5kZXguDQo+Pj4+PiBGaXhlZCBzb21lIHR5cG9zLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ IEJlc3QgcmVnYXJkcywNCj4+Pj4+IEhpcm9jaGlrYQ0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IEJl Z2luIGZvcndhcmRlZCBtZXNzYWdlOg0KPj4+Pj4gDQo+Pj4+Pj4gRnJvbTogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1hc2FpLXZtbS1taWItMDUudHh0DQo+Pj4+Pj4gRGF0ZTogT2N0b2JlciAxMywgMjAx MyAzOjE5OjE0IFBNIEdNVCswOTowMA0KPj4+Pj4+IFRvOiBZdWppIFNla2l5YSA8c2VraXlhQHdp ZGUuYWQuanA+LCBDYXRoeSBaaG91IDxjYXRoeXpob3VAaHVhd2VpLmNvbT4sIFRpbmEgVHNvdSA8 dGluYS50c291LnpvdXRpbmdAaHVhd2VpLmNvbT4sIEtlaWljaGkgU2hpbWEgPGtlaWljaGlAaWlq bGFiLm5ldD4sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlPiwgTWljaGFlbCBNYWNGYWRlbiA8bXJtQHZtd2FyZS5jb20+LCBIaXJvY2hp a2EgQXNhaSA8cGFuZGFAaG9uZ28ud2lkZS5hZC5qcD4sIEhpcm9zaGkgRXNha2kgPGhpcm9zaGlA d2lkZS5hZC5qcD4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtYXNhaS12bW0tbWliLTA1LnR4dA0KPj4+Pj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgSGlyb2NoaWthIEFzYWkgYW5kIHBvc3RlZCB0byB0aGUNCj4+Pj4+PiBJ RVRGIHJlcG9zaXRvcnkuDQo+Pj4+Pj4gDQo+Pj4+Pj4gRmlsZW5hbWU6ICAgICBkcmFmdC1hc2Fp LXZtbS1taWINCj4+Pj4+PiBSZXZpc2lvbjogICAgIDA1DQo+Pj4+Pj4gVGl0bGU6ICAgICAgICAg TWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlIGZvciBWaXJ0dWFsIE1hY2hpbmVzIENvbnRyb2xs ZWQgYnkgYSBIeXBlcnZpc29yDQo+Pj4+Pj4gQ3JlYXRpb24gZGF0ZTogICAgIDIwMTMtMTAtMTMN Cj4+Pj4+PiBHcm91cDogICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+Pj4+PiBOdW1i ZXIgb2YgcGFnZXM6IDU2DQo+Pj4+Pj4gVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hc2FpLXZtbS1taWItMDUudHh0DQo+Pj4+Pj4gU3Rh dHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFzYWkt dm1tLW1pYg0KPj4+Pj4+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYXNhaS12bW0tbWliLTA1DQo+Pj4+Pj4gRGlmZjogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1hc2FpLXZtbS1taWItMDUNCj4+Pj4+PiAN Cj4+Pj4+PiBBYnN0cmFjdDoNCj4+Pj4+PiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgcG9ydGlv biBvZiB0aGUgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlDQo+Pj4+Pj4gIChNSUIpIGZvciB1 c2Ugd2l0aCBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xzIGluIHRoZSBJbnRlcm5ldA0KPj4+ Pj4+ICBjb21tdW5pdHkuICBJbiBwYXJ0aWN1bGFyLCB0aGlzIHNwZWNpZmllcyBvYmplY3RzIGZv ciBtYW5hZ2luZw0KPj4+Pj4+ICB2aXJ0dWFsIG1hY2hpbmVzIGNvbnRyb2xsZWQgYnkgYSBoeXBl cnZpc29yIChhLmsuYS4gdmlydHVhbCBtYWNoaW5lDQo+Pj4+Pj4gIG1vbml0b3IpLg0KPj4+Pj4+ IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N Cj4+Pj4+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KPj4+Pj4+IA0KPj4+Pj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0 DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiAtLQ0KPj4+PiBK b2UgTWFyY3VzIENsYXJrZSwgQ0NJRSAjNTM4NCwgICAgICAgICB8ICAgICAgICAgIHwNCj4+Pj4g U0NKUCwgU0NTQSwgU0NOQSwgU0NTRUNBLCBWQ1AgICAgICAgIHx8fHx8ICAgICAgfHx8fHwNCj4+ Pj4gRGlzdGluZ3Vpc2hlZCBTZXJ2aWNlcyBFbmdpbmVlciAuLjp8fHx8fHx8fHw6Onx8fHx8fHx8 fDouLg0KPj4+PiBQaG9uZTogKzEgKDkxOSkgMzkyLTI4NjcgICAgICAgICBjIGkgcyBjIG8gIFMg eSBzIHQgZSBtIHMNCj4+Pj4gRW1haWw6IGpjbGFya2VAY2lzY28uY29tDQo+Pj4+IA0KPj4+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+IE9QU0FXRyBtYWlsaW5nIGxpc3QNCj4+Pj4gT1BTQVdHQGll dGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdn DQo+Pj4gDQo+PiANCj4+IA0KPj4gLS0gDQo+PiBKb2UgTWFyY3VzIENsYXJrZSwgQ0NJRSAjNTM4 NCwgICAgICAgICB8ICAgICAgICAgIHwNCj4+IFNDSlAsIFNDU0EsIFNDTkEsIFNDU0VDQSwgVkNQ ICAgICAgICB8fHx8fCAgICAgIHx8fHx8DQo+PiBEaXN0aW5ndWlzaGVkIFNlcnZpY2VzIEVuZ2lu ZWVyIC4uOnx8fHx8fHx8fDo6fHx8fHx8fHx8Oi4uDQo+PiBQaG9uZTogKzEgKDkxOSkgMzkyLTI4 NjcgICAgICAgICBjIGkgcyBjIG8gIFMgeSBzIHQgZSBtIHMNCj4+IEVtYWlsOiBqY2xhcmtlQGNp c2NvLmNvbQ0KPj4gDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPUFNBV0cgbWFpbGluZyBsaXN0 DQo+IE9QU0FXR0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2F3Zw0K From shima@wide.ad.jp Sun Oct 20 05:29:06 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FFF11E83B7 for ; Sun, 20 Oct 2013 05:29:06 -0700 (PDT) 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=[AWL=-0.248, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_BAD_ISO_CHARSET=0.346] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3rVvXI7QLr8 for ; Sun, 20 Oct 2013 05:29:02 -0700 (PDT) Received: from sh.wide.ad.jp (sh.wide.ad.jp [IPv6:2001:200:0:1001::6]) by ietfa.amsl.com (Postfix) with ESMTP id D548F11E83A9 for ; Sun, 20 Oct 2013 05:29:01 -0700 (PDT) Received: from [192.168.10.100] (p110-74-62-228.sub.ne.jp [110.74.62.228]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.21) with ESMTP id r9KCSwvR021305 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Sun, 20 Oct 2013 21:29:00 +0900 (JST) Content-Type: text/plain; charset=iso-2022-cn Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Keiichi SHIMA In-Reply-To: Date: Sun, 20 Oct 2013 21:28:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9348AA62-BD4A-43D0-961E-6901FAB03687@wide.ad.jp> References: <20131013061914.31896.77972.idtracker@ietfa.amsl.com> <126539BC-2994-4DF6-9A5C-E66ED691B24D@hongo.wide.ad.jp> <525D544E.1030507@cisco.com> <4289DA69-E42A-495E-B7B7-E72EA53AD81F@wide.ad.jp> <526034A2.7090801@cisco.com>, <3C61DF63-48C7-42E0-91B2-E6673CCCCD51@wide.ad.jp> To: Tina TSOU X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 12:29:06 -0000 Tina, Thank you for the response. I updated the draft. --- Keiichi SHIMA (=1B$)G=0EU5=0F =0ElcD!=0F) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/10/19, at 0:27, Tina TSOU wrote: > Dear SHIMA-San, > No objection. >=20 > Thank you, > Tina >=20 > On Oct 17, 2013, at 11:34 PM, "Keiichi SHIMA" = wrote: >=20 >> Joe, >>=20 >>> No, TC stays the same, but the tense of the states should change to: >>>=20 >>> unknown(1) >>> enabled(2) >>> disabled(3) >>>=20 >>> Since the associated object is now read-only. >>=20 >> It makes sense. >>=20 >> I'm OK to update the above values. Any objections from other = authors? >>=20 >> --- >> Keiichi SHIMA (=1B$)G=0EU5=0F =0ElcD!=0F) >> WIDE project >> Research Laboratory, IIJ Innovation Institute, Inc = >>=20 >>=20 >>=20 >> On 2013/10/18, at 4:04, Joe Marcus Clarke wrote: >>=20 >>> On 10/17/13 6:55 AM, Keiichi SHIMA wrote: >>>> Hi, >>>>=20 >>>> On 2013/10/15, at 23:42, Joe Marcus Clarke = wrote: >>>>=20 >>>>> NIT: VirtualMachineAdminState: >>>>>=20 >>>>=20 >>>>> The destroy(5) state really doesn't match in terms of tense. What = about destroyed(5)? That said, since this is something one can set, = perhaps present tense like run, pause, suspend, etc. make sense. >>>>=20 >>>> The original intention of the naming of VirtualMachineAdminState = was, 'to transit the operation state of a virtual machine to X by = setting its admin state as X'. For example, when we set 'suspended' to = the admin state of a virtual machine, then the virtual machine will = start transition to the suspended operation state. We intentionally = used the same state names here. That is because the tense is past. >>>>=20 >>>> For the 'destroy' admin state, since we didn't have any operation = state of a destroyed virtual machine (that is same as the shutdown = operation state), we didn't pay any attention to the naming. I can live = with either destroy(5) or destroyed(5). It is a matter of taste to me. >>>=20 >>> I think destroy(5) sounds better, but I'll admit it is a nit. >>>=20 >>>>=20 >>>>=20 >>>>> NIT (maybe a minor issue): VirtualMachineAutoStart: >>>>>=20 >>>>> Again, tense. Here, I think past tense works best since we = decided this would reflect a read-only state. I think enabled and = disabled work best. >>>>=20 >>>> Do you mean changing the name to something like = 'VirtualMachineAutoStartEnabled'? Here again, I don't have any strong = opinion on this. I am open to change the name, if most people agree on = this. >>>=20 >>> No, TC stays the same, but the tense of the states should change to: >>>=20 >>> unknown(1) >>> enabled(2) >>> disabled(3) >>>=20 >>> Since the associated object is now read-only. >>>=20 >>> Joe >>>=20 >>>>=20 >>>> Regards, >>>> --- >>>> Keiichi SHIMA (=1B$)G=0EU5=0F =0ElcD!=0F) >>>> WIDE project >>>> Research Laboratory, IIJ Innovation Institute, Inc = >>>>=20 >>>>=20 >>>>=20 >>>> On 2013/10/15, at 23:42, Joe Marcus Clarke = wrote: >>>>=20 >>>>> On 10/13/13 11:05 PM, Hirochika Asai wrote: >>>>>> Hi folks, >>>>>>=20 >>>>>> Thanks to comments from the mailing list, we've uploaded new = version >>>>>> of our I-D: http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>>>>>=20 >>>>>> We would like to submit our I-D as a working group draft soon and >>>>>> have a discussion in the next IETF as a working group draft. >>>>>> Chairs, could you please poll for adoption as a working group = item >>>>>> on the mailing list? >>>>>>=20 >>>>>> I've already noticed an error: RFC4133 must be RFC6933. Please = let >>>>>> us know if you find any other errors. These errors will be >>>>>> corrected in the next version (the first version for working = group >>>>>> draft if adopted). >>>>>=20 >>>>> Overall, I like the changes. Thanks! >>>>>=20 >>>>> NIT: VirtualMachineAdminState: >>>>>=20 >>>>> The destroy(5) state really doesn't match in terms of tense. What = about destroyed(5)? That said, since this is something one can set, = perhaps present tense like run, pause, suspend, etc. make sense. >>>>>=20 >>>>> Thanks for fleshing out the state definitions :-). >>>>>=20 >>>>> NIT (maybe a minor issue): VirtualMachineAutoStart: >>>>>=20 >>>>> Again, tense. Here, I think past tense works best since we = decided this would reflect a read-only state. I think enabled and = disabled work best. >>>>>=20 >>>>> In terms of the new notifications, why enumerate all states as = notifications? My original comment suggested a single state change = notification where the new and previous state would be available as = objects (note: this would require the definition of a previous state = object). It just seems like the way you've implemented it would be = harder to scale if new states need to be added in the future. >>>>>=20 >>>>> Joe >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Here, I summarize the updates from the previous version. >>>>>>=20 >>>>>> * According to the thread Joe-1 >>>>>> Modified a paragraph as follows: >>>>>>=20 >>>>>> The design of this MIB module has been derived from enterprise >>>>>> specific MIB modules, namely a MIB module for managing guests of = the >>>>>> Xen hypervisor, a MIB module for managing virtual machines = controlled >>>>>> by the VMware hypervisor, and a MIB module using the libvirt >>>>>> programming interface to access different hypervisors. >>>>>> + However, this MIB module attempts to generalize >>>>>> + the managed objects to support other hypervisors. >>>>>>=20 >>>>>> * According to the thread Joe-2 >>>>>> Added description of an example of hypervisor-specific case >>>>>> using ENTITY-MIB, but not modified the MIB definition. >>>>>>=20 >>>>>> * According to the thread Joe-3 >>>>>> vmAutoStart --> read-only >>>>>> vmCur* --> read-write >>>>>> vm*Mem vm*Cpu --> description w/ MUST NOT: "Changes to these = objects MUST NOT persist" >>>>>>=20 >>>>>> * According to the thread Joe-5 >>>>>> For the network portion of the hypervisor, added a note on a case >>>>>> equipping virtual switches on the hypervisor as follows: >>>>>> The objects related to virtual switches >>>>>> are not also included in this MIB module >>>>>> though virtual switches shall be placed on a hypervisor. >>>>>> This is because the virtual network interfaces are >>>>>> the lowest abstraction of network resources allocated >>>>>> to a virtual machine. >>>>>> Instead of including the objects related to virtual switches, >>>>>> for example, BRIDGE-MIB >>>>>> and Q-BRIDGE-MIB could be used. >>>>>>=20 >>>>>> * According to the thread Joe-7 >>>>>> Added Notifications for shuttingDown, resuming suspending, = migrating, and blocked >>>>>> # I think we still need discussion at this point. >>>>>>=20 >>>>>> * Others >>>>>> Modified VirtualMachineOperState to be more clear. >>>>>> Revised the description of VirtualMachine*Index. >>>>>> Fixed some typos. >>>>>>=20 >>>>>>=20 >>>>>> Best regards, >>>>>> Hirochika >>>>>>=20 >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Subject: New Version Notification for draft-asai-vmm-mib-05.txt >>>>>>> Date: October 13, 2013 3:19:14 PM GMT+09:00 >>>>>>> To: Yuji Sekiya , Cathy Zhou = , Tina Tsou , = Keiichi Shima , Juergen Schoenwaelder = , Michael MacFaden = , Hirochika Asai , Hiroshi Esaki = >>>>>>>=20 >>>>>>>=20 >>>>>>> A new version of I-D, draft-asai-vmm-mib-05.txt >>>>>>> has been successfully submitted by Hirochika Asai and posted to = the >>>>>>> IETF repository. >>>>>>>=20 >>>>>>> Filename: draft-asai-vmm-mib >>>>>>> Revision: 05 >>>>>>> Title: Management Information Base for Virtual Machines = Controlled by a Hypervisor >>>>>>> Creation date: 2013-10-13 >>>>>>> Group: Individual Submission >>>>>>> Number of pages: 56 >>>>>>> URL: = http://www.ietf.org/internet-drafts/draft-asai-vmm-mib-05.txt >>>>>>> Status: = http://datatracker.ietf.org/doc/draft-asai-vmm-mib >>>>>>> Htmlized: = http://tools.ietf.org/html/draft-asai-vmm-mib-05 >>>>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-asai-vmm-mib-05 >>>>>>>=20 >>>>>>> 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). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Please note that it may take a couple of minutes from the time = of submission >>>>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Joe Marcus Clarke, CCIE #5384, | | >>>>> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >>>>> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >>>>> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >>>>> Email: jclarke@cisco.com >>>>>=20 >>>>> = --------------------------------------------------------------------------= -- >>>>> _______________________________________________ >>>>> OPSAWG mailing list >>>>> OPSAWG@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/opsawg >>>>=20 >>>=20 >>>=20 >>> --=20 >>> Joe Marcus Clarke, CCIE #5384, | | >>> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >>> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >>> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >>> Email: jclarke@cisco.com >>>=20 >>> = --------------------------------------------------------------------------= -- >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg From dromasca@avaya.com Mon Oct 21 06:48:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A45E11E8520 for ; Mon, 21 Oct 2013 06:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.264 X-Spam-Level: X-Spam-Status: No, score=-103.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bxt4-wHuJjx2 for ; Mon, 21 Oct 2013 06:48:13 -0700 (PDT) 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 8A4D211E8522 for ; Mon, 21 Oct 2013 06:48:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwGACswZVLGmAcV/2dsb2JhbABZgmYhgQy+L4EsFm0HgicBAQMSKDEgARUVFEImAQQbEweHZAGaPIRInGKPK4NXgQoDlCqKQYslgySCKg X-IronPort-AV: E=Sophos;i="4.93,539,1378872000"; d="scan'208";a="28473187" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Oct 2013 09:47:58 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Oct 2013 09:43:21 -0400 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.0146.000; Mon, 21 Oct 2013 15:47:56 +0200 From: "Romascanu, Dan (Dan)" To: "opsawg@ietf.org" Thread-Topic: my comments on draft-ietf-opsawg-capwap-hybridmac-01 Thread-Index: Ac7OZCWF2Ot+MGKOSzSSM8oCUrHY9Q== Date: Mon, 21 Oct 2013 13:47:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129116B2@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSAWG] my comments on draft-ietf-opsawg-capwap-hybridmac-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:48:21 -0000 Hi,=20 I have read draft-ietf-opsawg-capwap-hybridmac-01.txt. I believe that the d= ocument is on the right track, the solution is clear and makes sense. There= are however a number of functional and editorial improvements that should = improve the clarity of the document.=20 1. The interaction between the AC and WTP which is introduced for the Hybr= id-MAC model Frames Exchange needs to be better clarified. If I understand = well the WTP communicates to the AC the list of profile it supports, and th= e AC selects one to configure the WTP. This exchange of information takes p= lace in the Discovery Request message, Primary Discovery Request message, a= nd Join Request message as per section 4, but it is not clear what is the o= rder. It is also not clear whether an AC can support more than one profile.= =20 2. The IANA policy of Expert Review suggested to manage the profile space s= eems too 'liberal'. Adding a new profile actually defines a new class of de= vice, possibly with new functionality, or with functionality distributed di= fferently between the WTPs and ACs. As with this document, I believe that n= ew profiles should be defined in Standards Track documents. 'Standards Acti= on' or at least 'IETF Review' (as per RFC 5226) seem to be the appropriate = policies.=20 3. (editorial) This document uses -- a lot -- of terms from RFC 5415 and RF= C 5416. I suggest to have a short section of Terminology and Abbreviations = that reminds the principal terms and acronyms re-used. This section can be = shared with draft-ietf-opsawg-capwap-extension 4. (editorial) Acronyms should be avoided in the Abstract. In general I thi= nk that a shortest and more 'high level' abstract is needed.=20 Regards, Dan =20 From rpazhyan@cisco.com Mon Oct 21 09:55:14 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7065911E869D for ; Mon, 21 Oct 2013 09:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhQoErD1JsRY for ; Mon, 21 Oct 2013 09:55:05 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7009E11E86A6 for ; Mon, 21 Oct 2013 09:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8337; q=dns/txt; s=iport; t=1382374473; x=1383584073; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1qvTct4Ktqhy7PM+d/ZL4f43hr6daSocDFxlWFwSsZU=; b=QS0xCGhBfzjyLjJSUZ5xM6f7GBvDM6BHaxVUWmCecKurDOJ24qSle57R ezgZAPIyB70Y+7dAPInrDtZXCYya0Ur2F8ypAoTM6xufnXc6Dyg8ZGUVl DaHHrw0dhsSCwMp8iU/qH10RQPtq5FpjNTwqg+Y8kKIpVM6ea1a1R1rtD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAAZbZVKtJV2a/2dsb2JhbABZgkNEOFS9ZEuBLhZ0giUBAQEDAQEBASo+AxAHBAIBCBEEAQELHQcnCxQJCAEBBAESCBOHZQYNuX0EjystCwaDGYEKA5QqlWaDJIIq X-IronPort-AV: E=Sophos;i="4.93,540,1378857600"; d="scan'208,217";a="274777853" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 21 Oct 2013 16:54:30 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9LGsUoK014194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 16:54:30 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.202]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 11:54:29 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" Thread-Topic: my comments on draft-ietf-opsawg-capwap-hybridmac-01 Thread-Index: Ac7OZCWF2Ot+MGKOSzSSM8oCUrHY9QAGNrkw Date: Mon, 21 Oct 2013 16:54:29 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320ECD155@xmb-aln-x09.cisco.com> References: <9904FB1B0159DA42B0B887B7FA8119CA129116B2@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129116B2@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.139.19] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320ECD155xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: Re: [OPSAWG] my comments on draft-ietf-opsawg-capwap-hybridmac-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 16:55:14 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320ECD155xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan Thanks for the comments. Appreciate the review. Some follow up comments and questions. Regards Rajesh -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Romascanu, Dan (Dan) Sent: Monday, October 21, 2013 6:48 AM To: opsawg@ietf.org Subject: [OPSAWG] my comments on draft-ietf-opsawg-capwap-hybridmac-01 Hi, I have read draft-ietf-opsawg-capwap-hybridmac-01.txt. I believe that the d= ocument is on the right track, the solution is clear and makes sense. There= are however a number of functional and editorial improvements that should = improve the clarity of the document. 1. The interaction between the AC and WTP which is introduced for the Hybr= id-MAC model Frames Exchange needs to be better clarified. If I understand = well the WTP communicates to the AC the list of profile it supports, and th= e AC selects one to configure the WTP. This exchange of information takes p= lace in the Discovery Request message, Primary Discovery Request message, a= nd Join Request message as per section 4, but it is not clear what is the o= rder. It is also not clear whether an AC can support more than one profile. > Yes. Agree. We will incorporate a sequence diagram that indicates the or= der. > The intent is that the WTP capability is indicated in one of the followin= g: Discovery/Primary Discovery/Join. > The AC and WTPs may support multiple profiles (and the AC may select a pr= ofile while configuring the WLAN) 2. The IANA policy of Expert Review suggested to manage the profile space s= eems too 'liberal'. Adding a new profile actually defines a new class of de= vice, possibly with new functionality, or with functionality distributed di= fferently between the WTPs and ACs. As with this document, I believe that n= ew profiles should be defined in Standards Track documents. 'Standards Acti= on' or at least 'IETF Review' (as per RFC 5226) seem to be the appropriate = policies. > I am not completely sure what you are recommending. This may be mai= nly because of lack of experience with this matter but am seeking further g= uidance on this matter. 3. (editorial) This document uses -- a lot -- of terms from RFC 5415 and RF= C 5416. I suggest to have a short section of Terminology and Abbreviations = that reminds the principal terms and acronyms re-used. This section can be = shared with draft-ietf-opsawg-capwap-extension > Yes, noted. Will incorporate in the next version. 4. (editorial) Acronyms should be avoided in the Abstract. In general I thi= nk that a shortest and more 'high level' abstract is needed. > Yes, noted. Will incorporate in the next version. Regards, Dan _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_4ED2E36A22261145861BAB2C24088B4320ECD155xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dan
 
Thanks for the comments. Appreciate the review= .
Some follow up comments and questions.<= /div>
 
Regards
 
Rajesh
-----Original Message-----
From: opsawg-bounces@ietf.org [m= ailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, October 21, 2013 6:48 AM
To: opsawg@ietf.org
Subject: [OPSAWG] my comments on draft-ietf-opsawg-capwap-hybridmac-01
 
Hi,
 
I have read draft-ietf-opsawg-capwap-hybridmac-01.txt. I believe that = the document is on the right track, the solution is clear and makes sense. = There are however a number of functional and editorial improvements that sh= ould improve the clarity of the document.
 
1. The interaction between the AC and WTP which is introduced for the&= nbsp; Hybrid-MAC model Frames Exchange needs to be better clarified. If I u= nderstand well the WTP communicates to the AC the list of profile it suppor= ts, and the AC selects one to configure the WTP. This exchange of information takes place in the Discovery Request = message, Primary Discovery Request message, and Join Request message as per= section 4, but it is not clear what is the order. It is also not clear whe= ther an AC can support more than one profile.
 
> Yes. Agree. We will incorporate a sequen= ce diagram that indicates the order. 
> The intent is that the WTP capability is = indicated in one of the following: Discovery/Primary Discovery/Join.=
> The AC and WTPs may support multiple prof= iles (and the AC may select a profile while configuring the WLAN)
 
2. The IANA policy of Expert Review suggested to manage the profile sp= ace seems too 'liberal'. Adding a new profile actually defines a new class = of device, possibly with new functionality, or with functionality distribut= ed differently between the WTPs and ACs. As with this document, I believe that new profiles should be defin= ed in Standards Track documents. 'Standards Action' or at least 'IETF Revie= w' (as per RFC 5226) seem to be the appropriate policies.
 
  • I am not completely sure what you are recommending. This may be mainly = because of lack of experience with this matter but am seeking further guida= nce on this matter.
    •
 
3. (editorial) This document uses -- a lot -- of terms from RFC 5415 a= nd RFC 5416. I suggest to have a short section of Terminology and Abbreviat= ions that reminds the principal terms and acronyms re-used. This section ca= n be shared with draft-ietf-opsawg-capwap-extension
 
> Yes, noted. Will incorporate in the next = version.
4. (editorial) Acronyms should be avoided in the Abstract. In general = I think that a shortest and more 'high level' abstract is needed.
 
  • Yes, noted. Will incorporate in the next version.
    •
Regards,
 
Dan
 
 
 
 
_______________________________________________
OPSAWG mailing list
 
--_000_4ED2E36A22261145861BAB2C24088B4320ECD155xmbalnx09ciscoc_-- From internet-drafts@ietf.org Mon Oct 21 10:32:42 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0309611E86C9; Mon, 21 Oct 2013 10:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfX9w4B5egQ7; Mon, 21 Oct 2013 10:32:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C0C11E85C8; Mon, 21 Oct 2013 10:32:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021173241.32495.25783.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 10:32:41 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-extension-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:32:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : CAPWAP Extension for 802.11n and Power/channel Reconfigu= ration Author(s) : Yifan Chen Dapeng Liu Hui Deng Lei Zhu Filename : draft-ietf-opsawg-capwap-extension-01.txt Pages : 14 Date : 2013-10-21 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 was several new amendment of 802.11 has been published. 802.11n is one of those amendment 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-capwap-extension-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 internet-drafts@ietf.org Mon Oct 21 10:42:25 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D367D11E821E; Mon, 21 Oct 2013 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzSoEl4kBEyw; Mon, 21 Oct 2013 10:42:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2332911E819C; Mon, 21 Oct 2013 10:42:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021174223.32495.88107.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 10:42:23 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-oam-overview-10.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:42:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : An Overview of Operations, Administration, and Maintenan= ce (OAM) Data Plane Tools Author(s) : Tal Mizrahi Nurit Sprecher Elisa Bellagamba Yaacov Weingarten Filename : draft-ietf-opsawg-oam-overview-10.txt Pages : 47 Date : 2013-10-21 Abstract: Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the data plane OAM tools defined in the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for the transport profile (MPLS-TP), and TRILL. 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 data plane OAM tools defined in the IETF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-oam-overview-10 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 mehmet.ersue@nsn.com Mon Oct 21 12:52:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DF611E8705 for ; Mon, 21 Oct 2013 12:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.103 X-Spam-Level: X-Spam-Status: No, score=-106.103 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVbx0ti1QCws for ; Mon, 21 Oct 2013 12:52:23 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A140B11E8724 for ; Mon, 21 Oct 2013 12:49:39 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r9LJnTtW026715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Oct 2013 21:49:29 +0200 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r9LJnTCG025945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 21:49:29 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.164]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Mon, 21 Oct 2013 21:49:29 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "opsawg@ietf.org" Thread-Topic: draft-opsawg-ersue-coman-*-00 Thread-Index: Ac7OlqYtF57/mMmbQ2uDVQpY5NHw2Q== Date: Mon, 21 Oct 2013 19:49:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.95] Content-Type: multipart/mixed; boundary="_005_E4DE949E6CE3E34993A2FF8AE79131F81CF5A0DEMUMBX005nsnintr_" 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: 13557 X-purgate-ID: 151667::1382384970-00004A43-A1CD9661/0-0/0-0 Cc: "ops-chairs@tools.ietf.org" Subject: [OPSAWG] draft-opsawg-ersue-coman-*-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:52:27 -0000 --_005_E4DE949E6CE3E34993A2FF8AE79131F81CF5A0DEMUMBX005nsnintr_ Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81CF5A0DEMUMBX005nsnintr_" --_000_E4DE949E6CE3E34993A2FF8AE79131F81CF5A0DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, we submitted following two drafts by dividing the original Coman draft draf= t-ersue-constrained-mgmt-03 into two parts: Filename: draft-opsawg-ersue-coman-probstate-reqs Title: Management of Networks with Constrained Devices: Problem S= tatement and Requirements Htmlized: http://tools.ietf.org/html/draft-opsawg-ersue-coman-probst= ate-reqs-00 Filename: draft-opsawg-ersue-coman-use-cases Title: Management of Networks with Constrained Devices: Use Cases Htmlized: http://tools.ietf.org/html/draft-opsawg-ersue-coman-use-cas= es-00 We also asked OPSAWG chairs for a time slot to introduce the drafts and dis= cuss issues. We would appreciate your comments and a discussion on these drafts. Please send your comments to the OPSAWG maillist. Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F81CF5A0DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
we submitted following two drafts by dividing the original Coman draft= draft-ersue-constrained-mgmt-03 into two parts:
&nbs= p;
Filename:        draft-opsawg-ersue= -coman-probstate-reqs
Title:           Man= agement of Networks with Constrained Devices: Problem Statement and Require= ments
&nbs= p;
Filename:        draft-opsawg-ersue= -coman-use-cases
Title:           Man= agement of Networks with Constrained Devices: Use Cases
&nbs= p;
We also asked OPSAWG chairs for a time slot to introduce the drafts an= d discuss issues.
 
We would appreciate your comments and a discussion on these drafts.
Please send your comments to the OPSAWG maillist.
&nbs= p;
Regards,
Mehmet
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F81CF5A0DEMUMBX005nsnintr_-- --_005_E4DE949E6CE3E34993A2FF8AE79131F81CF5A0DEMUMBX005nsnintr_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Mon, 21 Oct 2013 19:49:27 GMT"; modification-date="Mon, 21 Oct 2013 19:49:27 GMT" Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC007.nsn-intra.net (10.159.42.38) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 21 Oct 2013 20:54:17 +0200 Received: from demuprx016.emea.nsn-intra.net (10.159.42.124) by DEMUHTC006.nsn-intra.net (10.159.42.37) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 21 Oct 2013 20:54:16 +0200 Received: from mumrelp001.nsn-inter.net (mumrelp001.nsn-inter.net [93.183.13.135]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r9LIsGLt013181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Oct 2013 20:54:16 +0200 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mumrelp001.nsn-inter.net (8.13.8/8.13.8) with ESMTP id r9LIsGtO015396 for ; Mon, 21 Oct 2013 20:54:16 +0200 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EAB11E8238; Mon, 21 Oct 2013 11:54:15 -0700 (PDT) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF1g3msh2mBQ; Mon, 21 Oct 2013 11:54:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DFD11E840D; Mon, 21 Oct 2013 11:54:08 -0700 (PDT) From: "ext internet-drafts@ietf.org" To: Dan Romascanu , Juergen Schoenwaelder , "Ersue, Mehmet (NSN - DE/Munich)" Subject: New Version Notification for draft-opsawg-ersue-coman-probstate-reqs-00.txt Thread-Topic: New Version Notification for draft-opsawg-ersue-coman-probstate-reqs-00.txt Thread-Index: AQHOzo7xgMDHISK6VE++bt9ABi2s3Q== Date: Mon, 21 Oct 2013 18:54:08 +0000 Message-ID: <20131021185408.32548.16277.idtracker@ietfa.amsl.com> Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: DEMUHTC006.nsn-intra.net X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-purgate-id: 151667::1382381656-00005789-530842F7/0-0/0-0 x-purgate-ad: Categorized by eleven eXpurgate (R) http://www.eleven.de x-purgate: This mail is considered clean (visit http://www.eleven.de for further information) x-purgate-size: 1175 x-purgate-type: clean x-virus-scanned: amavisd-new at amsl.com auto-submitted: auto-generated x-scanned-by: MIMEDefang 2.71 on 93.183.13.135 Content-Type: text/plain; charset="utf-8" Content-ID: <3F5AC62326FFE44697C3BD694A3B2368@internal.nsn.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtb3BzYXdnLWVyc3VlLWNvbWFuLXByb2JzdGF0 ZS1yZXFzLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNZWhtZXQg RXJzdWUgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAg ICAgICBkcmFmdC1vcHNhd2ctZXJzdWUtY29tYW4tcHJvYnN0YXRlLXJlcXMNClJldmlzaW9uOiAg ICAgICAgMDANClRpdGxlOiAgICAgICAgICAgTWFuYWdlbWVudCBvZiBOZXR3b3JrcyB3aXRoIENv bnN0cmFpbmVkIERldmljZXM6IFByb2JsZW0gU3RhdGVtZW50IGFuZCBSZXF1aXJlbWVudHMNCkNy ZWF0aW9uIGRhdGU6ICAgMjAxMy0xMC0yMQ0KR3JvdXA6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNTYNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtb3BzYXdnLWVyc3VlLWNvbWFuLXByb2Jz dGF0ZS1yZXFzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LW9wc2F3Zy1lcnN1ZS1jb21hbi1wcm9ic3RhdGUtcmVxcw0KSHRtbGl6 ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vcHNhd2ctZXJzdWUt Y29tYW4tcHJvYnN0YXRlLXJlcXMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQg cHJvdmlkZXMgYSBwcm9ibGVtIHN0YXRlbWVudCwgZGVwbG95bWVudCBhbmQgbWFuYWdlbWVudA0K ICAgdG9wb2xvZ3kgb3B0aW9ucyBhcyB3ZWxsIGFzIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBt YW5hZ2VtZW50IG9mDQogICBuZXR3b3JrcyB3aGVyZSBjb25zdHJhaW5lZCBkZXZpY2VzIGFyZSBp bnZvbHZlZC4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K --_005_E4DE949E6CE3E34993A2FF8AE79131F81CF5A0DEMUMBX005nsnintr_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Mon, 21 Oct 2013 19:49:28 GMT"; modification-date="Mon, 21 Oct 2013 19:49:28 GMT" Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC007.nsn-intra.net (10.159.42.38) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 21 Oct 2013 20:55:41 +0200 Received: from demuprx017.emea.nsn-intra.net (10.159.42.97) by DEMUHTC010.nsn-intra.net (10.159.42.41) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 21 Oct 2013 20:55:41 +0200 Received: from demumfd002.nsn-inter.net (DEMUMFD002 [93.183.12.31]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r9LItfsZ005813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Oct 2013 20:55:41 +0200 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r9LIteO0003660 for ; Mon, 21 Oct 2013 20:55:40 +0200 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0974D11E861C; Mon, 21 Oct 2013 11:55:40 -0700 (PDT) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wovqHH-a08U9; Mon, 21 Oct 2013 11:55:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD7F11E856E; Mon, 21 Oct 2013 11:55:10 -0700 (PDT) From: "ext internet-drafts@ietf.org" To: Dan Romascanu , Juergen Schoenwaelder , "Ersue, Mehmet (NSN - DE/Munich)" Subject: New Version Notification for draft-opsawg-ersue-coman-use-cases-00.txt Thread-Topic: New Version Notification for draft-opsawg-ersue-coman-use-cases-00.txt Thread-Index: AQHOzo8jFGmhc5H0FkCR10dedIYG3Q== Date: Mon, 21 Oct 2013 18:55:10 +0000 Message-ID: <20131021185510.32482.68231.idtracker@ietfa.amsl.com> Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: DEMUHTC010.nsn-intra.net X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-purgate-id: 151667::1382381741-00005753-F1DC8E4D/0-0/0-0 x-purgate-ad: Categorized by eleven eXpurgate (R) http://www.eleven.de x-purgate: This mail is considered clean (visit http://www.eleven.de for further information) x-purgate-size: 1215 x-purgate-type: clean x-virus-scanned: amavisd-new at amsl.com auto-submitted: auto-generated Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtb3BzYXdnLWVyc3VlLWNvbWFuLXVzZS1jYXNl cy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWVobWV0IEVyc3Vl IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAg ZHJhZnQtb3BzYXdnLWVyc3VlLWNvbWFuLXVzZS1jYXNlcw0KUmV2aXNpb246ICAgICAgICAwMA0K VGl0bGU6ICAgICAgICAgICBNYW5hZ2VtZW50IG9mIE5ldHdvcmtzIHdpdGggQ29uc3RyYWluZWQg RGV2aWNlczogVXNlIENhc2VzDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTMtMTAtMjENCkdyb3VwOiAg ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDMzDQpVUkw6 ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW9w c2F3Zy1lcnN1ZS1jb21hbi11c2UtY2FzZXMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtb3BzYXdnLWVyc3VlLWNvbWFuLXVzZS1j YXNlcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1v cHNhd2ctZXJzdWUtY29tYW4tdXNlLWNhc2VzLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRv Y3VtZW50IGRpc2N1c3NlcyB0aGUgdXNlIGNhc2VzIGNvbmNlcm5pbmcgdGhlIG1hbmFnZW1lbnQg b2YNCiAgIG5ldHdvcmtzLCB3aGVyZSBjb25zdHJhaW5lZCBkZXZpY2VzIGFyZSBpbnZvbHZlZC4g IEEgcHJvYmxlbQ0KICAgc3RhdGVtZW50LCBkZXBsb3ltZW50IG9wdGlvbnMgYW5kIHRoZSByZXF1 aXJlbWVudHMgb24gdGhlIG5ldHdvcmtzDQogICB3aXRoIGNvbnN0cmFpbmVkIGRldmljZXMgY2Fu IGJlIGZvdW5kIGluIHRoZSBjb21wYW5pb24gZG9jdW1lbnQgW0NPTS0NCiAgIFJFUV0uDQoNCg0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg== --_005_E4DE949E6CE3E34993A2FF8AE79131F81CF5A0DEMUMBX005nsnintr_-- From talmi@marvell.com Wed Oct 23 08:55:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB3511E83AB for ; Wed, 23 Oct 2013 08:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOt-Prmr0ieW for ; Wed, 23 Oct 2013 08:55:30 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 69CBD11E8369 for ; Wed, 23 Oct 2013 08:55:27 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r9NFtPbB006363; Wed, 23 Oct 2013 08:55:26 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1fpb629qqe-12 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Oct 2013 08:55:26 -0700 Received: from YK-HUB01.marvell.com (10.4.102.51) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 23 Oct 2013 08:55:15 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB01.marvell.com ([10.4.102.51]) with mapi; Wed, 23 Oct 2013 17:55:11 +0200 From: Tal Mizrahi To: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" , "draft-ietf-opsawg-oam-overview@tools.ietf.org" Date: Wed, 23 Oct 2013 18:55:06 +0200 Thread-Topic: Updated draft-ietf-opsawg-oam-overview-10 Thread-Index: Ac7QCBPXM7/vjWUjRf+fSKRq1SubJw== Message-ID: <74470498B659FA4687F0B0018C19A89C01B87D7A485A@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01B87D7A485AILMB01marve_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-23_04:2013-10-23, 2013-10-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310230060 Subject: [OPSAWG] Updated draft-ietf-opsawg-oam-overview-10 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:55:35 -0000 --_000_74470498B659FA4687F0B0018C19A89C01B87D7A485AILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have uploaded an updated draft. http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-10 This document has been around for a while now (4 years), and over this long= period we have receive a very large number of comments from many reviewers= . We would like to thank everyone who has reviewed and sent comments, which= have significantly helped us to improve the document. We, the authors, believe that we have addressed all the comments we receive= d, and that this document is finally ready for WG last call. As advised by our AD, Benoit Claise, we would like to get feedback about wh= ether we have indeed addressed the concerns that were raised, and whether t= his document is ready to go. Main changes compared to prev draft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The main changes compared to the previous draft are: - Various terminology fixes following comments we received from Stewart Br= yant and Benoit Claise. - We have added a subsection about connection oriented vs. connectionless = communication, as well as a subsection about point-to-point vs. point-to-mu= ltipoint communication. A (not so short) history of this draft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - October 2009 draft-mizrahi-opsawg-oam-overview was submitted as an independent submission. - December 2009 draft-mizrahi-opsawg-oam-overview became a WG document - July 2010 draft-sprecher-mpls-tp-oam-primer was submitted as an independent submission. - July 2010 draft-ietf-opsawg-oam-overview was presented in IETF 78. Loa Andersson commented that this draft overlaps with draft-sprecher-mpls-tp-oam-primer, and suggested to merge t= hem. - October 2010 The two drafts were merged into draft-ietf-opsawg-oam-overv= iew. - March 2011 The draft went into WG last call. - August 2011 The draft went through IESG review. After a short iterative process most of the comments were addressed, except a singl= e (but significant) DISCUSS by the routing area AD, which included a large number of comments. - March 2012 The draft was significantly revised to address the comments from the pending DISCUSS. - Sep 2012 The updated version was not reviewed by the IESG on time. The IESG has a 1-year-timeout for drafts in the IESG proces= s, and hence the draft went back to the WG. - Dec 2012 The draft passed WG last call (again). - Jan 2013 IETF last call: the draft received comments from ~10 review= ers, including significant comments from the routing area review= ers. - Jun 2013 Ops AD, Benoit Claise, returned the document to the WG following the large number of comments. - Jul 2013 The draft was significantly revised to address the comments= in IETF last call, and especially the ones by the routing area reviewers. - Oct 2013 The draft was revised to address additional comments by the Ops area AD and the routing area AD. Any feedback would be welcome. Thanks, Tal. --_000_74470498B659FA4687F0B0018C19A89C01B87D7A485AILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have uploaded an = updated draft.

http://tools.ietf.org/html/draft-ietf-opsawg-oam-over= view-10

 

This document has been around for a wh= ile now (4 years), and over this long period we have receive a very large n= umber of comments from many reviewers. We would like to thank everyone who = has reviewed and sent comments, which have significantly helped us to impro= ve the document.

 

= We, the authors, believe that we = have addressed all the comments we received, and that this document is fina= lly ready for WG last call.

 

As advised by our AD= , Benoit Claise, we would like to get feedback about whether we have indeed= addressed the concerns that were raised, and whether this document is read= y to go.

 

 

Main changes compared to = prev draft

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The main c= hanges compared to the previous draft are:

-  Various term= inology fixes following comments we received from Stewart Bryant and Benoit= Claise.

-  We have added a subsection about connection orien= ted vs. connectionless communication, as well as a subsection about point-t= o-point vs. point-to-multipoint communication.

 

 

A (not so short) history of this draft

~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~

- October 2009  draft-mizrahi-opsawg= -oam-overview was submitted as

<= span style=3D'font-family:"Courier New"'>     &nbs= p;          an independen= t submission.

- December 2009 draft-mizrahi-opsawg-oam-overview be= came a WG document

- July 2010     draft-sprec= her-mpls-tp-oam-primer was submitted as

    &= nbsp;           an i= ndependent submission.

- July 2010     draft-i= etf-opsawg-oam-overview was presented in IETF 78.

  &nb= sp;            =  Loa Andersson commented that this draft overlaps with

 = ;            &n= bsp;  draft-sprecher-mpls-tp-oam-primer, and suggested to merge t= hem.

- October 2010  The two drafts were merged into draft-ie= tf-opsawg-oam-overview.

- March 2011    The draft w= ent into WG last call.

- August 2011   The draft went th= rough IESG review. After a short iterative

   &n= bsp;            = ;process most of the comments were addressed, except a single

&nb= sp;            =    (but significant) DISCUSS by the routing area AD, which <= o:p>

           =      included a large number of comments.

        = ;        from the pending DISCUSS.<= o:p>

- Sep 2012      The updated version was n= ot reviewed by the IESG on time.

     &n= bsp;          The IESG ha= s a 1-year-timeout for drafts in the IESG process,

  &n= bsp;            = ; and hence the draft went back to the WG.

- Dec 2012 &n= bsp;    The draft passed WG last call (again).

- Ja= n 2013      IETF last call: the draft received com= ments from ~10 reviewers,

      &nbs= p;         including significant co= mments from the routing area reviewers.

- Jun 2013  &nbs= p;   Ops AD, Benoit Claise, returned the document to the WG =

           &nbs= p;    following the large number of comments.

= - Jul 2013      The draft was significantly revise= d to address the comments in

      =           IETF last call,= and especially the ones by the routing area

   &n= bsp;            = ;reviewers.

- Oct 2013      The draft was= revised to address additional comments by the

   =             &nb= sp;Ops area AD and the routing area AD.

&nb= sp;

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>Any feedback woul= d be welcome.

 

Th= anks,

Tal.

 

<= /div>= --_000_74470498B659FA4687F0B0018C19A89C01B87D7A485AILMB01marve_-- From dromasca@avaya.com Wed Oct 23 14:10:10 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F1111E8205 for ; Wed, 23 Oct 2013 14:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.304 X-Spam-Level: X-Spam-Status: No, score=-103.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-W0a7ec3BK8 for ; Wed, 23 Oct 2013 14:10:03 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9779F11E8122 for ; Wed, 23 Oct 2013 14:10:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAEQ6aFKHCzI1/2dsb2JhbABZgkMjIThUvleBLhZ0giUBAQEBAxIbPh4CAQgNCA0dBzIUEQEBBAESCBqHZAGeNp0Tjx03AYMfgQsDnmuLJYMkgio X-IronPort-AV: E=Sophos;i="4.93,557,1378872000"; d="scan'208,217";a="33320054" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Oct 2013 17:10:02 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Oct 2013 17:00:34 -0400 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.0146.000; Wed, 23 Oct 2013 23:10:00 +0200 From: "Romascanu, Dan (Dan)" To: "Rajesh Pazhyannur (rpazhyan)" , "opsawg@ietf.org" Thread-Topic: my comments on draft-ietf-opsawg-capwap-hybridmac-01 Thread-Index: Ac7OZCWF2Ot+MGKOSzSSM8oCUrHY9QAGNrkwAG21PtA= Date: Wed, 23 Oct 2013 21:10:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12914365@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA129116B2@AZ-FFEXMB04.global.avaya.com> <4ED2E36A22261145861BAB2C24088B4320ECD155@xmb-aln-x09.cisco.com> In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320ECD155@xmb-aln-x09.cisco.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_9904FB1B0159DA42B0B887B7FA8119CA12914365AZFFEXMB04globa_" MIME-Version: 1.0 Subject: Re: [OPSAWG] my comments on draft-ietf-opsawg-capwap-hybridmac-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 21:10:10 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA12914365AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Rajesh Pazhyannur (rpazhyan) [mailto:rpazhyan@cisco.com] 2. The IANA policy of Expert Review suggested to manage the profile space s= eems too 'liberal'. Adding a new profile actually defines a new class of de= vice, possibly with new functionality, or with functionality distributed di= fferently between the WTPs and ACs. As with this document, I believe that n= ew profiles should be defined in Standards Track documents. 'Standards Acti= on' or at least 'IETF Review' (as per RFC 5226) seem to be the appropriate = policies. * I am not completely sure what you are recommending. This may be m= ainly because of lack of experience with this matter but am seeking further= guidance on this matter. Hi, I suggest that you read RFC 5226. My proposal is to define 'Standards Actio= n' or at least 'IETF Review' as recommended policies for the profile regist= ry. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA12914365AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

 <= /p>

 <= /p>

From: Rajesh Pazhyannur (rpazhyan) [mailto:rpazhyan@cisco.co= m]

2. The IANA policy of Expert Review sug= gested to manage the profile space seems too 'liberal'. Adding a new profil= e actually defines a new class of device, possibly with new functionality, or with functionality distributed differently between t= he WTPs and ACs. As with this document, I believe that new profiles should = be defined in Standards Track documents. 'Standards Action' or at least 'IE= TF Review' (as per RFC 5226) seem to be the appropriate policies.

 

·       &= nbsp; I am not completely sure what you are recommending. This may be mai= nly because of lack of experience with this matter but am seeking further guidance on this matter.

 

Hi,

 

I suggest that you = read RFC 5226. My proposal is to define ‘Standards Action’ or a= t least ‘IETF Review’ as recommended policies for the profile r= egistry.

 

Regards,=

 

Dan

--_000_9904FB1B0159DA42B0B887B7FA8119CA12914365AZFFEXMB04globa_-- From leo.liubing@huawei.com Wed Oct 23 19:44:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD4A11E829C for ; Wed, 23 Oct 2013 19:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45EuQSxTtcBG for ; Wed, 23 Oct 2013 19:44:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 23A3A11E822F for ; Wed, 23 Oct 2013 19:44:22 -0700 (PDT) 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 AZK19585; Thu, 24 Oct 2013 02:44:10 +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; Thu, 24 Oct 2013 03:44:07 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 03:44:10 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Thu, 24 Oct 2013 10:44:05 +0800 From: "Liubing (Leo)" To: "opsawg@ietf.org" Thread-Topic: Soliciting comments on draft-liu-running-multiple-prefixes-01 Thread-Index: Ac7QYuTPryzwQLYDQKO/FE6oY6aVaw== Date: Thu, 24 Oct 2013 02:44:04 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CD04D@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Ac+w Be46 CEcj Cw5T DWc7 DzhY E22N F9kQ GUCS Gccx HqxQ Iaqb JqRo KCT1 K93r MI0a; 1; bwBwAHMAYQB3AGcAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {F6678AF2-6E17-4675-B66B-ADBA89BAE357}; bABlAG8ALgBsAGkAdQBiAGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 24 Oct 2013 02:44:01 GMT; UwBvAGwAaQBjAGkAdABpAG4AZwAgAGMAbwBtAG0AZQBuAHQAcwAgAG8AbgAgAGQAcgBhAGYAdAAtAGwAaQB1AC0AcgB1AG4AbgBpAG4AZwAtAG0AdQBsAHQAaQBwAGwAZQAtAHAAcgBlAGYAaQB4AGUAcwAtADAAMQA= x-cr-puzzleid: {F6678AF2-6E17-4675-B66B-ADBA89BAE357} x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [OPSAWG] Soliciting comments on draft-liu-running-multiple-prefixes-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 02:44:27 -0000 Hi All, We have submitted a draft:=20 http://tools.ietf.org/html/draft-liu-running-multiple-prefixes-01 May I request your review and comments. Any feedback would be appreciated much. A brief intro of this draft: Administrators might not be familiar with running multiple prefixes simulta= neously in networks, since it is not a normal deployment model in IPv4. But= in IPv6, the hosts are naturally ready for multiple addresses, and in some= cases multiple prefixes could benefit the network use (as the use cases de= scribed in the draft, multihoming/semantic prefixes/addresses with multiple= scopes/separated OAM plane .etc ), so it might become a very common deploy= ment model in real IPv6 networks. This draft aims at helping readers to understand and be accustomed to run m= ultiple prefixes in IPv6 networks. Use cases, operational considerations, a= nd current gaps are provided in the draft. Many thanks and best regards, Bing From acmorton@att.com Thu Oct 24 06:32:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02A111E8311 for ; Thu, 24 Oct 2013 06:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvVD18N4e+Ak for ; Thu, 24 Oct 2013 06:32:15 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id DD55B11E8315 for ; Thu, 24 Oct 2013 06:32:03 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 07ABF1206B2; Thu, 24 Oct 2013 09:32:03 -0400 (EDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by mail-azure.research.att.com (Postfix) with ESMTP id 8A06DE02EF; Thu, 24 Oct 2013 09:32:03 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.160.22]) by mail-blue.research.att.com (Postfix) with ESMTP id 83D4BF013A; Thu, 24 Oct 2013 09:32:03 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Thu, 24 Oct 2013 09:32:03 -0400 From: "MORTON, ALFRED C (AL)" To: "opsawg@ietf.org" Date: Thu, 24 Oct 2013 09:32:02 -0400 Thread-Topic: Re: Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC Thread-Index: Ac3yeLXjiQQo4p4cTpeRKnTArIHmZwArkErwN2V2NGA= Message-ID: <2845723087023D4CB5114223779FA9C8ABBA79B7@njfpsrvexg8.research.att.com> References: <50F437BF.8040005@cisco.com> <50F43982.8010805@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8ABBA79B7njfpsrvexg8rese_" MIME-Version: 1.0 Cc: "ops-ads@tools.ietf.org" Subject: [OPSAWG] FW: Re: Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 13:32:21 -0000 --_000_2845723087023D4CB5114223779FA9C8ABBA79B7njfpsrvexg8rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OPAWG, One of the authors asked me to check that my comments on this draft (below) were resolved. The diff between versions 08 and 09 indicates that they were. Al From: MORTON JR., ALFRED (AL) Sent: Tuesday, January 15, 2013 9:21 AM To: 'Benoit Claise'; Thomas Nadeau; Monique Morrow; sam_aldrin@yahoo.com Cc: Ron Bonica Subject: RE: Re: Last Call: (An Ove= rview of Operations, Administration, and Maintenance (OAM) Mechanisms) to I= nformational RFC Hi Benoit, Here are some additional comments, just checking a few things I know a little about. Al -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- 1.1. The Building Blocks of OAM ... 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. >>> Apparently, no OAM tool currently measures Throughput, because no such tool is cited in the memo (and the term "throughput" never appears again). my guess is that there was some reference to RFC 2544 that has now been removed. Remove Throughput from the list. 1.3 OAM Toolsets ... 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. >>> and Delay variation, duplication, reordering, etc. (all the metrics lim= ited tools completely ignore). 1.4 IETF OAM Documents >>> Expand Table 1 as noted above, to include all the metrics they missed. 3.6.1 ... TWAMP [TWAMP] is a similar protocol that enables measurement of >>> both one-way and two-way (round trip) characteristics. >>> sentence below is simply not true, because the authors did not understa= nd the one-way measurement capability: 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. >>> go back and read the memo... 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 | | +-----------+-------+--------+--------+-----------+-------+--------+ ... + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |OWAMP and | | | | |-Delay | | |TWAMP | Yes | Yes | | | measur| | | | | | | | ement | | | | | | | |-Packet| | | | | | | | loss | | | | | | | | measur| | | | | | | | ement | | +-----------+-------+--------+--------+-----------+-------+--------+ Table 3 Summary of OAM Functions >>> Both Continuity Check and Connectivity Verification are tested and confirmed by establishing the *WAMP Control Protocol TCP connection, so this should be indicated the table. --_000_2845723087023D4CB5114223779FA9C8ABBA79B7njfpsrvexg8rese_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= OPAWG,

 =

One of the authors asked me to check that my comm= ents on

this draft (below) were = resolved. The diff between versions 08 and 09

indicates that they were.

 

Al

 

From: MORTON JR., A= LFRED (AL)
Sent: Tuesday, January 15, 2013 9:21 AM
To:= 'Benoit Claise'; Thomas Nadeau; Monique Morrow; sam_aldrin@yahoo.com
Cc: Ron Bonica
Subject: RE: Re: Last Call: <draft-ietf-op= sawg-oam-overview-08.txt> (An Overview of Operations, Administration, an= d Maintenance (OAM) Mechanisms) to Informational RFC

<= /div>

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:windowtext'>= Hi Benoit,

 

Here are some additional comments, just checki= ng a few things

I know a little = about.

 <= /p>

Al

 

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-

 

1.1. The Building Blocks of = OAM

...

   o Performance Monitoring:=

      Consists of 3 main= functions

 

        o L= oss Measurement (LM) - monitors the packet loss rate of a=

        &= nbsp; connection.

 

      &nb= sp; o Delay Measurement (DM) - monitors the delay and delay

        = ;  variation between MPs.

<= o:p> 

    &n= bsp;   o Throughput measurement - monitors the throughput of a

      &nb= sp;   connection.

=  

>>> Apparently,= no OAM tool currently measures Throughput,

    because no such tool is cited in the = memo (and the term “throughput”

    never appears again).  my guess is th= at there was some reference to

&= nbsp;   RFC 2544 that has now been removed. Remove Throughput fro= m the list.

 

1.3 OAM Toolsets

...

 &nbs= p; o OWAMP and TWAMP:

 = ;     The One Way Active Measurement Protocol (OWAMP) a= nd the Two Way

   = ;   Active Measurement Protocols (TWAMP) are two protocols define= d in

    &nb= sp; the IP Performance Metrics (IPPM) working group in the IETF. These=

      proto= cols allow delay and packet loss measurement in IP networks.

 

>>> and Delay variation, duplication, reordering, etc. (all th= e metrics limited tools

 &n= bsp;  completely ignore).

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:windowtext'>=  

1.4 IETF OAM Documents

 

>>> Expand Table 1 as noted above, to include all = the metrics they missed.

&n= bsp;

 

3.6.1

...=

   TWAMP [TWAMP] is a simi= lar protocol that enables measurement of

>>> both one-way and

   two-way (round trip) characteristics. 

 

>>> sentence below is simply not true, because the = authors did not understand

 = ;  the one-way measurement capability:

   TWAMP does not require accurate

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

&= nbsp;  reflector, making it an attractive alternative to OWAMP.

>>> go back and read the memo= ...

 

=

 

3.7= . Summary of OAM Functions

=  

   Table 3 summarize= s the OAM functions that are supported in each of

   the categories that were analyzed in this se= ction.

 <= /p>

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

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:windowtext'>=    | Standard  |Continu|Connecti|Path    |Def= ect     |Perform|Other   |<= /p>

   |      =      |ity    |vity    |Di= scover|Indications|ance   |Function|

   |       &nbs= p;   |Check  |Verifica|y      = |           |Monitor|s&n= bsp;      |

   |         &n= bsp; |       |tion    | &= nbsp;      |      &n= bsp;    |ing    |    &nbs= p;   |

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

...

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

   |OWAM= P and  |       |    =     |        |  = ;         |-Delay |  &nbs= p;     |

&nb= sp;  |TWAMP      |  Yes  |  Ye= s   |        |  &nbs= p;        | measur|   &nb= sp;    |

 &n= bsp; |           | &= nbsp;     |        |=         |     &= nbsp;     | ement |      =   |

   | &nb= sp;         |   &nbs= p;   |        |  &nb= sp;     |       &nbs= p;   |-Packet|        |

   |    =        |       = |        |     =    |           = | loss  |        |

   |     &nbs= p;     |       | &nb= sp;      |      &nbs= p; |           | measur|&= nbsp;       |

   |        = ;   |       |   &nbs= p;    |        | &nb= sp;         | ement |  &n= bsp;     |

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

    &n= bsp;            = ;    Table 3 Summary of OAM Functions

<= p class=3DMsoNormal> 

>= >> Both Continuity Check and Connectivity Verification are tested and=

confirmed by establishing the *= WAMP Control Protocol TCP connection,

so this should be indicated the table.

 

 = ;

 

<= /div>= --_000_2845723087023D4CB5114223779FA9C8ABBA79B7njfpsrvexg8rese_-- From saperia@g.harvard.edu Thu Oct 24 10:09:39 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDEA11E838C for ; Thu, 24 Oct 2013 10:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy81X7aqb0NW for ; Thu, 24 Oct 2013 10:09:22 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0D50E11E82DA for ; Thu, 24 Oct 2013 10:08:28 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x19so1542320qcw.37 for ; Thu, 24 Oct 2013 10:08:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=vnM1n5RzrUPXPqxyoUks7wfVFz6kSC23srS1TdpUOGs=; b=RrFwnzJxEMbzFTE9NvSneCNyW1v5egho88OqBtiKPINRaRaF9UoKRRxm4itc6Akdfm N4EZTbY707NDJPUzMpeSIhP1wseSo5mmbJUSto9S9HrMS/KrqT17GTWAH8dXtKoYRlhs VK3Kmu+BlDo1QVfIodj5ZDqVGF/1jl2XsifarrgMALOdrYWb+ofqetO0J6aE8ImFJwWY FEXH6nWG1JJpz4A+5vWj8fP+Qz5gm9/GROPtKz/6OUU/f7OgdDmoAKeJTeyB1znp52OO Tg6t7kBR0vA6AulPqMCBc0lbgiFN3Q26pAMsEALjzB1ozmIYZ11VN0h7TNQ0jBx/5amR 3lPQ== X-Gm-Message-State: ALoCoQl2luhe7GHcIsSxE7RgsXtnHFC0yS7439yNJ67w8hqllTuaZKcZ2Udk744KiiQtzcWjDKjk X-Received: by 10.224.3.5 with SMTP id 5mr5351314qal.93.1382634495463; Thu, 24 Oct 2013 10:08:15 -0700 (PDT) Received: from dhcp-128-103-65-110.harvard.edu (dhcp-128-103-65-110.harvard.edu. [128.103.65.110]) by mx.google.com with ESMTPSA id k4sm9506508qaa.8.2013.10.24.10.08.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Oct 2013 10:08:14 -0700 (PDT) From: Saperia Jon Content-Type: multipart/alternative; boundary="Apple-Mail=_A2C91B70-FB84-4C6B-B78C-11258AF64E35" Message-Id: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> Date: Thu, 24 Oct 2013 13:08:09 -0400 To: opsawg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [OPSAWG] Comments on draft-asai-vmm-mib-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 17:09:39 -0000 --Apple-Mail=_A2C91B70-FB84-4C6B-B78C-11258AF64E35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I thought two additional objects might be of value based on current = experience: cpuReadyTime - how much time a VM is waiting for CPU resources. This = could be expressed in milliseconds over the past minute. storageLatency - a problem that sometimes comes up is that the CPU is = available to the VM but due to storage latency work can not continue. = This object will show average storage latency over a short period of = time (perhaps 15 seconds). =20 Notifications should be created for these two objects that can be sent = when values exceed configurable limits. Thank you=20 /jon Jon Saperia saperia@g.harvard.edu Enterprise Architect Harvard University Information Technology Innovation & Architecture (P) (617) 384-6683 1350 Mass Ave., room 758 Cambridge, MA 02138 --Apple-Mail=_A2C91B70-FB84-4C6B-B78C-11258AF64E35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thank you 
/jon
Jon = Saperia
Harvard University Information Technology
 (617) = 384-6683
1350 = Mass Ave., room 758

= --Apple-Mail=_A2C91B70-FB84-4C6B-B78C-11258AF64E35-- From cpignata@cisco.com Thu Oct 24 13:28:13 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A1C11E81CA for ; Thu, 24 Oct 2013 13:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.773 X-Spam-Level: X-Spam-Status: No, score=-110.773 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWXN1jjpmMLN for ; Thu, 24 Oct 2013 13:28:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id ED04F11E8210 for ; Thu, 24 Oct 2013 13:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22339; q=dns/txt; s=iport; t=1382646487; x=1383856087; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0YgvWj0xqPiG/OspUVaGsmfYoY4a+dL1XEdhAp8f0dE=; b=ArpQeJVfZntazT3T/FfYOy+JZOJ0CHMhJdNgwkUVoMpFz1ktSkdGjWbi 7YCALdsLlA5wZn/mxtBnMe5KbzwRc1W41ek9erhriyQrv8i6aDXbSh0D4 tfsaBxHoWmOHNtgDoBEchWJgi4YF/d/EMnxSxcEZ2KieKKsTa2QkkwEN8 E=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUFAHqBaVKtJXHB/2dsb2JhbABZgkNEOFS2FId/S4EfFnSCJQEBAQMBAQEBawsFCwIBCCIWDicLJQEBBA4FCAaHcwYNui2NeYEjLQQHgx+BDQOQLYEwgk2FD5BYgySCKg X-IronPort-AV: E=Sophos;i="4.93,564,1378857600"; d="asc'?scan'208,217";a="273321196" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 24 Oct 2013 20:28:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9OKS5Xr019985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 20:28:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 15:28:05 -0500 From: "Carlos Pignataro (cpignata)" To: Tal Mizrahi Thread-Topic: [OPSAWG] Updated draft-ietf-opsawg-oam-overview-10 Thread-Index: Ac7QCBPXM7/vjWUjRf+fSKRq1SubJwBGV7uA Date: Thu, 24 Oct 2013 20:28:04 +0000 Message-ID: <95067C434CE250468B77282634C96ED33360F3F9@xmb-aln-x02.cisco.com> References: <74470498B659FA4687F0B0018C19A89C01B87D7A485A@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01B87D7A485A@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.62] Content-Type: multipart/signed; boundary="Apple-Mail=_BD56E997-7986-44BA-A5C0-7FFF19E28968"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-oam-overview@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Updated draft-ietf-opsawg-oam-overview-10 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:28:13 -0000 --Apple-Mail=_BD56E997-7986-44BA-A5C0-7FFF19E28968 Content-Type: multipart/alternative; boundary="Apple-Mail=_1EC02B37-9CB7-4284-8759-F7D0FADB0C87" --Apple-Mail=_1EC02B37-9CB7-4284-8759-F7D0FADB0C87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Tal, First of all, there's been tremendous amount of progress and meaningful = forward movement with this document since it went into IETF LC earlier = this calendar year. Very many thanks for that, as it's been very = productive. =46rom my perspective, all major comments have been addressed, and the = minor suggestions have also been entertained. This looks good! At the same time, from a process perspective, the doc really (really!) = changed since the WG considered it last time in a WGLC: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-oam-overview-10.txt= &url1=3Ddraft-ietf-opsawg-oam-overview-07.txt Chairs, Would a WGLC be also in order? Thanks, -- Carlos. On Oct 23, 2013, at 12:55 PM, Tal Mizrahi wrote: > Hi, > =20 > We have uploaded an updated draft. > http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-10 > =20 > This document has been around for a while now (4 years), and over this = long period we have receive a very large number of comments from many = reviewers. We would like to thank everyone who has reviewed and sent = comments, which have significantly helped us to improve the document. > =20 > We, the authors, believe that we have addressed all the comments we = received, and that this document is finally ready for WG last call. > =20 > As advised by our AD, Benoit Claise, we would like to get feedback = about whether we have indeed addressed the concerns that were raised, = and whether this document is ready to go. > =20 > =20 > Main changes compared to prev draft > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The main changes compared to the previous draft are: > - Various terminology fixes following comments we received from = Stewart Bryant and Benoit Claise. > - We have added a subsection about connection oriented vs. = connectionless communication, as well as a subsection about = point-to-point vs. point-to-multipoint communication. > =20 > =20 > A (not so short) history of this draft > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > - October 2009 draft-mizrahi-opsawg-oam-overview was submitted as > an independent submission. > - December 2009 draft-mizrahi-opsawg-oam-overview became a WG document > - July 2010 draft-sprecher-mpls-tp-oam-primer was submitted as > an independent submission. > - July 2010 draft-ietf-opsawg-oam-overview was presented in IETF = 78. > Loa Andersson commented that this draft overlaps with > draft-sprecher-mpls-tp-oam-primer, and suggested to = merge them. > - October 2010 The two drafts were merged into = draft-ietf-opsawg-oam-overview. > - March 2011 The draft went into WG last call. > - August 2011 The draft went through IESG review. After a short = iterative > process most of the comments were addressed, except a = single > (but significant) DISCUSS by the routing area AD, = which > included a large number of comments. > - March 2012 The draft was significantly revised to address the = comments > from the pending DISCUSS. > - Sep 2012 The updated version was not reviewed by the IESG on = time. > The IESG has a 1-year-timeout for drafts in the IESG = process, > and hence the draft went back to the WG. > - Dec 2012 The draft passed WG last call (again). > - Jan 2013 IETF last call: the draft received comments from ~10 = reviewers, > including significant comments from the routing area = reviewers. > - Jun 2013 Ops AD, Benoit Claise, returned the document to the WG > following the large number of comments. > - Jul 2013 The draft was significantly revised to address the = comments in > IETF last call, and especially the ones by the routing = area > reviewers. > - Oct 2013 The draft was revised to address additional comments = by the > Ops area AD and the routing area AD. > =20 > =20 > Any feedback would be welcome. > =20 > Thanks, > Tal. > =20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail=_1EC02B37-9CB7-4284-8759-F7D0FADB0C87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, = Tal,

First of all, there's been tremendous amount of = progress and meaningful forward movement with this document since it = went into IETF LC earlier this calendar year. Very many thanks for that, = as it's been very productive.

=46rom my = perspective, all major comments have been addressed, and the minor = suggestions have also been entertained. This looks = good!

At the same time, from a process = perspective, the doc really (really!) changed since the WG considered it = last time in a WGLC:

Chairs, = Would a WGLC be also in = order?

Thanks,

-- = Carlos.

On Oct 23, 2013, at 12:55 PM, Tal = Mizrahi <talmi@marvell.com>= wrote:

 
We = have uploaded an updated draft.
X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C3C11E8210 for ; Thu, 24 Oct 2013 13:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7-VblTyNHRP for ; Thu, 24 Oct 2013 13:29:43 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DB60B11E81CA for ; Thu, 24 Oct 2013 13:29:43 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc17so3168170pbc.4 for ; Thu, 24 Oct 2013 13:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6mfp8fi6Nkwb2VLhTmCrUuiQ9WTiTD9jc8oOkFJpu+M=; b=kzRSzsBKYSPreN2TuYtmbHU0/lrdClzYbGweeRKXM8mKLpQYs1FogRWcBAV/y+wWZQ iem7hzOIveeni+NHpDFPBuWmVlDaerU4aBaMQUGUnCzk1M2i+/+85lQwInMddVRRat9M lFfT+zIPS+0cZqOB0xKFzNoai2pTqbElgRqdT10IVoyJkpV1PFkBN87tMmCFN9AvPimY dYMbFMKJmeymlTqi8ytAyFdbSBHRRo4CDK4aMe/bysDf2SoEkcTOOD0AVTWwpWrUoblt OIabqiprL7K+zJA0gU2EijQ6KbiT02yL5yDUMIQEZK5WfQFYoaZBJKo9zqnvRe/gBTG2 XyNA== X-Received: by 10.66.188.80 with SMTP id fy16mr5189043pac.168.1382646583685; Thu, 24 Oct 2013 13:29:43 -0700 (PDT) Received: from spandex.local (63-140-94-250.dynamic.dsl.acsalaska.net. [63.140.94.250]) by mx.google.com with ESMTPSA id be1sm4574184pbb.28.2013.10.24.13.29.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Oct 2013 13:29:42 -0700 (PDT) Message-ID: <52698333.6050304@gmail.com> Date: Thu, 24 Oct 2013 12:29:39 -0800 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: "Carlos Pignataro (cpignata)" References: <74470498B659FA4687F0B0018C19A89C01B87D7A485A@IL-MB01.marvell.com> <95067C434CE250468B77282634C96ED33360F3F9@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED33360F3F9@xmb-aln-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-oam-overview@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Updated draft-ietf-opsawg-oam-overview-10 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:29:44 -0000 On 10/24/13 12:28 PM, Carlos Pignataro (cpignata) wrote: > Chairs, Would a WGLC be also in order? That's the plan, but we'd like to make sure the reviewers' concerns have been addressed, first. Thanks, Melinda From cpignata@cisco.com Thu Oct 24 13:31:07 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0264711E835C for ; Thu, 24 Oct 2013 13:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.739 X-Spam-Level: X-Spam-Status: No, score=-110.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs7HatviOqYr for ; Thu, 24 Oct 2013 13:31:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3B59011E8336 for ; Thu, 24 Oct 2013 13:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=613; q=dns/txt; s=iport; t=1382646661; x=1383856261; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xvj7EDgHLYYl9vhDcIk8z6oh7+jQ8GQPH5XIYpxh4w8=; b=LC/2J8njPaohN/nUT86MpsbR4hEpk9wA3IWgWo5Bb6TMGQrL2F4lU+RQ 8X/u2eoa5guyjJFPNVlWW0seXb7W4X0Z2C+7qJzBvuKZqHIPmYRd3NqCC 1rNI6LUucZ1q1EWDcS8uZvzzXrTGZc0cv3i2kOqe+sg+619TU6MpNdk2z g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANOCaVKtJV2b/2dsb2JhbABZgwc4VL4TS4EfFnSCJQEBAQQBAQE3NAsSAQgYChQxBgslAQEEDgUIh20DDw2wMw2JZwSMX4I9MQeDH4ENA5QqgXWOO4U3gySCKg X-IronPort-AV: E=Sophos;i="4.93,564,1378857600"; d="scan'208";a="276306589" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 24 Oct 2013 20:31:00 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9OKV0eG027177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 20:31:00 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 15:31:00 -0500 From: "Carlos Pignataro (cpignata)" To: Melinda Shore Thread-Topic: [OPSAWG] Updated draft-ietf-opsawg-oam-overview-10 Thread-Index: Ac7QCBPXM7/vjWUjRf+fSKRq1SubJwBGV7uAAAAOToD//71QAA== Date: Thu, 24 Oct 2013 20:30:59 +0000 Message-ID: <95067C434CE250468B77282634C96ED33360F4CA@xmb-aln-x02.cisco.com> In-Reply-To: <52698333.6050304@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.117.115.62] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C87132FB5BB6441B1B79434281EA60D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-oam-overview@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Updated draft-ietf-opsawg-oam-overview-10 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:31:07 -0000 On 10/24/13 4:29 PM, "Melinda Shore" wrote: >On 10/24/13 12:28 PM, Carlos Pignataro (cpignata) wrote: >> Chairs, Would a WGLC be also in order? > >That's the plan, but we'd like to make sure the reviewers' >concerns have been addressed, first. Thanks, Melinda. As RTG-Dir reviewer for the document, and also as an individual reviewer, all my concerns have been addressed. Thanks, -- Carlos. > >Thanks, > >Melinda > > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From warren@kumari.net Thu Oct 24 14:07:01 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A4511E8247 for ; Thu, 24 Oct 2013 14:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PgJiuQIqw1U for ; Thu, 24 Oct 2013 14:06:50 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C0E11E8238 for ; Thu, 24 Oct 2013 14:06:15 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id 537B91B400E3; Thu, 24 Oct 2013 17:06:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari Date: Thu, 24 Oct 2013 17:06:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131021181118.32495.35777.idtracker@ietfa.amsl.com> To: "opsawg@ietf.org" X-Mailer: Apple Mail (2.1510) Subject: [OPSAWG] Fwd: New Version Notification for draft-swhyte-i2rs-data-collection-system-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 21:07:01 -0000 Dear OPSAWG, We have written a draft that outlines a set of use case and requirements = for a bulk data collection system for collecting large amounts of data = from network infrastructure. The system is designed to allow for faster / lower overhead access than = things like SNMP, and be friendlier than things like screen scraping. While the document will probably end up in I2RS, we wanted to discuss = it here, because we want to make sure that the use cases and requirement = capture *operators* input, and because this is a (proposed) new = management solution. We have already discussed this idea / concept with a number of operators = (including large content type players), at places like NANOG and have = incorporated their feedback, but would really appreciate additional = review, use cases, discussion, etc. W Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-swhyte-i2rs-data-collection-system-00.txt > Date: October 21, 2013 2:11:18 PM EDT > To: Scott Whyte , Marcus Hines , = Warren Kumari >=20 >=20 > A new version of I-D, draft-swhyte-i2rs-data-collection-system-00.txt > has been successfully submitted by Scott Whyte and posted to the > IETF repository. >=20 > Filename: draft-swhyte-i2rs-data-collection-system > Revision: 00 > Title: Bulk Network Data Collection System > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-swhyte-i2rs-data-collection-syst= em-00.txt > Status: = http://datatracker.ietf.org/doc/draft-swhyte-i2rs-data-collection-system > Htmlized: = http://tools.ietf.org/html/draft-swhyte-i2rs-data-collection-system-00 >=20 >=20 > Abstract: > Collecting large amounts of data from network infrastructure devices > has never been very easy. Existing methods generate CPU and memory > loads that may be unacceptable, the output varies across > implementations and can be difficult to parse, and these methods are > often difficult to scale. I2RS programmatic interfacing with the > routing system may exacerbate this problem: state needs to be > collected from nodes and fed to consumers participating in the > control plane that may not be physically close to the nodes. This > state includes not only control plane information, but elements of > the data plane that have a direct impact on control plane behavior, > like traffic engineering. >=20 > This document outlines a set of use cases requiring a flexible > framework to collect routing system data, and the features and > functionality needed to make such a framework useful for these use > cases. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --=20 "I think it would be a good idea."=20 - Mahatma Ghandi, when asked what he thought of Western civilization From melinda.shore@gmail.com Fri Oct 25 10:07:24 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B2B21E80BC for ; Fri, 25 Oct 2013 10:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p18W+NkgA31O for ; Fri, 25 Oct 2013 10:07:22 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3B00511E83AD for ; Fri, 25 Oct 2013 10:07:00 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id g10so4198872pdj.20 for ; Fri, 25 Oct 2013 10:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Mi9IwnF3TYmje68xm7XneTiazlxpDmW1iF/g9NM5ans=; b=UPJUFrZLyHRj2+LiwWfrTMmea2szfbEwx+xOe09U/sq7Nno/2kT0Le971fHVqwWJte tAcrjOPEtFEKYgCaIhdSIlRpKXcLVUoWW8arOZqQOgI1TPr19vZFnopP3UT9tbq1Pqk5 /zNwlzGjxhvcWRXqvk7ySw9AEy4kZcfG8jhLSNM8+TJTw+4X2CZTtB9lI4zrMfgWbeTD yKZX+Szs9TP3nMhgujSXD05Ii4mW6tJuzVrEE8mqDktm0tr2gB7dSWrkPIkJLvQBy8cv 78jm9pliU3kwEhPuca7cQzB2qJbjDREiJdpBPd0u5KLlC1yPKojebASC6934r+rS5uCo jHmQ== X-Received: by 10.66.102.100 with SMTP id fn4mr11759394pab.71.1382720815836; Fri, 25 Oct 2013 10:06:55 -0700 (PDT) Received: from spandex.local (63-140-94-250.dynamic.dsl.acsalaska.net. [63.140.94.250]) by mx.google.com with ESMTPSA id ef10sm14684000pac.1.2013.10.25.10.06.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 10:06:54 -0700 (PDT) Message-ID: <526AA52C.1040308@gmail.com> Date: Fri, 25 Oct 2013 09:06:52 -0800 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" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Asking for time on the agenda X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:07:24 -0000 Hello, opsawg-ites: It seems to have become a matter of standard practice for someone to request time on the agenda to discuss a draft that we've never seen before and which has received no discussion. We always write back and tell them there really needs to be discussion on the mailing list so that we can gauge interest, relevance, and quality, and so the author sends email to opsawg@ietf.org. You can save yourself a round trip and possibly a bit of time by starting a mailing list discussion first. Melinda From brian.e.carpenter@gmail.com Fri Oct 25 19:31:37 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB26A21F9ECE for ; Fri, 25 Oct 2013 19:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfTfLS8mMfLN for ; Fri, 25 Oct 2013 19:31:37 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5E411E80DC for ; Fri, 25 Oct 2013 19:31:37 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id g10so4694622pdj.6 for ; Fri, 25 Oct 2013 19:31:36 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=AAMC5ZRLwtbN7SyioTn42ctjh4g3UhHHe2B5kADTZf8=; b=TR9DADdVBrHCFqHRnOJ+hqcjUfWott/lYQbx2s13i4+1fdQKMae9d/WNDix+ds/6dp wEmFc/ScFslV1onv9BGfOwSjZKpmnAqBaws8/sI9xu9Xmz6xZqSbJlNeg2sE2FSpkRZL fNa1YTu2TBsRNY0bJH5VePg0oiRtkFc05E2+tVpOKOswGtO3C5UsLE0qAqK1OrjX6HQW bXoTFeod//dGz3zMra6YSl9X2VZ/qGEzE8s54Qaqs5wvMEkT0kT8XmrKaBsRKn/EEHRJ DCaSSkUStFHmmBL+hZ+jAsk/rSjwQW6lWlBpFtmVcb8AIsV0JMdJ5w+yAAmUdjh8IK5Q 3kJg== X-Received: by 10.68.28.5 with SMTP id x5mr4655385pbg.72.1382754696638; Fri, 25 Oct 2013 19:31:36 -0700 (PDT) Received: from [192.168.178.20] (85.201.69.111.dynamic.snap.net.nz. [111.69.201.85]) by mx.google.com with ESMTPSA id f8sm12610128pbe.43.2013.10.25.19.31.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 19:31:36 -0700 (PDT) Message-ID: <526B2993.2070103@gmail.com> Date: Sat, 26 Oct 2013 15:31:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-jiang-config-negotiation-ps@tools.ietf.org Subject: [OPSAWG] Network Configuration Negotiation X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 02:31:37 -0000 It's a bit close to Vancouver, but could people have a look at https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-ps/ ? The idea is to establish a problem statement for distributed autonomous configuration of multiple aspects of networks, in particular carrier networks. In a sense it's a next step beyond draft-boucadair-network-automation-requirements. We'd like to get away from top-down human-intensive configuration. Regards Brian From melinda.shore@gmail.com Fri Oct 25 21:49:12 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3DB11E8128 for ; Fri, 25 Oct 2013 21:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux5QlYIUdpTt for ; Fri, 25 Oct 2013 21:49:12 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 68A5D21E80CE for ; Fri, 25 Oct 2013 21:48:55 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so1464865pbc.36 for ; Fri, 25 Oct 2013 21:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zobkWqHZT3ZIzrWCKYs+W1DDN1/psMz6/PfHkm7OtGk=; b=VirWXdk2SgkYLY8M0zqEo2Hu/p3feqSBF38NZWTff5wqQGOoO9qLX427R0DV4AMM7W ie7AzcM2/o+BKfZyZDJqewcNoiaIrHqEKG9I2ayj2o4hxIY0RrghLWMrwAdCEFQoUnRC 8djsrIiAly/kAMb5U/GIiT7iwkduKf8gQhaQujM7sKpReLyX5Adl9HPTGDu0fdGtG3+3 M5wRQV+Q/0e4T/SPXWlSLG+616olBoM96mnHl/4Npr5bwulB+tRD7aDcTlh7kHcj5QqI Bajic/JsbSBL6ZernX8d1I0869zfI3OzfXWGhcLE3aBz5fSyZKs5TtSZMR5BXudPULW3 8HRg== X-Received: by 10.68.130.1 with SMTP id oa1mr10386530pbb.35.1382762935097; Fri, 25 Oct 2013 21:48:55 -0700 (PDT) Received: from spandex.local (63-140-94-250.dynamic.dsl.acsalaska.net. [63.140.94.250]) by mx.google.com with ESMTPSA id ye1sm17607130pab.19.2013.10.25.21.48.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 21:48:54 -0700 (PDT) Message-ID: <526B49B3.9050305@gmail.com> Date: Fri, 25 Oct 2013 20:48:51 -0800 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: <526B2993.2070103@gmail.com> In-Reply-To: <526B2993.2070103@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] Network Configuration Negotiation X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 04:49:12 -0000 On 10/25/13 6:31 PM, Brian E Carpenter wrote: > The idea is to establish a problem statement for distributed autonomous > configuration of multiple aspects of networks, in particular carrier networks. > In a sense it's a next step beyond draft-boucadair-network-automation-requirements. > We'd like to get away from top-down human-intensive configuration. Longer term, are you interested in seeing it adopted by opsawg, or are you asking for review for an individual submission, another working group, ... ? Melimda From brian.e.carpenter@gmail.com Sat Oct 26 12:07:58 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BE311E8208 for ; Sat, 26 Oct 2013 12:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScaNWmkMunzY for ; Sat, 26 Oct 2013 12:07:53 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id ED42821F9E40 for ; Sat, 26 Oct 2013 12:07:48 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id g10so5323675pdj.6 for ; Sat, 26 Oct 2013 12:07:44 -0700 (PDT) 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=HnQhW3MIlAgGAjFUCOMrgMEqzKchwvmKZUJy80eHzt8=; b=yj9Bgk5lZzIXWku9szXpnVAvLTkdY1XimZZCXAgvkAxCjcDIQauX2Qb29ZS9aWO3RC /+PA+iiBdzrrjJXFO6gB7GR2gQWIw3q34Nv8jkf5TdvokHvZeHkuldgGUEN3baU4ckVL 8SqryJ2v0yOIVo6YrBLFMz4Lw4mauQRygQxv9c1ea+W+T9aQ1fJ+MLtpxhEOl3tOQM38 PBnPyGHOaX3ZuR7v2Lul7wYOzlXvU0vKJROqBZJby/j8zcs8bodq4fdFMQCZE3V9qXko FOeLYZicfYvcicuthcI4oHhWATntfEkOggqyposo9RIIefn2rwE7kichDl9w9mpkSWJt Se7Q== X-Received: by 10.68.180.34 with SMTP id dl2mr13024340pbc.6.1382814464282; Sat, 26 Oct 2013 12:07:44 -0700 (PDT) Received: from [192.168.178.20] (38.201.69.111.dynamic.snap.net.nz. [111.69.201.38]) by mx.google.com with ESMTPSA id ye1sm22682586pab.19.2013.10.26.12.07.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Oct 2013 12:07:43 -0700 (PDT) Message-ID: <526C12F8.7030202@gmail.com> Date: Sun, 27 Oct 2013 08:07:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Melinda Shore References: <526B2993.2070103@gmail.com> <526B49B3.9050305@gmail.com> In-Reply-To: <526B49B3.9050305@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Network Configuration Negotiation X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 19:08:12 -0000 Melinda, On 26/10/2013 17:48, Melinda Shore wrote: > On 10/25/13 6:31 PM, Brian E Carpenter wrote: >> The idea is to establish a problem statement for distributed autonomous >> configuration of multiple aspects of networks, in particular carrier networks. >> In a sense it's a next step beyond draft-boucadair-network-automation-requirements. >> We'd like to get away from top-down human-intensive configuration. > > Longer term, are you interested in seeing it adopted by opsawg, > or are you asking for review for an individual submission, > another working group, ... ? I think our minds are fairly open at the moment, but opsawg seems like a reasonable venue for the problem statement, if people agree that there's a problem. Needless to say we have ideas for the solution space, which might require the BOF/WG route, but it's too soon to discuss that. Thanks Brian From rpazhyan@cisco.com Sat Oct 26 17:08:07 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A00D11E81CA for ; Sat, 26 Oct 2013 17:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yesLXYW1+jxt for ; Sat, 26 Oct 2013 17:07:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AE2F821F9E39 for ; Sat, 26 Oct 2013 17:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4130; q=dns/txt; s=iport; t=1382832474; x=1384042074; h=from:to:subject:date:message-id:mime-version; bh=+I332YxD6TQCB8wHPayNr7ZKRaO6bgnUhgYjDqvXNzo=; b=RYF/p25DUNf0EEZt6IZQFdVCVQ2/4/r5lyjrtvPQq2sh3ovl8ltKhk9w 2VYmiuo+WUX4q+XlqoZIThPFPsDeDSs4dmdtgb9MBQ1xnavu+RFfweHen Eq3Du6D4hympD3aPcuMUjN1EMA2jip3JVJieX6+mZMWhetjHac8qFlbkw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwHAK9YbFKtJV2b/2dsb2JhbABZgkNEOFSsI4lmiEeBHxZtB4InAQQtXgEMHlYmAQQbE4dsDZYUoRiPJINXgQ0DmTmQWIFogT6CKg X-IronPort-AV: E=Sophos;i="4.93,578,1378857600"; d="scan'208,217";a="277111227" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 27 Oct 2013 00:07:40 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9R07eGX005526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 27 Oct 2013 00:07:40 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.202]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Sat, 26 Oct 2013 19:07:39 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "opsawg@ietf.org" Thread-Topic: Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" Thread-Index: Ac7SqIs8II5D0brnRoyCTVQ6wZ7WWA== Date: Sun, 27 Oct 2013 00:07:38 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320ED015B@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.21.146.163] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320ED015Bxmbalnx09ciscoc_" MIME-Version: 1.0 Subject: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 00:08:07 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320ED015Bxmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello We have resubmitted a new version of the draft titled "Alternate Tunnel Enc= apsulation for Data Frames in CAPWAP", http://datatracker.ietf.org/doc/draf= t-zhang-opsawg-capwap-cds/. The previous version was titled: "Separation of CAPWAP Control and Data Pla= ne: Scenarios, Requirements and Solutions". Based on discussion in the last= IETF, we reworked the draft. The draft provides a reason for the need for WTP to have additional tunnel = (beyond CAPWAP) encapsulations for user traffic. It enables a WTP to advert= ise the capability to support such alternate tunnel encapsulation and the A= C to configure such tunnel encapsulation on the WTP. The alternate tunnel = encapsulation allows 1) the WTP to tunnel non-management data frames to an = endpoint different from the AC and 2) allows the WTP to tunnel using one of= many known ecapsulation types such as IP-IP, IP-GRE, CAPWAP. We would like to get it adopted as a working group item and would like feed= back on whether we are on track. Regards Rajesh --_000_4ED2E36A22261145861BAB2C24088B4320ED015Bxmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello
 
= The previous version was titled: “Separation of CAPWAP Control a= nd Data Plane: Scenarios, Requirements and Solutions”. Based on discussion in the last IETF, we reworked the draft. =
=  
= The draft provides a reason for the need for WTP to have additional tunnel = (beyond CAPWAP) encapsulations for user traffic. It enables a WTP to advert= ise the capability to support such alternate tunnel encapsulation and the AC to configure such tunnel encapsulation on t= he WTP.  The alternate tunnel encapsulation allows 1) the WTP to tunne= l non-management data frames to an endpoint different from the AC and 2) al= lows the WTP to tunnel using one of many known ecapsulation types such as IP-IP, IP-GRE, CAPWAP.
 
= We would like to get it adopted as a working group item and would like feed= back on whether we are on track.
=  
= Regards
=  
= Rajesh
 
 
 --_000_4ED2E36A22261145861BAB2C24088B4320ED015Bxmbalnx09ciscoc_-- From rpazhyan@cisco.com Sat Oct 26 17:18:40 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A1011E81E1 for ; Sat, 26 Oct 2013 17:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLIGSnd4CxXZ for ; Sat, 26 Oct 2013 17:18:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 68F2221F9F7F for ; Sat, 26 Oct 2013 17:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3236; q=dns/txt; s=iport; t=1382833115; x=1384042715; h=from:to:subject:date:message-id:mime-version; bh=5y7ZkHXr9IcS2ZyQsSC3+QpE2JTrSzvt/xgLKAIM4EE=; b=Cj29ZWPHNxV8fvNjU2PmBQIyL6orUO04NY8ySbCE+DPeJz3KsCXz9uF/ PMaDEx/BVb/qSZSMbVJhjk2uvQ0nSZaMjw+dajRhiKHWuO8STVrE+Quxb lw1u9XxkIfUI3LG86ZpI+OUlKYeWiLaPZrDbeBix8dqgmuC6S5VHG7ehU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwHAFBbbFKtJXG8/2dsb2JhbABZgkNEOFSsI4lmiEeBHxZtB4InAQQtXgEMHlYmAQQbh38NlhWhGI8kg1eBDQOZOZBYgyaCKg X-IronPort-AV: E=Sophos;i="4.93,578,1378857600"; d="scan'208,217";a="277083616" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 27 Oct 2013 00:18:34 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9R0IYvm010997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 27 Oct 2013 00:18:34 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.202]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sat, 26 Oct 2013 19:18:34 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "opsawg@ietf.org" Thread-Topic: Time on agenda to discuss " IEEE 802.11 MAC Profile for CAPWAP" Thread-Index: Ac7SqhIBFLVbyBHITzq7Ms47Oa5Q6w== Date: Sun, 27 Oct 2013 00:18:34 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320ED0185@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.21.146.163] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320ED0185xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: [OPSAWG] Time on agenda to discuss " IEEE 802.11 MAC Profile for CAPWAP" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 00:18:40 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320ED0185xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello We would like to request some time on the agenda to discuss " IEEE 802.11 = MAC Profile for CAPWAP ", http://datatracker.ietf.org/doc/draft-ietf-opsawg= -capwap-hybridmac/. In the last IETF meeting we had discussion that has resulted in changing th= e way the MAC profile capability is specified/advertised and configured. We have received comments on this draft from Dan and Stanley suggesting som= e further changes. We wanted some time mainly to discuss whether there were= any other changes required and whether we can move to last call after this= meeting. Thanks Regards Rajesh --_000_4ED2E36A22261145861BAB2C24088B4320ED0185xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello
 
In the= last IETF meeting we had discussion that has resulted in changing the way = the MAC profile capability is specified/advertised and configured.
We have received comments on this draft from Dan and Stanley suggesting som= e further changes. We wanted some time mainly to discuss whether there were= any other changes required and whether we can move to last call after this= meeting.
 
Thanks=
 =
Regard= s
 =
Rajesh=
 
 
--_000_4ED2E36A22261145861BAB2C24088B4320ED0185xmbalnx09ciscoc_-- From dstanley1389@gmail.com Mon Oct 28 10:29:44 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED5C11E8260 for ; Mon, 28 Oct 2013 10:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMJTTGX4CcCP for ; Mon, 28 Oct 2013 10:29:44 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C23F311E8191 for ; Mon, 28 Oct 2013 10:29:43 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id g12so3902680oah.5 for ; Mon, 28 Oct 2013 10:29:43 -0700 (PDT) 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=0fsvXAyfsIXY04hQFQvYIcidON+JnU4pS30Q+ccMpAE=; b=HuAB5L/hXUlNRRK7NKBj1K4rN1WhPPf5eF8lGq8bQh6L1zS5zFbVzU0PkGIfgdEnNE BIMiBytlvNRGrA9nxlN3vIPvvar4jnSjFuLFlG98ZOUXvgJgAQ72ylH7mLBr3qmvFXmY NByd/CSJot6Muijk4jHIXUZqWgoh4BUvxXBmt2CG8vvYUYxESfZ8KJl3KMzFnTOEej2D hbsQi8U/vBqTr9Pj5pDRpCKIHRXuXLedHOJC3dfk5+a+vDlweGeiFg6VqQYokkCtmEBl 12wTlOjrJ8NSp1ZFpROFBENv5P9HYKLmm0qOSQTjHqTizAdHZRSdW7TTRzYKOPTTZTEj Douw== MIME-Version: 1.0 X-Received: by 10.60.44.178 with SMTP id f18mr15591960oem.43.1382981383114; Mon, 28 Oct 2013 10:29:43 -0700 (PDT) Received: by 10.76.5.48 with HTTP; Mon, 28 Oct 2013 10:29:43 -0700 (PDT) In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320EC9109@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320EC9109@xmb-aln-x09.cisco.com> Date: Mon, 28 Oct 2013 10:29:43 -0700 Message-ID: From: Dorothy Stanley To: "Rajesh Pazhyannur (rpazhyan)" Content-Type: multipart/alternative; boundary=001a11333a4e1255d904e9d07214 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Seeking comments on draft "IEEE 802.11 MAC Profile for CAPWAP" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 17:29:44 -0000 --001a11333a4e1255d904e9d07214 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rajesh, Comments below. Dorothy ------------- 1. Today, Split and Local MAC are negotiated using the WTP MAC Type message element. There is no need to include Local and Split MAC in the profile element. The new mode is actually a profile of the current defined Split MAC. In section 4, delete 0 and 1, renumber =932=94 to =930=94 and ch= ange from =93indentified=94 to =93identified=94 in the line above. Section 3.2 can be deleted, and Sections 3.1 and 3.3 combined into a single table. 2. Section 3.3.1: =93Frames Exchange=94 to =93Frame Exchange=94 3. Section 4, =93The IEEE 802.11 WTP Profile message element allows t= he WTP to communicate the profile*(s)* it supports to the AC.=94 4. 4. The new MAC model is named =93Hybrid MAC profile=94. This name = is very general, and the description says that it is a specific profile of the split MAC, not a hybrid (as the current name suggests) of split and local.= =94 Suggest renaming =93Hybrid MAC=94 to =93Split MAC with WTP Encryption=94 (o= r similar) 5. 5. Section 5. The text is not clear: =93it could directly reference=94. Well it could, Make it reference the section or not. Change to =93There are no additional security considerations introduced by this specification in addition to those in [RFC5416]. 6. 6. Section 4 =96 add a period at the end of the first sentence aft= er =93one such message element=94. 7. 7. Abstract. Suggested edits below: The CAPWAP protocol defines two modes of operation for IEEE 802.11 WTPs: Split and Local MAC (medium access control), as described in [RFC5415], *and* [RFC5416]. Specifically, [RFC5416] describes in detail= the division of labor *functionality *between *the *WTP and AC in *both *the Split and Local MAC modes. Unfortunately, *tT**here* are many *some *functions that have no= t yet been clearly defined whether they belong *can be performed in either *to the WTP or the AC. For example*, in the Split MAC mode, * IEEE 802.11 encryption is specified as located in either in the AC or the WTP with no clear way to negotiate where it should be located. This lack of specification leads to interoperability *issues* between *an *AC and WTP when *the *AC and WTP come from different vendors. To solve this problem, this specification defines *a profile of the Split MAC mode, =93Split MAC with WTP Encryption=94 mode of operation and an* the concept of IEEE 802.11 MAC profile *message element used to negotiate the profile. *where each profile refers to a table containing an unambigous division of labor between WTP and AC. The *IEEE 802.11 MAC *profile *message element* is used as follows: the WTP informs the AC of the supported *profile(s*) and the AC selects the profile when it configures to be configured on the WTP. On Mon, Oct 14, 2013 at 7:46 AM, Rajesh Pazhyannur (rpazhyan) < rpazhyan@cisco.com> wrote: > Greetings=85 > > We have submitted a new version of the draft (previously titled =93Hybrid > MAC-Model for CAPWAP=94. > While solving the same problem as in the original draft, this takes a > different approach. We introduce a new element IEEE 802.11 MAC Profile. > This profile defines the functional split between the MAC and AC. The id= ea > of using profiles was based on discussion in the last working groups > meeting as well as offline meetings with other participants. While somewh= at > similar to mode defined in RFC 5416, this solves the problem with the > ambiguity in the mode definitions in RFC 5416 as well as enables differen= t > functional splits to be defined in the future. The link to the draft is * > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac* > > We are soliciting comments and feedback. > > Thanks > > Regards > > Rajesh > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > --001a11333a4e1255d904e9d07214 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Rajesh,

Comments below.

<= /div>Dorothy
-------------
1.=A0=A0=A0=A0=A0=A0 Today, Split and Local MAC are negotiated using the WTP MAC Type message e= lement. There is no need to include Local and Split MAC in the profile elem= ent. The new mode is actually a profile of the current defined Split MAC. I= n section 4, delete 0 and 1, renumber =932=94 to =930=94 and change from = =93indentified=94 to =93identified=94 in the line above.
Sectio= n 3.2 can be deleted, and Sections 3.1 and 3.3 combined into a single table= .
2.=A0=A0=A0=A0=A0 Section 3.3.1: =93Frames Exchange=94 to =93Frame Exchange=94
3.=A0=A0=A0=A0=A0=A0 <= /span>Section 4, =93The IEEE 802.11 WTP Profile message element all= ows the WTP to communicate the profile(s) it support= s to the AC.=94

4.=A0=A0=A0=A0=A0=A0 4. The new MAC model is named =93Hybrid MAC p= rofile=94. This name is very general, and the description says that it is a specific profile of the split MAC, not a hybrid (as the current name suggests) of split and local.= =94 Suggest renaming =93Hybrid MAC=94 to =93Split MAC with WTP Encryption=94 (o= r similar)

5.=A0=A0=A0=A0=A0=A0 5. Section 5. The text is not clear: =93it co= uld directly reference=94. Well it could, Make it reference the section or not.
Change to =93There are no additional security considerations introduced by = this specification in addition to those in [RFC5416].

6.=A0=A0=A0=A0=A0=A0 6. Section 4 =96 add a period at the end of t= he first sentence after =93one such message element=94.

7.=A0=A0=A0=A0=A0=A0 7. Abstract. Suggested edits below: 

The CAPWAP protocol defines two modes of operat=
ion for IEEE 802.11
=A0=A0 WTPs: Sp=
lit and Local MAC (medium access control), as described in
=A0=A0 [RFC5415], and [RFC5416].=A0 S=
pecifically, [RFC5416] describes in detail the
=A0=A0=
 division of labor functionality between the WTP and A=
C in both the Split and Local MAC
=A0=A0=
 modes.=A0 Unfortunately, tThere are many so=
me functions that have not yet
=A0=
=A0 been clearly defined whether they belong can be performed in ei=
ther to the WTP or the AC.=A0 For
=A0=A0 example, in the Split MAC mode, =
=A0IEEE 802.11 encryption is specified as located in either in
= 
=A0=A0=
 the AC or the WTP with no clear way to negotiate where it should be=

=A0=A0 located.=A0 This lack of specifica=
tion leads to interoperability issues
=A0=A0 between an AC and WTP when the=
 AC and WTP come from different vendors.=A0 To
=A0=A0=
 solve this problem, this specification defines a profile of the Split M=
AC mode, =93Split MAC with WTP Encryption=94 mode of operation and an <=
s>the concept of IEEE
=A0=A0 802.11 MAC profile message element us=
ed to negotiate the profile. where each profile refers to a table co=
ntaining an
=A0=A0 unambigous division of labor between =
WTP and AC.=A0 The IEEE 802.11 MAC profile message element is used
=A0=A0 as follows: the WTP informs the AC of th=
e supported profile(s) and the
=A0=A0=
 AC selects the profile when it configures to be configured o=
n the WTP.

=A0

=A0




On = Mon, Oct 14, 2013 at 7:46 AM, Rajesh Pazhyannur (rpazhyan) <rpazhyan@cisc= o.com> wrote:
Greetings=85
=A0
We have submitted a new version of the draft (previously titled =93Hyb= rid MAC-Model for CAPWAP=94.
While solving the same problem as in the original draft, this takes a different app= roach. We introduce a new element IEEE 802.11 MAC Profile. This profile def= ines the functional split between the MAC and AC.=A0 The idea of using profiles was based on discussion in the la= st working groups meeting as well as offline meetings with other participan= ts. While somewhat similar to mode defined in RFC 5416, this solves the pro= blem with the ambiguity in the mode definitions in RFC 5416 as well as enables different functional splits to b= e defined in the future. Th= e link to the draft is https://datatracker.ietf= .org/doc/draft-ietf-opsawg-capwap-hybridmac
=A0
We are soliciting comments and feedback.
=A0
Thanks
=A0
Regards
=A0
Rajesh
=A0

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


--001a11333a4e1255d904e9d07214-- From dromasca@avaya.com Tue Oct 29 08:26:15 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B1721F9EC8 for ; Tue, 29 Oct 2013 08:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HHeyvdSoVIh for ; Tue, 29 Oct 2013 08:26:08 -0700 (PDT) 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 9B35811E82CE for ; Tue, 29 Oct 2013 08:26:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQNAN3Sb1KHCzI1/2dsb2JhbABZgkMjIThUqk2CO4lmiEeBKhZ0giUBAQEBAxIbXAIBCA0EAQMBAQsdBzIUAwYIAQEEARIIEweHZQEMnGCdFBePFjcBBoMZgQ0DmTmFNIslgWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,593,1378872000"; d="scan'208,217";a="34472452" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Oct 2013 11:26:07 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 29 Oct 2013 11:16:27 -0400 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.0146.000; Tue, 29 Oct 2013 16:26:06 +0100 From: "Romascanu, Dan (Dan)" To: "Rajesh Pazhyannur (rpazhyan)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" Thread-Index: Ac7SqIs8II5D0brnRoyCTVQ6wZ7WWACEPwyw Date: Tue, 29 Oct 2013 15:26:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1291C9C0@AZ-FFEXMB04.global.avaya.com> References: <4ED2E36A22261145861BAB2C24088B4320ED015B@xmb-aln-x09.cisco.com> In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320ED015B@xmb-aln-x09.cisco.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_9904FB1B0159DA42B0B887B7FA8119CA1291C9C0AZFFEXMB04globa_" MIME-Version: 1.0 Subject: Re: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 15:26:15 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA1291C9C0AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I read the I-D and I have some clarification questions: - If tunneling using the new modes described in this document is g= oing to be possible to endpoints different from the AC, is it expected for = these endpoints to run all the discovery and advertising protocols? This se= ems to be a change from the traditional CAPWAP architecture that may have s= calability and security implications - at least this needs to be prompted a= nd discussed. At this point the document does not even mention that it upda= tes RFC 5415 and RFC 5416. - What is the advantage of tunneling non-management data frames us= ing the new encapsulation modes vs. bridging them using the local bridging = mode in RFC 5416? The document needs to explain this. - Why does the document take the approach of defining a new altern= ate tunnel encapsulation message? Would it not be possible to define new va= lues in the Tunnel Mode enumeration defined in Section 6.1 of RFC 5416? Thanks and Regards, Dan From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Rajesh Pazhyannur (rpazhyan) Sent: Sunday, October 27, 2013 2:08 AM To: opsawg@ietf.org Subject: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for= Data Frames in CAPWAP" Hello We have resubmitted a new version of the draft titled "Alternate Tunnel Enc= apsulation for Data Frames in CAPWAP", http://datatracker.ietf.org/doc/draf= t-zhang-opsawg-capwap-cds/. The previous version was titled: "Separation of CAPWAP Control and Data Pla= ne: Scenarios, Requirements and Solutions". Based on discussion in the last= IETF, we reworked the draft. The draft provides a reason for the need for WTP to have additional tunnel = (beyond CAPWAP) encapsulations for user traffic. It enables a WTP to advert= ise the capability to support such alternate tunnel encapsulation and the A= C to configure such tunnel encapsulation on the WTP. The alternate tunnel = encapsulation allows 1) the WTP to tunnel non-management data frames to an = endpoint different from the AC and 2) allows the WTP to tunnel using one of= many known ecapsulation types such as IP-IP, IP-GRE, CAPWAP. We would like to get it adopted as a working group item and would like feed= back on whether we are on track. Regards Rajesh --_000_9904FB1B0159DA42B0B887B7FA8119CA1291C9C0AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I read the I-D and I have= some clarification questions:

- =          If tunneling using the new modes described in this document is goin= g to be possible to endpoints different from the AC, is it expected for these endpoints to run all the discovery and advertising p= rotocols? This seems to be a change from the traditional CAPWAP architectur= e that may have scalability and security implications – at least this= needs to be prompted and discussed. At this point the document does not even mention that it updates RFC 5415 and= RFC 5416.

- =          What is the advantage of tunneling non-management data frames using= the new encapsulation modes vs. bridging them using the local bridging mode in RFC 5416? The document needs to explain this.  = ;

- =          Why does the document take the approach of defining a new alternate= tunnel encapsulation message? Would it not be possible to define new values in the Tunnel Mode enumeration defined in Section 6.1= of RFC 5416?  

 <= /p>

Thanks and Regards,<= /o:p>

 <= /p>

Dan

 <= /p>

 <= /p>

From: opsawg-b= ounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Rajesh Pazhyannur (rpazhyan)
Sent: Sunday, October 27, 2013 2:08 AM
To: opsawg@ietf.org
Subject: [OPSAWG] Seeking discussion on "Alternate Tunnel Encap= sulation for Data Frames in CAPWAP"

 

Hello

 

= We have resubmitted a new version of the draft titled “Alternate Tunn= el Encapsulation for Data Frames in CAPWAP", = http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/.

= The previous version was titled: “Separation of CAPWAP Control and Data Plane: Scenarios, Requirem= ents and Solutions”. Based on discussion in the last IETF, we reworke= d the draft.

=  

= The draft provides a reason for the need for WTP to have additional tunnel = (beyond CAPWAP) encapsulations for user traffic. It enables a WTP to advert= ise the capability to support such alternate tunnel encapsulation and the AC to configure such tunnel encapsulation on the WTP= .  The alternate tunnel encapsulation allows 1) the WTP to tunnel non-= management data frames to an endpoint different from the AC and 2) allows t= he WTP to tunnel using one of many known ecapsulation types such as IP-IP, IP-GRE, CAPWAP.=

 

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

=  

= Regards

=  

= Rajesh

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA1291C9C0AZFFEXMB04globa_-- From melinda.shore@gmail.com Tue Oct 29 09:55:33 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C723C21F9D9C for ; Tue, 29 Oct 2013 09:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVVndcE7M62d for ; Tue, 29 Oct 2013 09:55:33 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id D247D21F9C70 for ; Tue, 29 Oct 2013 09:52:51 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo5so115003pbc.9 for ; Tue, 29 Oct 2013 09:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=EYII7Wyq98qg/wr0GGyV9FAN1EpgF2cryUVtJw61ThA=; b=w/qcWscur06GOhTF2P+5HcT+KC4049iGvtVj/P6aBp+FQIPZhhiI6X5XFZDafT8s2p jfNbm0VQbsod02+J9q0oRedlaKcskZXpzvApE7TWwNOnUVagizVhUBi2zEcOIfij1c7R mnWk7IecNrKZlT//q9U1Djq+P82mCStDlvgvsVFSTq3EZIuqjgRxbzy/xzt70dykcymO toziU9S1fI/bCuAz/p7TkxwCYj8tosR3kRz2vtA9nNOvQwGDwQZSRhgmyEnSK5KQVdU9 2ZF+A5iUxxOwPDmXiVzZfeAi++1e3ciVFt4QrQj0yyy2aP3udNQbMKr+g586cC++1i0M 6PNw== X-Received: by 10.66.216.129 with SMTP id oq1mr1310061pac.75.1383065255647; Tue, 29 Oct 2013 09:47:35 -0700 (PDT) Received: from spandex.local (63-140-94-250.dynamic.dsl.acsalaska.net. [63.140.94.250]) by mx.google.com with ESMTPSA id sd3sm35939994pbb.42.2013.10.29.09.47.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 09:47:33 -0700 (PDT) Message-ID: <526FE6A3.8040904@gmail.com> Date: Tue, 29 Oct 2013 08:47:31 -0800 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" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Draft agenda X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:55:34 -0000 I've uploaded a first crack at an agenda for our session next Tuesday. If you've got a slot, please start thinking about getting your slides together. The agenda is online, here: http://www.ietf.org/proceedings/88/agenda/agenda-88-opsawg Melinda From dromasca@avaya.com Tue Oct 29 10:00:02 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF31421E8097 for ; Tue, 29 Oct 2013 10:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.797 X-Spam-Level: X-Spam-Status: No, score=-102.797 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJrWYzgv0O+N for ; Tue, 29 Oct 2013 09:59:56 -0700 (PDT) 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 E2E2921E805D for ; Tue, 29 Oct 2013 09:41:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIGAHbkb1KHCzI1/2dsb2JhbABZgmYhgQy/NYEqFm0HgicBAQMSKDEgARUVFEImAQQbGodlAZgzhEidJY8Wg1eBDQOebYslgyaCKg X-IronPort-AV: E=Sophos;i="4.93,594,1378872000"; d="scan'208";a="34488916" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Oct 2013 12:41:39 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 29 Oct 2013 12:31:59 -0400 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.0146.000; Tue, 29 Oct 2013 17:41:37 +0100 From: "Romascanu, Dan (Dan)" To: "opsawg@ietf.org" Thread-Topic: review of draft-ietf-opsawg-capwap-extension-01 Thread-Index: Ac7Uxbxsbvp4u1PTST6j98tJtfEcSA== Date: Tue, 29 Oct 2013 16:41:38 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1291CAE4@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 17:00:03 -0000 Hi, I have read draft-ietf-opsawg-capwap-extension-01. I am no expert in IEEE 8= 02.11 technology, so I cannot confirm the accuracy of the .11-related infor= mation in this I-D. It looks like straight forward and consistent work, but= it needs review from the IEEE experts as long as several editorial improve= ments.=20 Here are my comments (mostly editorial, but important to make the document = readable and usable):=20 1. The document obviously updated RFC 5416. This needs to be mentioned in t= he Header. Moreover, there must be some information about the migration or = coexistence from a previous CAPWAP environment that did not support IEEE 80= 2.11n and a new environment that supports .11n and the CAPWAP extensions de= fined in this document 2. The document needs a section of abbreviations - expand and explain if ne= cessary what OFDM, MIMO, etc. mean 3. There is a need of cleaning the English syntax - preferable by a native = English speaker.=20 4. Keywords need to be used in a manner that is consistent and conforms to = RFC 2119. For example the 'may' in the first paragraph of Section 4.2, or i= n the first paragraph of section 4.3 need to be capitalized.=20 5. Some of the fields need to have the units for the parameters added - e.g= . MaxRxFactor, Min StaSpacing, HiSuppDataRate 6. In Section 5.3 I could not understand what 'Report Count: The channel nu= mber will be reported' - is it a number or a count?=20 Thanks and Regards, Dan From melinda.shore@gmail.com Tue Oct 29 21:32:25 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F0B21E80E7 for ; Tue, 29 Oct 2013 21:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mh3UlF16Lf9 for ; Tue, 29 Oct 2013 21:32:23 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9762C11E81CB for ; Tue, 29 Oct 2013 21:32:22 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id mc17so815483pbc.35 for ; Tue, 29 Oct 2013 21:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=q9ZCKRlfnYuBSir2Tl0AfOYQ7rAJV2yka+55QVTcqOc=; b=HrVrWA210flVN6CbbHEQkFGx3f1DtR9FFBlz8QKbLZX8TGydGmFfy1buFqq3R2zjYe PnHo9FqUgSGeyM/dC0p1PJcZC8+8lt9iKVTYjHaIbLpW96OLZQteYpjP7d0ohetloX82 HT+GkAsofy3e/0zEMsTfSJI9Burq6q/BPCT/wWtSFm9bU6JHkWi0NC88lgOIREnRgek4 pSl5TOCzM3FTbSjCvyFUtof4TkgVW4MkD25Rm1feprEYwHEGhTrOWGO9skblDi/i7Hpa bm+Dynae7YPJec9TIJ/6ONXOU1cxZFLgcSxD3+gMQ3Lgq2oFOfw3x3Dlw51cAR67PBi7 MCKw== X-Received: by 10.68.234.165 with SMTP id uf5mr3071136pbc.41.1383107542266; Tue, 29 Oct 2013 21:32:22 -0700 (PDT) Received: from spandex.local (63-140-94-250.dynamic.dsl.acsalaska.net. [63.140.94.250]) by mx.google.com with ESMTPSA id hi5sm16568070pbb.43.2013.10.29.21.32.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 21:32:21 -0700 (PDT) Message-ID: <52708BD2.6010209@gmail.com> Date: Tue, 29 Oct 2013 20:32:18 -0800 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" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Call for adoption, draft-asai-vmm-mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 04:32:25 -0000 We are starting a call for working group adoption of "Management Information Base for Virtual Machines Controlled by a Hypervisor," https://datatracker.ietf.org/doc/draft-asai-vmm-mib/. This document has received extensive discussion on the opsawg mailing list and is on its 5th revision, and we believe it meets the criteria for consideration for adoption laid out by Benoit at IETF 86: 1. reach out to other people for review, 2. potentially put the bar higher for WG adoption 3. solicit reviews from chairs and AD 4. if no feedback, kill it. Demonstrate support. We've also allowed some time for discussion during the meeting session next Tuesday. We will be assessing consensus on Wednesday, 13 November. Please review the current version of the document, let us know whether or not you support adoption, and raise any issues you've identified. Thanks, Melinda, Scott, Warren From jclarke@cisco.com Tue Oct 29 21:47:16 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A5821F9AE3 for ; Tue, 29 Oct 2013 21:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09NHdIU9ZigM for ; Tue, 29 Oct 2013 21:47:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0AE21F9AE7 for ; Tue, 29 Oct 2013 21:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1394; q=dns/txt; s=iport; t=1383108420; x=1384318020; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=XlwmRhTljypeqVld/8yKb+5/SGwB5AkzdJCvnx5w9wo=; b=m4VKB0GkWFXUxy5beXSUTokeWqQswzx847e0jsSCqbp4+Xh2O1OGhhmO nO3MKaomK9C2lL+8SBz3Cwoe63VPm8uigvF4l9rIg7BmSf9nV3D/Oq65b Qv0oBppDiU3JGDNgzVe5crbWBRt+pLPifo6pDVpQJ0v4JMn3EBvHpC6Xh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAN6NcFKtJXG8/2dsb2JhbABWA4MHOMAUgSMWdIIlAQEBBB0bNgoPAgsYCRYPCQMCAQIBCTwGAQwGAgEBiAMNulsEBI4CgTkXEYQbA5gKkgmDQiCBNQ X-IronPort-AV: E=Sophos;i="4.93,598,1378857600"; d="scan'208";a="278292529" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 30 Oct 2013 04:46:48 +0000 Received: from rtp-jclarke-89110.cisco.com (rtp-jclarke-89110.cisco.com [10.117.46.171]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9U4kmco003931; Wed, 30 Oct 2013 04:46:48 GMT Message-ID: <52708F37.6030606@cisco.com> Date: Wed, 30 Oct 2013 00:46:47 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Melinda Shore , "opsawg@ietf.org" References: <52708BD2.6010209@gmail.com> In-Reply-To: <52708BD2.6010209@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] Call for adoption, draft-asai-vmm-mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 04:47:17 -0000 On 10/30/13, 12:32 AM, Melinda Shore wrote: > We are starting a call for working group adoption of > "Management Information Base for Virtual Machines Controlled > by a Hypervisor," https://datatracker.ietf.org/doc/draft-asai-vmm-mib/. > This document has received extensive discussion on the opsawg > mailing list and is on its 5th revision, and we believe it meets > the criteria for consideration for adoption laid out by > Benoit at IETF 86: > > 1. reach out to other people for review, > 2. potentially put the bar higher for WG adoption > 3. solicit reviews from chairs and AD > 4. if no feedback, kill it. Demonstrate support. > > We've also allowed some time for discussion during the > meeting session next Tuesday. > > We will be assessing consensus on Wednesday, 13 November. > Please review the current version of the document, let us > know whether or not you support adoption, and raise any > issues you've identified. I have reviewed the document, and I support adoption. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From rpazhyan@cisco.com Tue Oct 29 22:32:31 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E7B21F9FAC for ; Tue, 29 Oct 2013 22:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcR+zRWqcYFl for ; Tue, 29 Oct 2013 22:32:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0457A11E820C for ; Tue, 29 Oct 2013 22:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31589; q=dns/txt; s=iport; t=1383111146; x=1384320746; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DRBJKIOPRq6aDecVrKiROFkvNwcoZD2GmYht58u5r2I=; b=fSJ4s/A7dQajb9VJYxz2WEJ8vLAQgyZPUUf6CRmpGGXWN1AiIOg+sMqa RoIlOmDTvZVUKAq/o933PCT8Gzv8A6NeQ0KBJFeB3vJDFaOnV09pgwoKf noukuTIXt0kMmm7RwrR3DVx1V4nOdLcI1KE9LjIhgvA6kNH8t6pe4xRq3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsHALOYcFKtJXG//2dsb2JhbABZgkNEOFStE4loiEeBIxZ0giUBAQEELVwCAQgRAQMBAQsWAQYHMhQDBggBAQQBEggTh2wNumWPHjcBBoMZgQ0DmTmQWoFogT6CKg X-IronPort-AV: E=Sophos;i="4.93,599,1378857600"; d="scan'208,217";a="278401924" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 30 Oct 2013 05:32:24 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9U5WOkR014136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 05:32:24 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.202]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 00:32:24 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" Thread-Index: Ac7SqIs8II5D0brnRoyCTVQ6wZ7WWACEPwywAB31AxA= Date: Wed, 30 Oct 2013 05:32:23 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320ED1291@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320ED015B@xmb-aln-x09.cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA1291C9C0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1291C9C0@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.89] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320ED1291xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: Re: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 05:32:31 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320ED1291xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan Thanks for the review. Really appreciate it. Some immediate comments and we can follow up more live at the meeting next = week. Regards Rajesh - If tunneling using the new modes described in this document is g= oing to be possible to endpoints different from the AC, is it expected for = these endpoints to run all the discovery and advertising protocols? No, we don't expect to run the discovery and advertising protocols. We do p= lan to update the draft with an additional message element that will be sen= t by the AC to the WTP that will contain information about how the WTP can = establish a tunnel (e.g., IP addresses, shared secret required if any, etc)= . Additionally, a number of tunneling protocols being considered like L2TPv= 3, PMIPv6 have their own control protocol to setup and tear down tunnels. T= he AC, simply, assists in providing the WTP with configuration information = to initiate the control signaling. - This seems to be a change from the traditional CAPWAP architectu= re that may have scalability and security implications - at least this need= s to be prompted and discussed. I don't think we are necessarily changing the CAPWAP architecture. This was= the key feedback we received on the last draft. As a result, we have kept = the CAPWAP architecture almost intact. As far as the AC is concerned, the = WTP behaves almost identical to a local bridging is concerned, in the sense= that the AC will not see any user traffic. The difference however is that = traffic is not locally bridged but actually tunneled to a different endpoin= t. If you think about it, a WTP can do this (without any changes to CAPWAP)= and the AC-WTP interaction would work just fine. The reason to suggest the= changes in the draft is that given the AC is configuring all the WTP param= eters, it would be quite useful to extend CAPWAP to configure the alternate= /additional tunnel parameter. On the security front, note that the CAPWAP data channel encryption is opti= onal. Currently, our position is that if user traffic needs to be secured t= hen it can be handled via additional mechanism like IPSec. For example, L2T= P, PMIPv6/GRE all provide for an additional IPSec encapsulation. At this point the document does not even mention that it updates RFC 5415 a= nd RFC 5416. Yes, noted. We will address it. - What is the advantage of tunneling non-management data frames us= ing the new encapsulation modes vs. bridging them using the local bridging = mode in RFC 5416? The document needs to explain this. I had hoped to provide the motivation for this in Section 1 (espec= ially via the figures 1 and 2). Perhaps I can be more descriptive in the ne= xt version. The main motivation is to separate the AC from the entity that handles the = user traffic tunnels as well enable one of multitude of tunneling protocols= for user traffic. There is still a requirement to tunnel and as result, lo= cal bridging is not an easy option. The options are either tunneled to AC o= r as we propose, tunnel to a different element. - Why does the document take the approach of defining a new altern= ate tunnel encapsulation message? Would it not be possible to define new va= lues in the Tunnel Mode enumeration defined in Section 6.1 of RFC 5416? Tunnel modes as defined today define tunnels between the WTP and AC. In= the current draft, we are proposing an additional tunnel between tunnel an= d an endpoint other than AC. Also, the tunnel mode is being used to indicat= e that the user traffic is *not* being tunneled to the AC. So all in all, i= t seemed easier to define a new element rather than reuse/overload an exist= ing one. From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, October 29, 2013 8:26 AM To: Rajesh Pazhyannur (rpazhyan); opsawg@ietf.org Subject: RE: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation= for Data Frames in CAPWAP" Hi, I read the I-D and I have some clarification questions: - If tunneling using the new modes described in this document is g= oing to be possible to endpoints different from the AC, is it expected for = these endpoints to run all the discovery and advertising protocols? This se= ems to be a change from the traditional CAPWAP architecture that may have s= calability and security implications - at least this needs to be prompted a= nd discussed. At this point the document does not even mention that it upda= tes RFC 5415 and RFC 5416. - What is the advantage of tunneling non-management data frames us= ing the new encapsulation modes vs. bridging them using the local bridging = mode in RFC 5416? The document needs to explain this. - Why does the document take the approach of defining a new altern= ate tunnel encapsulation message? Would it not be possible to define new va= lues in the Tunnel Mode enumeration defined in Section 6.1 of RFC 5416? Thanks and Regards, Dan From: opsawg-bounces@ietf.org [mailto:opsaw= g-bounces@ietf.org] On Behalf Of Rajesh Pazhyannur (rpazhyan) Sent: Sunday, October 27, 2013 2:08 AM To: opsawg@ietf.org Subject: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for= Data Frames in CAPWAP" Hello We have resubmitted a new version of the draft titled "Alternate Tunnel Enc= apsulation for Data Frames in CAPWAP", http://datatracker.ietf.org/doc/draf= t-zhang-opsawg-capwap-cds/. The previous version was titled: "Separation of CAPWAP Control and Data Pla= ne: Scenarios, Requirements and Solutions". Based on discussion in the last= IETF, we reworked the draft. The draft provides a reason for the need for WTP to have additional tunnel = (beyond CAPWAP) encapsulations for user traffic. It enables a WTP to advert= ise the capability to support such alternate tunnel encapsulation and the A= C to configure such tunnel encapsulation on the WTP. The alternate tunnel = encapsulation allows 1) the WTP to tunnel non-management data frames to an = endpoint different from the AC and 2) allows the WTP to tunnel using one of= many known ecapsulation types such as IP-IP, IP-GRE, CAPWAP. We would like to get it adopted as a working group item and would like feed= back on whether we are on track. Regards Rajesh --_000_4ED2E36A22261145861BAB2C24088B4320ED1291xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan

 <= /p>

Thanks for the review. &n= bsp;Really appreciate it.

Some immediate comments a= nd we can follow up more live at the meeting next week.

 <= /p>

Regards=

 <= /p>

Rajesh<= /p>

 <= /p>

 <= /p>

- =          If tunneling usin= g the new modes described in this document is going to be possible to endpo= ints different from the AC, is it expected for these endpoints to run all the discovery and advertising protocols?

 <= /span>

No, we don’t expect to run th= e discovery and advertising protocols. We do plan to update the draft with = an additional message element that will be sent by the AC to the WTP that will contain information about how the WTP can establish a tunnel= (e.g., IP addresses, shared secret required if any, etc). Additionally, a = number of tunneling protocols being considered like L2TPv3, PMIPv6 have the= ir own control protocol to setup and tear down tunnels. The AC, simply, assists in providing the WTP with c= onfiguration information to initiate the control signaling.

 <= /span>

- =          This seems to be = a change from the traditional CAPWAP architecture that may have scalability= and security implications – at least this needs to be prompted and discussed.

 <= /span>

I don’t thin= k we are necessarily changing the CAPWAP architecture. This was the key fee= dback we received on the last draft. As a result, we have kept the CAPWAP architecture almost intact.  As far as the AC is concerned= , the WTP behaves almost identical to a local bridging is concerned, in the= sense that the AC will not see any user traffic. The difference however is= that traffic is not locally bridged but actually tunneled to a different endpoint. If you think about it, a WT= P can do this (without any changes to CAPWAP) and the AC-WTP interaction wo= uld work just fine. The reason to suggest the changes in the draft is that = given the AC is configuring all the WTP parameters, it would be quite useful to extend CAPWAP to configure= the alternate/additional tunnel parameter.

 <= /span>

On the security fr= ont, note that the CAPWAP data channel encryption is optional. Currently, o= ur position is that if user traffic needs to be secured then it can be handled via additional mechanism like IPSec. For example, L= 2TP, PMIPv6/GRE all provide  for an additional IPSec encapsulation. &n= bsp; 

 <= /span>

At this point the = document does not even mention that it updates RFC 5415 and RFC 5416.  = ;

Yes, noted.  We will address i= t.

 <= /p>

- =          What is the advan= tage of tunneling non-management data frames using the new encapsulation mo= des vs. bridging them using the local bridging mode in RFC 5416? The document needs to explain this.  

 <= /span>

    &= nbsp;    I had hoped to provide the motivation for this in Section 1 = (especially via the figures 1 and 2). Perhaps I can be more descriptive in = the next version.

The main motivation is to separate the AC = from the entity that handles the user traffic tunnels as well enable one of= multitude of tunneling protocols for user traffic. There is still a requirement to tunnel and as result, local bridging is not an e= asy option. The options are either tunneled to AC or as we propose, tunnel = to a different element.    

- =          Why does the docu= ment take the approach of defining a new alternate tunnel encapsulation mes= sage? Would it not be possible to define new values in the Tunnel Mode enumeration defined in Section 6.1 of RFC 5416?  

 

    Tunnel modes as defined today define tunnels between the W= TP and AC. In the current draft, we are proposing an additional tunnel betw= een tunnel and an endpoint other than AC. Also, the tunnel mode is being used to indicate that the user traffic is *not* being= tunneled to the AC. So all in all, it seemed easier to define a new elemen= t rather than reuse/overload an existing one.

 

 

 

From: Romascan= u, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Tuesday, October 29, 2013 8:26 AM
To: Rajesh Pazhyannur (rpazhyan); opsawg@ietf.org
Subject: RE: [OPSAWG] Seeking discussion on "Alternate Tunnel E= ncapsulation for Data Frames in CAPWAP"

 

Hi,

 <= /p>

I read the I-D and I have= some clarification questions:

 <= /p>

- =          If tunneling usin= g the new modes described in this document is going to be possible to endpo= ints different from the AC, is it expected for these endpoints to run all the discovery and advertising protocols? This seems to be a cha= nge from the traditional CAPWAP architecture that may have scalability and = security implications – at least this needs to be prompted and discus= sed. At this point the document does not even mention that it updates RFC 5415 and RFC 5416.

- =          What is the advan= tage of tunneling non-management data frames using the new encapsulation mo= des vs. bridging them using the local bridging mode in RFC 5416? The document needs to explain this.  

- =          Why does the docu= ment take the approach of defining a new alternate tunnel encapsulation mes= sage? Would it not be possible to define new values in the Tunnel Mode enumeration defined in Section 6.1 of RFC 5416?  

 <= /p>

Thanks and Regards,<= /o:p>

 <= /p>

Dan

 <= /p>

 <= /p>

From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Rajesh Pazhyannur (rpazhyan)
Sent: Sunday, October 27, 2013 2:08 AM
To: opsawg@ietf.org
Subject: [OPSAWG] Seeking discussion on "Alternate Tunnel Encap= sulation for Data Frames in CAPWAP"

 

Hello

 

= We have resubmitted a new version of the draft titled “Alternate Tunn= el Encapsulation for Data Frames in CAPWAP", = http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/.

= The previous version was titled: “Separation of CAPWAP Control and Data Plane: Scenarios, Requirem= ents and Solutions”. Based on discussion in the last IETF, we reworke= d the draft.

=  

= The draft provides a reason for the need for WTP to have additional tunnel = (beyond CAPWAP) encapsulations for user traffic. It enables a WTP to advert= ise the capability to support such alternate tunnel encapsulation and the AC to configure such tunnel encapsulation on the WTP= .  The alternate tunnel encapsulation allows 1) the WTP to tunnel non-= management data frames to an endpoint different from the AC and 2) allows t= he WTP to tunnel using one of many known ecapsulation types such as IP-IP, IP-GRE, CAPWAP.=

 

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

=  

= Regards

=  

= Rajesh

 

 

--_000_4ED2E36A22261145861BAB2C24088B4320ED1291xmbalnx09ciscoc_-- From victor@jvknet.com Wed Oct 30 16:38:34 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C9B21E8173 for ; Wed, 30 Oct 2013 16:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PwzYtB1netp for ; Wed, 30 Oct 2013 16:38:29 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 120CA21E8143 for ; Wed, 30 Oct 2013 16:38:09 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q58so1977860wes.17 for ; Wed, 30 Oct 2013 16:38:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QknqHyepmoqtIx8dypzIWHtFQqmPcQZHdVU964uDMYE=; b=PjbNjyKOTQu67czrJqzUWDdYuOd5QLbCwjbmB7Go4asNSxmvbSFw3cdyD7jFPx9TFo XDZqDGroA9vf7MSD32DCiku2EsUtrNwtKfUqOeNBB5eeiKqTq+5rYukPOMIR7+bNfjIp dy4HHZVD1cFS3ei71RNuJeIPd6wmEwHoaScNFpAbGmN5NHWMcf6/mjg7yoQMWWBZeaRE ZErH25KhfieehGsKhmQg+vUk+E9LC6fQa5N12JqDR2DE5RRBIQpwdyRMYyA8G6HKWpJ2 f2Kq2/CHskvNHlWOp8OrUHjh927uU1mD7gW62Io1Vnu+awzSDlpGUVXrjNAGQjZ6+kdj lZdw== X-Gm-Message-State: ALoCoQkSmHO0ulxbA7czkx84xjHouDIO3ZuQlSjJLX1rEyCK1+BT0tkvueEhK7x8YAk7qxTDsYdG MIME-Version: 1.0 X-Received: by 10.180.185.130 with SMTP id fc2mr4128758wic.43.1383176288994; Wed, 30 Oct 2013 16:38:08 -0700 (PDT) Received: by 10.216.240.6 with HTTP; Wed, 30 Oct 2013 16:38:08 -0700 (PDT) In-Reply-To: <52708BD2.6010209@gmail.com> References: <52708BD2.6010209@gmail.com> Date: Wed, 30 Oct 2013 19:38:08 -0400 Message-ID: From: Victor Kuarsingh To: Melinda Shore Content-Type: multipart/alternative; boundary=001a11c350da5e1bce04e9fdd393 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for adoption, draft-asai-vmm-mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 23:38:34 -0000 --001a11c350da5e1bce04e9fdd393 Content-Type: text/plain; charset=ISO-8859-1 Melinda, I have also reviewed [most] the document and also support it adoption. I did not complete a very detailed review (yet) of section 3.3's definition. Reasons for support (1). Document addresses area of operational concern (management of virtual machines) (2). Based on updates even from last version (-04), the authors have put in significant work to mature draft content and text (3). This is also a good time to get an expanded set of eyes to review content (i.e. OID structure and MIB definitions) and verify content is complete (appears so) regards, Victor K On Wed, Oct 30, 2013 at 12:32 AM, Melinda Shore wrote: > We are starting a call for working group adoption of > "Management Information Base for Virtual Machines Controlled > by a Hypervisor," https://datatracker.ietf.org/doc/draft-asai-vmm-mib/. > This document has received extensive discussion on the opsawg > mailing list and is on its 5th revision, and we believe it meets > the criteria for consideration for adoption laid out by > Benoit at IETF 86: > > 1. reach out to other people for review, > 2. potentially put the bar higher for WG adoption > 3. solicit reviews from chairs and AD > 4. if no feedback, kill it. Demonstrate support. > > We've also allowed some time for discussion during the > meeting session next Tuesday. > > We will be assessing consensus on Wednesday, 13 November. > Please review the current version of the document, let us > know whether or not you support adoption, and raise any > issues you've identified. > > Thanks, > > Melinda, Scott, Warren > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a11c350da5e1bce04e9fdd393 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Melinda,

I have also reviewed [most] th= e document and also support it adoption. =A0I did not complete a very detai= led review (yet) of section 3.3's definition.

= Reasons for support
(1). Document addresses area of operational concern (management of virtual = machines)
(2). Based on updates even from last version (-04), the= authors have put in significant work to mature draft content and text
(3). This is also a good time to get an expanded set of eyes to review= content (i.e. OID structure and MIB definitions) and verify content is com= plete (appears so)


regards,

Victor K




On Wed, Oct 30, 20= 13 at 12:32 AM, Melinda Shore <melinda.shore@gmail.com> wrote:
We are starting a call for working group ado= ption of
"Management Information Base for Virtual Machines Controlled
by a Hypervisor," https://datatracker.ietf.org/doc/draft-asai-= vmm-mib/.
This document has received extensive discussion on the opsawg
mailing list and is on its 5th revision, and we believe it meets
the criteria for consideration for adoption laid out by
Benoit at IETF 86:

=A0 =A0 =A0 =A0 1. reach out to other people for review,
=A0 =A0 =A0 =A0 2. potentially put the bar higher for WG adoption
=A0 =A0 =A0 =A0 3. solicit reviews from chairs and AD
=A0 =A0 =A0 =A0 4. if no feedback, kill it. Demonstrate support.

We've also allowed some time for discussion during the
meeting session next Tuesday.

We will be assessing consensus on Wednesday, 13 November.
Please review the current version of the document, let us
know whether or not you support adoption, and raise any
issues you've identified.

Thanks,

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

--001a11c350da5e1bce04e9fdd393-- From John.Kaippallimalil@huawei.com Wed Oct 30 20:15:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A44921E80B9 for ; Wed, 30 Oct 2013 20:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhnKMYTtr3iM for ; Wed, 30 Oct 2013 20:15:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B5E7111E81F5 for ; Wed, 30 Oct 2013 20:15:16 -0700 (PDT) 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 AZR98571; Thu, 31 Oct 2013 03:15:15 +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; Thu, 31 Oct 2013 03:14:37 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Oct 2013 03:14:59 +0000 Received: from DFWEML511-MBB.china.huawei.com ([169.254.4.153]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Wed, 30 Oct 2013 20:14:56 -0700 From: John Kaippallimalil To: "Rajesh Pazhyannur (rpazhyan)" , "opsawg@ietf.org" Thread-Topic: Could you help review and comments the updated CAPWAP draft Thread-Index: Ac7UpP2yssHBL8S3TiqkLZR4EOWsNgAYwINgACQUEYAAAAgAEA== Date: Thu, 31 Oct 2013 03:14:56 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171CFD569B@dfweml511-mbb.china.huawei.com> References: <470F27D1263A1B4EB73491ED995DE62525856226@NKGEML512-MBS.china.huawei.com> <6561EABF52675C45BCDACA1B4D7AA1171CFD5565@dfweml511-mbb.china.huawei.com> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171CFD5565@dfweml511-mbb.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OPSAWG] Could you help review and comments the updated CAPWAP draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 03:15:21 -0000 SGksDQpJJ3ZlIHJlYWQgdGhpcyBkcmFmdCBhbmQgYWdyZWUgd2l0aCB0aGUgcmVxdWlyZW1lbnRz IGlkZW50aWZpZWQgYW5kIHNvbHV0aW9uIHRvIHR1bm5lbCB0byBhbiBBUiwgZXRjLiBUaGVyZSBp cyBhIG5lZWQgdG8gaGF2ZSB0aGUgcmlnaHQgbWVhbnMgYnkgd2hpY2ggdGhlIEFDLCBXVFAgYW5k IEFSIGRpc2NvdmVyLCBzeW5jIHVwIG9uIHR1bm5lbHMsIGV0Yy4NCg0KU29tZSBxdWVzdGlvbnMg Zm9yIGNsYXJpZmljYXRpb246DQoxLiBIb3cgZG8gdGhlIEFDIGFuZCBXVFAgYWdyZWUgdGhhdCB0 aGV5IHdpbGwgYmUgdXNpbmcgdGhlIG1vZGUgd2hlcmUgZGF0YSBmcm9tIHRoZSBXVFAgaXMgbm90 IGZvcndhcmRlZCB0byB0aGUgQUM/IFdvdWxkIHRoZXJlIGJlIGEgbmV3IG1lc3NhZ2UgdGhhdCBp bmZvcm1zIHRoZSBXVFAgb2Ygd2hhdCB0byBkby4gDQoNCjIuIEluIHRoaXMgZHJhZnQsIHRoZSBk YXRhIGlzIHNlbnQgZnJvbSBhIFdUUCB0byBhbiBBY2Nlc3MgUm91dGVyLiBIb3cgZG9lcyB0aGUg V1RQIGRpc2NvdmVyIHRoZSByaWdodCBBY2Nlc3MgUm91dGVyIGZvciBhIHNwZWNpZmljIHVzZXI/ IA0KRXNwZWNpYWxseSBjb25zaWRlcmluZyB0aGF0IC0gYXMgZGVzY3JpYmVkIGluIHRoZSBkcmFm dCBpdHNlbGYgLSAiaW4gbWFueSBkZXBsb3ltZW50cywgdGhlIG9wZXJhdG9yIG1hbmFnaW5nIHRo ZSBXVFBzL0FDIG1heSBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgb3BlcmF0b3IgcHJvdmlkaW5nIHRo ZSBpbnRlcm5ldCBjb25uZWN0aXZpdHkgdG8gdGhlIFdUUHMiLg0KSXQgY291bGQgYWxzbyBiZSB0 aGUgY2FzZSB0aGF0IHNlc3Npb25zIGF0dGFjaGVkIHRvIGEgV1RQIG1heSBiZSBob21lZCB0byBt b3JlIHRoYW4gb25lIG9wZXJhdG9yLg0KSXQgc2VlbXMgbGlrZSBhIGR5bmFtaWMvcHJvdG9jb2wg YmFzZWQgZGlzY292ZXJ5IGlzIGJldHRlciBzdWl0ZWQgaW4gdGhpcyBjYXNlPw0KDQozLiBJbiB0 aGlzIGNhc2UsIHRoZXJlIGlzIGEgQ0FQV0FQIGNvbnRyb2wgcmVsYXRpb25zaGlwIFdUUCAtIEFD LCBhbmQgYSBkYXRhIHBhdGggb2YgV1RQIC0gQWNjZXNzIFJvdXRlci4gSWYgdGhlcmUgaXMgYSBm YWlsdXJlIG9mLCBsZXRzIHNheSwgdGhlIFdUUCAtIEFDIHBhdGggKGtlZXAtYWxpdmUgZmFpbHMp LCB3aGF0IHdvdWxkIGJlIHRoZSBleHBlY3RlZCBiZWhhdmlvciBvZiB0aGUgZGF0YSBwYXRoIChX VFAtQVIpPyBXb3VsZCB0aGUgZGF0YSBjaGFubmVsIGJlIGtlcHQgb3IgdG9ybiBkb3duPyANCg0K QWxzbyB3YW50IHRvIG5vdGUgdGhhdCBzb21lIG9mIHRoZSBwcm9wb3NhbHMgaW4gZHJhZnQteHVl LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1jYXBhYmlsaXR5LTAxIChDYXBhYmlsaXR5IEFubm91 bmNlbWVudCBhbmQgQVIgRGlzY292ZXJ5IGluIENBUFdBUCBDb250cm9sIGFuZCBEYXRhIENoYW5u ZWwgU2VwYXJhdGlvbikgY2FuIGNvbXBsZW1lbnQgdGhpcyBkcmFmdC4gV2UgY291bGQgZGlzY3Vz cyB0aGlzIHNlcGFyYXRlbHkgYXMgbmVlZGVkLg0KDQpCZXN0IFJlZ2FyZHMsDQpKb2huDQoNCg0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3BzYXdnLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9m IFJhamVzaCBQYXpoeWFubnVyIChycGF6aHlhbikNCj4gU2VudDogU2F0dXJkYXksIE9jdG9iZXIg MjYsIDIwMTMgNTowOCBQTQ0KPiBUbzogb3BzYXdnQGlldGYub3JnDQo+IFN1YmplY3Q6IFtPUFNB V0ddIFNlZWtpbmcgZGlzY3Vzc2lvbiBvbiAiQWx0ZXJuYXRlIFR1bm5lbCBFbmNhcHN1bGF0aW9u DQo+IGZvciBEYXRhIEZyYW1lcyBpbiBDQVBXQVAiDQo+IA0KPiBIZWxsbw0KPiANCj4gV2UgaGF2 ZSByZXN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB0aXRsZWQg4oCcQWx0ZXJu YXRlIFR1bm5lbA0KPiBFbmNhcHN1bGF0aW9uIGZvciBEYXRhIEZyYW1lcyBpbiBDQVBXQVAiLA0K PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLW9wc2F3Zy1jYXB3 YXAtY2RzLy4NCj4gVGhlIHByZXZpb3VzIHZlcnNpb24gd2FzIHRpdGxlZDog4oCcU2VwYXJhdGlv biBvZiBDQVBXQVAgQ29udHJvbCBhbmQgRGF0YQ0KPiBQbGFuZTogU2NlbmFyaW9zLCBSZXF1aXJl bWVudHMgYW5kIFNvbHV0aW9uc+KAnS4gQmFzZWQgb24gZGlzY3Vzc2lvbiBpbg0KPiB0aGUgbGFz dCBJRVRGLCB3ZSByZXdvcmtlZCB0aGUgZHJhZnQuDQo+IA0KPiBUaGUgZHJhZnQgcHJvdmlkZXMg YSByZWFzb24gZm9yIHRoZSBuZWVkIGZvciBXVFAgdG8gaGF2ZSBhZGRpdGlvbmFsDQo+IHR1bm5l bCAoYmV5b25kIENBUFdBUCkgZW5jYXBzdWxhdGlvbnMgZm9yIHVzZXIgdHJhZmZpYy4gSXQgZW5h YmxlcyBhDQo+IFdUUCB0byBhZHZlcnRpc2UgdGhlIGNhcGFiaWxpdHkgdG8gc3VwcG9ydCBzdWNo IGFsdGVybmF0ZSB0dW5uZWwNCj4gZW5jYXBzdWxhdGlvbiBhbmQgdGhlIEFDIHRvIGNvbmZpZ3Vy ZSBzdWNoIHR1bm5lbCBlbmNhcHN1bGF0aW9uIG9uIHRoZQ0KPiBXVFAuwqAgVGhlIGFsdGVybmF0 ZSB0dW5uZWwgZW5jYXBzdWxhdGlvbiBhbGxvd3MgMSkgdGhlIFdUUCB0byB0dW5uZWwNCj4gbm9u LW1hbmFnZW1lbnQgZGF0YSBmcmFtZXMgdG8gYW4gZW5kcG9pbnQgZGlmZmVyZW50IGZyb20gdGhl IEFDIGFuZCAyKQ0KPiBhbGxvd3MgdGhlIFdUUCB0byB0dW5uZWwgdXNpbmcgb25lIG9mIG1hbnkg a25vd24gZWNhcHN1bGF0aW9uIHR5cGVzDQo+IHN1Y2ggYXMgSVAtSVAsIElQLUdSRSwgQ0FQV0FQ Lg0KPiANCj4gDQo+IFJlZ2FyZHMNCj4gDQo+IFJhamVzaA0KPiANCj4gDQo= From John.Kaippallimalil@huawei.com Wed Oct 30 20:38:58 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2E611E81ED for ; Wed, 30 Oct 2013 20:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnJGgFbML0bc for ; Wed, 30 Oct 2013 20:38:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D111E81DD for ; Wed, 30 Oct 2013 20:38:53 -0700 (PDT) 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 AZS00228; Thu, 31 Oct 2013 03:38:51 +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; Thu, 31 Oct 2013 03:38:29 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Oct 2013 03:38:50 +0000 Received: from DFWEML511-MBB.china.huawei.com ([169.254.4.153]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Wed, 30 Oct 2013 20:38:48 -0700 From: John Kaippallimalil To: "Rajesh Pazhyannur (rpazhyan)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" Thread-Index: Ac7SqIs8II5D0brnRoyCTVQ6wZ7WWAAAbPhgAAAs4CAANMhyYAAPWb9gAAvDqPAAVQEngAAq4DrAAAAKW0A= Date: Thu, 31 Oct 2013 03:38:47 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171CFD56E5@dfweml511-mbb.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171CFD3AF4@dfweml511-mbb.china.huawei.com> <01FE63842C181246BBE4CF183BD159B448F32979@nkgeml504-mbx.china.huawei.com> <6561EABF52675C45BCDACA1B4D7AA1171CFD4EA1@dfweml511-mbb.china.huawei.com> <01FE63842C181246BBE4CF183BD159B448F36D6D@nkgeml504-mbx.china.huawei.com> <6561EABF52675C45BCDACA1B4D7AA1171CFD56D3@dfweml511-mbb.china.huawei.com> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171CFD56D3@dfweml511-mbb.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 03:38:58 -0000 Hi, [Sorry for reposting - but I think I posted to the wrong thread earlier - a= pologize for that.] I've read this draft and agree with the requirements identified and solutio= n to tunnel to an AR, etc. There is a need to have the right means by which= the AC, WTP and AR discover, sync up on tunnels, etc. Some questions for clarification: 1. How do the AC and WTP agree that they will be using the mode where data = from the WTP is not forwarded to the AC? Would there be a new message that = informs the WTP of what to do.=20 2. In this draft, the data is sent from a WTP to an Access Router. How does= the WTP discover the right Access Router for a specific user?=20 Especially considering that - as described in the draft itself - "in many d= eployments, the operator managing the WTPs/AC may be different from the ope= rator providing the internet connectivity to the WTPs". It could also be the case that sessions attached to a WTP may be homed to m= ore than one operator. It seems like a dynamic/protocol based discovery is better suited in this c= ase? 3. In this case, there is a CAPWAP control relationship WTP - AC, and a dat= a path of WTP - Access Router. If there is a failure of, lets say, the WTP = - AC path (keep-alive fails), what would be the expected behavior of the da= ta path (WTP-AR)? Would the data channel be kept or torn down?=20 Also want to note that some of the proposals in draft-xue-opsawg-capwap-sep= aration-capability-01 (Capability Announcement and AR Discovery in CAPWAP C= ontrol and Data Channel Separation) can complement this draft. We could dis= cuss this separately as needed. Best Regards, John > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Rajesh Pazhyannur (rpazhyan) > Sent: Saturday, October 26, 2013 5:08 PM > To: opsawg@ietf.org > Subject: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation > for Data Frames in CAPWAP" >=20 > Hello >=20 > We have resubmitted a new version of the draft titled "Alternate Tunnel > Encapsulation for Data Frames in CAPWAP", > http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/. > The previous version was titled: "Separation of CAPWAP Control and Data > Plane: Scenarios, Requirements and Solutions". Based on discussion in > the last IETF, we reworked the draft. >=20 > The draft provides a reason for the need for WTP to have additional > tunnel (beyond CAPWAP) encapsulations for user traffic. It enables a > WTP to advertise the capability to support such alternate tunnel > encapsulation and the AC to configure such tunnel encapsulation on the > WTP.=A0 The alternate tunnel encapsulation allows 1) the WTP to tunnel > non-management data frames to an endpoint different from the AC and 2) > allows the WTP to tunnel using one of many known ecapsulation types > such as IP-IP, IP-GRE, CAPWAP. >=20 > We would like to get it adopted as a working group item and would like > feedback on whether we are on track. >=20 > Regards >=20 > Rajesh >=20 >=20 From rpazhyan@cisco.com Wed Oct 30 21:16:55 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A17421E80B5 for ; Wed, 30 Oct 2013 21:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JShvD4F3Xyt5 for ; Wed, 30 Oct 2013 21:16:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A014821E80AF for ; Wed, 30 Oct 2013 21:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13413; q=dns/txt; s=iport; t=1383193005; x=1384402605; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5cmW2kJ3UeYONVrExcfSf7t2iSdF3By9UB9iJSPs3Z8=; b=jpnCSw7maYNXMb3jyTVVwYZ6NggeTj0HDurj0+QfjTf4/tKsuzRJJpEH Kjy2PlSqFS5UL991JPYD6ejAxRvuBOCmQAK6rHX1dG0+RkClEOc8+hZYX p1n96M2c/nfGpe9jig+hSv+GVRcGUGyA8DGFNIkbtRN7/Jr+scvXnoSeG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsGABnZcVKtJXHA/2dsb2JhbABZgkNEOFStL4loiE2BLBZ0giUBAQEDAS1FDAcEAgEIEQQBAQsdBxwWFAkIAgQBEggTh2YGDbsBjgaBGDgGgxqBDQOFZoF8kViQWoFogT6BcTk X-IronPort-AV: E=Sophos;i="4.93,606,1378857600"; d="scan'208,217";a="275791344" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 31 Oct 2013 04:16:44 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9V4GiE1026161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 04:16:44 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.202]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 23:16:44 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: John Kaippallimalil , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" Thread-Index: Ac7SqIs8II5D0brnRoyCTVQ6wZ7WWAAAbPhgAAAs4CAANMhyYAAPWb9gAAvDqPAAVQEngAAq4DrAAAAKW0AAAQWqgA== Date: Thu, 31 Oct 2013 04:16:43 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320ED18A0@xmb-aln-x09.cisco.com> References: <6561EABF52675C45BCDACA1B4D7AA1171CFD3AF4@dfweml511-mbb.china.huawei.com> <01FE63842C181246BBE4CF183BD159B448F32979@nkgeml504-mbx.china.huawei.com> <6561EABF52675C45BCDACA1B4D7AA1171CFD4EA1@dfweml511-mbb.china.huawei.com> <01FE63842C181246BBE4CF183BD159B448F36D6D@nkgeml504-mbx.china.huawei.com> <6561EABF52675C45BCDACA1B4D7AA1171CFD56D3@dfweml511-mbb.china.huawei.com> <6561EABF52675C45BCDACA1B4D7AA1171CFD56E5@dfweml511-mbb.china.huawei.com> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171CFD56E5@dfweml511-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.186] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320ED18A0xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: Re: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 04:16:55 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320ED18A0xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John Thanks for reviewing. Some answers provided. Regards Rajesh -----Original Message----- From: John Kaippallimalil [mailto:John.Kaippallimalil@huawei.com] Sent: Wednesday, October 30, 2013 8:39 PM To: Rajesh Pazhyannur (rpazhyan); opsawg@ietf.org Subject: RE: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation= for Data Frames in CAPWAP" Hi, [Sorry for reposting - but I think I posted to the wrong thread earlier - a= pologize for that.] I've read this draft and agree with the requirements identified and solutio= n to tunnel to an AR, etc. There is a need to have the right means by which= the AC, WTP and AR discover, sync up on tunnels, etc. Some questions for clarification: 1. How do the AC and WTP agree that they will be using the mode where data = from the WTP is not forwarded to the AC? Would there be a new message that = informs the WTP of what to do. > I should probably explain this in more detail in the draft, with a= figure. The procedure is defined somewhat tersely in the text in Section = 2.1 and 2.2. Specifically, the WTP will indicate support for this capabilit= y in the Discover and/or Join Request and the AC will determine whether to = configure this mode while configuring the WLAN by providing the Tunnel Enca= p Type in the IEEE 802.11 Add WLAN Message Element. 2. In this draft, the data is sent from a WTP to an Access Router. How does= the WTP discover the right Access Router for a specific user? Especially considering that - as described in the draft itself - "in many d= eployments, the operator managing the WTPs/AC may be different from the ope= rator providing the internet connectivity to the WTPs". It could also be the case that sessions attached to a WTP may be homed to m= ore than one operator. It seems like a dynamic/protocol based discovery is better suited in this c= ase? > Dan had raised the same point in his email. We envision that the AC will= configure the WTP with the appropriate identifier of the AR. So for examp= le, if PMIPv6 were being used (and the WTP were a MAG) then the AC would pr= ovide the IP address (and other configuration like shared secret) of the LM= A. Reusing CAPWAP to provide some of the alternate tunnel configurations s= eem advantageous. This detail is not there in the current version of the d= raft but something we hoped to add in the next version. 3. In this case, there is a CAPWAP control relationship WTP - AC, and a dat= a path of WTP - Access Router. If there is a failure of, lets say, the WTP = - AC path (keep-alive fails), what would be the expected behavior of the da= ta path (WTP-AR)? Would the data channel be kept or torn down? > This is a good question. I believe this is a matter of implementati= on (and not something that has to be specified in the protocol). For exampl= e, in the current CAPWAP system if the WTP is operating in local bridged mo= de and there is a failure with the AC such that WTP can longer communicate = with the AC. In such a case, the WTP may choose to continue providing serv= ice to existing customers. Most current implementations continue service to= existing customers. Also want to note that some of the proposals in draft-xue-opsawg-capwap-sep= aration-capability-01 (Capability Announcement and AR Discovery in CAPWAP C= ontrol and Data Channel Separation) can complement this draft. We could dis= cuss this separately as needed. > Happy to discuss this more. Best Regards, John > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:ops= awg-bounces@ietf.org] On > Behalf Of Rajesh Pazhyannur (rpazhyan) > Sent: Saturday, October 26, 2013 5:08 PM > To: opsawg@ietf.org > Subject: [OPSAWG] Seeking discussion on "Alternate Tunnel > Encapsulation for Data Frames in CAPWAP" > > Hello > > We have resubmitted a new version of the draft titled "Alternate > Tunnel Encapsulation for Data Frames in CAPWAP", > http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/. > The previous version was titled: "Separation of CAPWAP Control and > Data > Plane: Scenarios, Requirements and Solutions". Based on discussion in > the last IETF, we reworked the draft. > > The draft provides a reason for the need for WTP to have additional > tunnel (beyond CAPWAP) encapsulations for user traffic. It enables a > WTP to advertise the capability to support such alternate tunnel > encapsulation and the AC to configure such tunnel encapsulation on the > WTP. The alternate tunnel encapsulation allows 1) the WTP to tunnel > non-management data frames to an endpoint different from the AC and 2) > allows the WTP to tunnel using one of many known ecapsulation types > such as IP-IP, IP-GRE, CAPWAP. > > We would like to get it adopted as a working group item and would like > feedback on whether we are on track. > > Regards > > Rajesh > > --_000_4ED2E36A22261145861BAB2C24088B4320ED18A0xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
John
 
Thanks for reviewing. Some answers provided. <= /font>
 
Regards
 
Rajesh
 
-----Original Message-----
From: John Kaippallimalil [mailto:John.Kaippallimalil@huawei.com]
Sent: Wednesday, October 30, 2013 8:39 PM
To: Rajesh Pazhyannur (rpazhyan); opsawg@ietf.org
Subject: RE: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsul= ation for Data Frames in CAPWAP"
 
Hi,
[Sorry for reposting - but I think I posted to the wrong thread earlie= r - apologize for that.]
 
I've read this draft and agree with the requirements identified and so= lution to tunnel to an AR, etc. There is a need to have the right means by = which the AC, WTP and AR discover, sync up on tunnels, etc.
 
Some questions for clarification:
1. How do the AC and WTP agree that they will be using the mode where = data from the WTP is not forwarded to the AC? Would there be a new message = that informs the WTP of what to do.
 
  • I should probably explain this in more detail in the draft, with a fig= ure. The procedure is defined somewhat tersely in the text in Section 2.1 = and 2.2. Specifically, the WTP will indicate support for this capability in= the Discover and/or Join Request and the AC will determine whether to configure this mode while configuring = the WLAN by providing the Tunnel Encap Type in the IEEE 802.11 Add WLAN Mes= sage Element.
    •
 
2. In this draft, the data is sent from a WTP to an Access Router. How= does the WTP discover the right Access Router for a specific user?
Especially considering that - as described in the draft itself - "= ;in many deployments, the operator managing the WTPs/AC may be different fr= om the operator providing the internet connectivity to the WTPs".
It could also be the case that sessions attached to a WTP may be homed= to more than one operator.
It seems like a dynamic/protocol based discovery is better suited in t= his case?
 
>  Dan had raised the same point in his email. We <= /font>envision that the AC will configure the WTP w= ith the appropriate identifier of the AR.  So for example, if PMIPv6 were being used (and the WTP were a MAG) then the AC would provide the IP address (and other configuration like = shared secret) of the LMA. Reusing CAPWAP to provide some of the alternate tunnel configurations seem = advantageous.  This detail is not there= in the current version of the draft but something we hoped to add in the n= ext version.
 
3. In this case, there is a CAPWAP control relationship WTP - AC, and = a data path of WTP - Access Router. If there is a failure of, lets say, the= WTP - AC path (keep-alive fails), what would be the expected behavior of t= he data path (WTP-AR)? Would the data channel be kept or torn down?
 
  • This is a good question. I believe this is a matter of implementation (= and not something that has to be specified in the protocol). For example, i= n the current CAPWAP system if the WTP is operating in local bridged mode a= nd there is a failure with the AC such that WTP can longer communicate with the AC.  In such a case, the= WTP may choose to continue providing service to existing customers. Most c= urrent implementations continue service to existing customers.
 
Also want to note that some of the proposals in draft-xue-opsawg-capwa= p-separation-capability-01 (Capability Announcement and AR Discovery in CAP= WAP Control and Data Channel Separation) can complement this draft. We coul= d discuss this separately as needed.
  • Happy to discuss this more.
    •
 
Best Regards,
John
 
 
> -----Original Message-----
> Behalf Of Rajesh Pazhyannur (rpazhyan)
> Sent: Saturday, October 26, 2013 5:08 PM
> Subject: [OPSAWG] Seeking discussion on "Alternate Tunnel
> Encapsulation for Data Frames in CAPWAP"
>
> Hello
>
> We have resubmitted a new version of the draft titled "Alter= nate
> Tunnel Encapsulation for Data Frames in CAPWAP",
> The previous version was titled: "Separation of CAPWAP Contr= ol and
> Data
> Plane: Scenarios, Requirements and Solutions". Based on disc= ussion in
> the last IETF, we reworked the draft.
>
> The draft provides a reason for the need for WTP to have addition= al
> tunnel (beyond CAPWAP) encapsulations for user traffic. It enable= s a
> WTP to advertise the capability to support such alternate tunnel =
> encapsulation and the AC to configure such tunnel encapsulation o= n the
> WTP.  The alternate tunnel encapsulation allows 1) the WTP t= o tunnel
> non-management data frames to an endpoint different from the AC a= nd 2)
> allows the WTP to tunnel using one of many known ecapsulation typ= es
> such as IP-IP, IP-GRE, CAPWAP.
>
> We would like to get it adopted as a working group item and would= like
> feedback on whether we are on track.
>
> Regards
>
> Rajesh
>
>
 
 --_000_4ED2E36A22261145861BAB2C24088B4320ED18A0xmbalnx09ciscoc_-- From bclaise@cisco.com Thu Oct 31 10:06:15 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB02B11E81D2 for ; Thu, 31 Oct 2013 10:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjQj1U02ktZx for ; Thu, 31 Oct 2013 10:06:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 957DA11E811D for ; Thu, 31 Oct 2013 10:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3103; q=dns/txt; s=iport; t=1383239164; x=1384448764; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=Eq/WFaN10iEJwvmYqhqjY59159ZfvQBbYTuIKgsp6/8=; b=NT7jRYFU6r0NmXAQ+cS5jHMq9woLLGgQe/kFCFKQiduU1aeZBLmd/eeC sQ9FFN+80QFA6yJuNQLyZiPTe1chVJ89oSX3cl10b2XVnSJK5LeXQihmX 5dHXt4dawcVZX+QxXe/9oCUm+0Tb4b7og3YyOTe+NrlubHqiYC9nfPJfw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcGAN2MclKQ/khL/2dsb2JhbABZgwfAdYEnFm0HgmRAATwWGAMCAQIBSw0BBwEBEAeHbLxXjhGBPoQ1A5gKhj2LTIMnO4Et X-IronPort-AV: E=Sophos;i="4.93,610,1378857600"; d="scan'208";a="87811151" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 31 Oct 2013 17:06:03 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9VH5vuq019759; Thu, 31 Oct 2013 17:05:58 GMT Message-ID: <52728DF5.2070701@cisco.com> Date: Thu, 31 Oct 2013 18:05:57 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dave Thaler Subject: [OPSAWG] OPS guidance to the non-OPS community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:06:15 -0000 Dear all, During the OPSAWG/OPSAREA meeting, I will be addressing one issue that is now on the top of my mind: OPS guidance to the non-OPS community. Problem 1: How do we share our OPS knowledge? How do we advice which OPS tools (NETCONF, SNMP, AAA, ping, syslog, IPFIX, etc...) the community should be using? The point is that we have multiple management frameworks, as opposed to only one in the past: SNMP You know, it could be as simple as: if you plan on doing configuration, investigate NETCONF. But it might more complex: 1. do you have an existing MIB module? and you don't plan on doing configuration? then update the existing MIB module alternatively, if you're thinking about configuration, then investigate NETCONF. and for monitoring, if you start from scratch, use NETCONF that can also report operational status however, if you have an existing MIB module for monitoring, and you plan on using NETCONF for monitoring ... 2. I need to do reporting, can you please give the pros and cons of the syslog versus syslog SDE versus SNMP versus IPFIX versus ... On regular basis, I have to provide these advice: it's not always easy, because the answer depends on many factors. However, when asking a few questions, we're able to limit the options to just one or two choices. How can we share this knowledge? This is the perfect job for an OPS advisor, but one OPS advisor in all WGs doesn't scale. Problem 2: What are the OPS recommendations for future developments? It might appear as the same problem as 1, but the audience is different. Here, we speak about new charters for example. Basically, the recommendations have changed over the years. For example, don't write MIB modules in your charter to please the OPS ADs, it's not about MIB module only any longer Provide the use cases and operational requirements, and from there, we will help selecting the right protocol and data models There are pieces of information all over the place: - RFC 5706, Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions Appendix A askes interesting questions, helping with the operational requirements - RFC 6632, An Overview of the IETF Network Management Standards It's complete, but way too long. The appendices ask the right question - There was an attempt to solve the same problem in the past: draft-harrington-operations-and-management-01 - RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards, is 25 years old :-) What are the constraints? For problem 1: must be simple and not too long (not a 50 pages document) can change on regular basis Solution: maybe a WIKI or a flow chart? For problem 2: These are recommendations for future developments: it doesn't matter if it's not perfect day one. Solution: maybe update RFC 1052bis Questions: - Do you agree on the two problem statements? - How to solve them? Any brainstorming ideas are welcome. Regards, Benoit From melinda.shore@gmail.com Thu Oct 31 13:11:33 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CB511E81AC for ; Thu, 31 Oct 2013 13:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvdVPhhh95Gt for ; Thu, 31 Oct 2013 13:11:33 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E8F1711E8195 for ; Thu, 31 Oct 2013 13:11:32 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so3031528pab.14 for ; Thu, 31 Oct 2013 13:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=4orzYe9eFV51uNFI/g9QAEPP2UFeRLlsm1DVq3ppTaw=; b=rter3IMhXmh/5ocHoQzZHD212w1CtfFXchceK8eBWvapHL2lClF0/KXTht06V7BJs1 O5GwRHxKEAgJFzALEPBCUsHJO3OMaplPkNPN323/HTk17q5RaRYFACDlxYlxL/+ivYbD gkF9hyO4nN1KVJXBsBHyfhas3KtNax/RJbHZG0sD4ZnNxEXUS0KGjVrYkcUnROQUnwhn Idzla8YWiIPp1h/wk6dVEB0prS+xi7SrCUs4MPgMjPJ6nFaJ1lMHF7GekV9I7wdATaHO zCuLZwfPVk8QmrOfuwjVgUURtxPNYLKN/q67X/cdbtIIfQcyuIgqHc+JZ/cjfBiui/Kq 4D/Q== X-Received: by 10.68.197.36 with SMTP id ir4mr3746479pbc.96.1383250292486; Thu, 31 Oct 2013 13:11:32 -0700 (PDT) Received: from spandex.local (63-140-93-114.dynamic.dsl.acsalaska.net. [63.140.93.114]) by mx.google.com with ESMTPSA id fa4sm7555727pab.17.2013.10.31.13.11.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 13:11:31 -0700 (PDT) Message-ID: <5272B970.2080508@gmail.com> Date: Thu, 31 Oct 2013 12:11:28 -0800 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" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Slides X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 20:11:33 -0000 If you're on the agenda during Tuesday's meeting and[*] will be using slides, please send them along so that we'll have time to get them uploaded prior to the session. Thanks! Melinda [*]Agenda is here: https://datatracker.ietf.org/meeting/88/agenda/opsawg/ From rpazhyan@cisco.com Thu Oct 31 13:57:29 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4B411E81B9 for ; Thu, 31 Oct 2013 13:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KdLJq-5ppNd for ; Thu, 31 Oct 2013 13:57:23 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CEDD211E826D for ; Thu, 31 Oct 2013 13:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=694; q=dns/txt; s=iport; t=1383253042; x=1384462642; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lnqPVsw/JHarYARaAV62pSWwGjFWxpFvJk5KSs+PvCw=; b=hcMOutvDdcnk68wrnRujFnrlKVIPdDSUODKHr49biSxev4pHqFxK7mRB +6U+QRDnEhGU0v27I52976yACTkRMmjm/fsBKFEgQGInZz5Fzlas50OOf MfJp0D6xP6CbF3OlxswyagwJ8IwUz6jESJtGvsEPRg1Slx6JCEDwr7uOA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAD3DclKtJV2c/2dsb2JhbABZgwc4VL8iS4EoFnSCJQEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIh34BDbxnBI8eOAaDGoEOA6oTgyaCKg X-IronPort-AV: E=Sophos;i="4.93,611,1378857600"; d="scan'208";a="279177901" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 31 Oct 2013 20:57:21 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9VKvKbA014321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 20:57:20 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.202]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 15:57:20 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Melinda Shore , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Slides Thread-Index: AQHO1nVqSH0KBJCtFE+7fe1Rcn24RpoPSo9A Date: Thu, 31 Oct 2013 20:57:19 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320ED1DB8@xmb-aln-x09.cisco.com> References: <5272B970.2080508@gmail.com> In-Reply-To: <5272B970.2080508@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.133.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] Slides X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 20:57:29 -0000 Melinda=20 Can I get it you by Sun evening ?=20 Thanks Rajesh -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Melinda Shore Sent: Thursday, October 31, 2013 1:11 PM To: opsawg@ietf.org Subject: [OPSAWG] Slides If you're on the agenda during Tuesday's meeting and[*] will be using slide= s, please send them along so that we'll have time to get them uploaded prio= r to the session. Thanks! Melinda [*]Agenda is here: https://datatracker.ietf.org/meeting/88/agenda/opsawg/ _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg