From sob@harvard.edu Thu Nov 1 06:01:32 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB4421F8F4E for ; Thu, 1 Nov 2012 06:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MelGYuLbTXt for ; Thu, 1 Nov 2012 06:01:31 -0700 (PDT) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id 16BD821F8F97 for ; Thu, 1 Nov 2012 06:01:30 -0700 (PDT) Received: from exchange.university.harvard.edu (entwedge0000003.university.harvard.edu [10.35.202.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 12B10E90A2 for ; Thu, 1 Nov 2012 09:01:30 -0400 (EDT) Received: from ENTWHUBT0000006.university.harvard.edu (192.168.236.26) by entwedge0000003.university.harvard.edu (10.35.202.50) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 1 Nov 2012 09:01:09 -0400 Received: from ENTWEXMB0000008.university.harvard.edu ([169.254.1.87]) by ENTWHUBT0000006.university.harvard.edu ([192.168.236.28]) with mapi id 14.01.0355.002; Thu, 1 Nov 2012 09:01:29 -0400 From: "Bradner, Scott" To: "opsawg@ietf.org" Thread-Topic: Please Help the NomCom Thread-Index: AQHNuDEB2OYwa8+htU+BP/zwJKrydg== Date: Thu, 1 Nov 2012 13:01:27 +0000 Message-ID: <9AE23F8A-177C-4BEA-A2B7-F1EA89FFC9AF@harvard.edu> References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.103.65.65] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSAWG] Please Help the NomCom 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, 01 Nov 2012 13:01:32 -0000 please help the noncom evaluate candidates for various IETF management role= s Scott Begin forwarded message: > From: NomCom Chair > Subject: CORRECTION: Help the NomCom > Date: November 1, 2012 8:17:22 AM EDT > To: Working Group Chairs >=20 > The full text of the corrected message is below > --------------------------------------------------- >=20 > The IETF Nominations Committee (NomCom) continues to seek input from > the IETF Community. The NomCom would greatly appreciate any help you > could provide in making members of your working group aware of ways in > which they can provide valuable feedback to the NomCom. >=20 > In order to ensure that your input is received in time to be useful, the= =20 > NomCom needs to receive community feedback on or before Sunday, November = 11. >=20 > The final list of candidates (as per RFC 5680) that the NomCom is=20 > considering for open positions can be found at:=20 > https://www.ietf.org/group/nomcom/2012/input/ >=20 > The NomCom will be holding office hours during IETF 85, Monday- > Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes=20 > comments on specific individuals, as well as general feedback related to= =20 > any of the positions that NomCom is considering. >=20 > Note: A list of leadership positions that the NomCom is considering can b= e=20 > found at: https://www.ietf.org/group/nomcom/2012/ >=20 > If the NomCom office hours are inconvenient for you or if you cannot=20 > attend IETF 85, the NomCom is happy to take community input via email=20 > to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a=20 > meeting outside of office hours, just send us email and we can set=20 > something up. >=20 > Comments on specific candidates can also be provided to the NomCom > via the web feedback tool:=20 > https://www.ietf.org/group/nomcom/2012/input/ >=20 > Thank you for your help, > - Matt Lepinski > nomcom-chair at ietf.org From melinda.shore@gmail.com Thu Nov 1 06:11:22 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6259F21F9160 for ; Thu, 1 Nov 2012 06:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIEsFkixXq4B for ; Thu, 1 Nov 2012 06:11:21 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40AD821F9134 for ; Thu, 1 Nov 2012 06:10:41 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1733792pbb.31 for ; Thu, 01 Nov 2012 06:10:41 -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:x-forwarded-message-id:content-type :content-transfer-encoding; bh=+uj5XgzKPmH72NKbgAevS95s7lIVOENLHZ8U+UgcerQ=; b=y7KPaPhUzz9csElOG/t9k6tJqTRWC/9TZFLKWJs/GktKrIbnc7K8tx56Amwd+nuFyr r4RLtJYwDER7ysGGyhJJqghaXpN/5ETn2+YWLPCUv/j3cgvF460cV+JJLtPHFsk20tVu 4PJDu9hl9XSwKcvBgUWPm5S3dDUGe8fjyqVHZSZGXLqf2mUd5u1Bdxa7Ef64P8Qxb7cA qBmffpUXyXvkoobnO9moXiZdZZgij9x1RXHSyFYgB+IqvCoVMPliF0/r3n0InxO5IN1T Om+k5b/HB28JcTDH3UNV7Vglrn8tWHHTb6ICysmzHuKTTz9dRiNcxWIcdEFYVO2XwNDl j7mw== Received: by 10.66.89.138 with SMTP id bo10mr111346490pab.0.1351775440994; Thu, 01 Nov 2012 06:10:40 -0700 (PDT) Received: from spandex.local (209-193-56-73-rb1.fai.dsl.dynamic.acsalaska.net. [209.193.56.73]) by mx.google.com with ESMTPS id jw14sm4019841pbb.36.2012.11.01.06.10.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 06:10:40 -0700 (PDT) Message-ID: <509274CD.1040703@gmail.com> Date: Thu, 01 Nov 2012 05:10:37 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <20121101122853.4065.5996.idtracker@ietfa.amsl.com> In-Reply-To: <20121101122853.4065.5996.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121101122853.4065.5996.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Fwd: NomCom 2012: Feedback and Office Hours 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, 01 Nov 2012 13:11:22 -0000 The NomCom is looking for your input. -------- Original Message -------- Subject: NomCom 2012: Feedback and Office Hours Date: Thu, 01 Nov 2012 05:28:53 -0700 From: NomCom Chair To: IETF Announcement List The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ In order to ensure that your input is received in time to be useful, please provide your input on or before Sunday, November 11. Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org From melinda.shore@gmail.com Thu Nov 1 10:37:49 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B92C21F8950 for ; Thu, 1 Nov 2012 10:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq1pmt4Ti5P1 for ; Thu, 1 Nov 2012 10:37:48 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0BC21F8922 for ; Thu, 1 Nov 2012 10:37:48 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1890563pbb.31 for ; Thu, 01 Nov 2012 10:37:48 -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=kcINqhu6u1rSdv4IoibrycuZ/+hRpL4e/5Ix92CG4BE=; b=fZxGFwWg+sjrFJxJBn31lwOKhWJZKnH5FtsL3Tk65AcwA3QThkkRP6PFAACqnkh41c Ssp9qlc+a5A2S6ZoLOb/WAoPaRAHOTFD8bNEbAmOcO9RfbfXf4tubEnV8FK+7yHRLIOo G0hxT1UDiTBIWPotlYEvXGgbWNdJkocFFM1UGDn5V/fpK5LM9FaWlWFKRHmEBaM0Z1Dw iTvtiOOk0quoC/FmAMcaCqJmt6TszxQIhKy8ZP1s83SNEQyoQ9MrWH6j933YOyjGQuet ip7QNjVM1lSbq7pIc4guBdrJrgCnVc7N+YD8wN4O+kFpuETwTGw3edPnNq0hChx79W7p hSQw== Received: by 10.66.78.231 with SMTP id e7mr113101847pax.44.1351791468330; Thu, 01 Nov 2012 10:37:48 -0700 (PDT) Received: from spandex.local (209-193-56-73-rb1.fai.dsl.dynamic.acsalaska.net. [209.193.56.73]) by mx.google.com with ESMTPS id ju7sm4322597pbb.60.2012.11.01.10.37.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 10:37:47 -0700 (PDT) Message-ID: <5092B369.5010406@gmail.com> Date: Thu, 01 Nov 2012 09:37:45 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Please send in your 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, 01 Nov 2012 17:37:49 -0000 If you're on the agenda during the opsawg/opsarea session next week, please send us your slides. Thanks, Melinda From bclaise@cisco.com Fri Nov 2 10:31:56 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96611E80BF; Fri, 2 Nov 2012 10:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.041 X-Spam-Level: X-Spam-Status: No, score=-10.041 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wAmxDTeCh5O; Fri, 2 Nov 2012 10:31:45 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA9821F91D3; Fri, 2 Nov 2012 10:31:45 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA2HVi8i016644; Fri, 2 Nov 2012 13:31:44 -0400 (EDT) Received: from [10.86.253.168] ([10.86.253.168]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA2HVX3R008200; Fri, 2 Nov 2012 13:31:37 -0400 (EDT) Message-ID: <5093B25F.1050908@cisco.com> Date: Fri, 02 Nov 2012 07:45:35 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------080306030900080702020909" Cc: coman@ietf.org, opsawg@ietf.org, ext Ulrich Herberg Subject: Re: [OPSAWG] [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.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, 02 Nov 2012 17:31:57 -0000 This is a multi-part message in MIME format. --------------080306030900080702020909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, One point regarding MANET. I believe that it deserves its own document: "MANET network management considerations". Actually, when looking at draft-ietf-manet-nhdp-mib part of the IESG review, one of the outcome was that such a document was required. I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT Note regarding the applicability statement: This is solved, as we discussed, but I'll keep this little sentence in one corner of my head "A fuller discussion of MANET network management use cases and challenges will be provided elsewhere." How/If this "MANET network management considerations" draft relates to the draft-ersue-constrained-mgmt, I'm not sure at this point in time. Regards, Benoit > > Hi Ulrich, > > see my comments below. > > Cheers, > Mehmet > > *From:*ext Ulrich Herberg [mailto:ulrich@herberg.name] > *Sent:* Saturday, October 20, 2012 1:46 AM > *To:* Ersue, Mehmet (NSN - DE/Munich) > *Cc:* coman@ietf.org ; opsawg@ietf.org > > *Subject:* Re: [coman] FW: New Version Notification for > draft-ersue-constrained-mgmt-02.txt > > Hi Mehmet, > > thank you for updating the draft. There is a huge amount of great work > in it, and I think this will provide a great basis for further > discussions. Indeed, splitting up the document would be required at > some point. > > Some high-level comments: > > - Section 1.2 (Terminology): The definition of MANET and > Intermediate entity (in COAP) come a bit surprising, since there has > been no discussion before. Also, it seems inconsistent to define > MANET, but not all the other use cases, such as AMI. > > [ME]: The terminology section is incomplete and should be extended > e.g. with AMI. > > - Section 1.3 (Constrained Device Classes): I know that this > definition is taken from Lwig, but I doubt that it is of much use. The > absolute values will change. While now there are still many C0 devices > out, in five years, they will not exist (or rather, the number 10KB > would need to be replaced by a larger number). I think I would prefer > a classification based on the capabilities (e.g. can support full IP > stack, or not) > > [ME]: The definition was actually first introduced by Carsten in the > Smart Object workshop before IETF 80 in Prague. This is an important > point. See my other mail. > > - Section 1.4 (constrained networks): I don't think this is a very > consistent classification of networks. First, CN0 seems to be the > least constrained network, whereas C0 devices are the most > constrained. I would suggest the remain the same ordering (0 the most > constrained up to a positive number). > > [ME]: The "0" in CN0 and C0 don't relate to each other. The > constrainedness of a network is mostly dependent on the wireless > technology used. I found it more useful to differentiate the type of > the network, where the wireless technology can be manifold. > > More importantly, there is a mixture with constrained devices in this > definition. Since we talk about the network only, we should only talk > about topology, lossy links, multi-hop, mobility etc. but not > constrained devices. > > [ME]: I agree, we should talk here on devices only. > > I don't understand why MANETs are not supported. Several of the use > cases, such as the military use case, community networks and AMI are > multi-hop networks with dynamic topology and lossy links. That is what > I call a MANET. > > [ME]: The agreement in our last f2f meeting was that we want to > include the MANET use case to highlight what it is but exclude from > the requirements discussion. The reason is that MANETs can be based on > very distinct scenarios and have specifics which are unique compared > to other networks. The essential point is that MANETs are > infrastructureless (i.e. without any hierarchy), which seems to be not > the case in other network types the draft describes and makes network > management essentially different. > > Even the definition of CN1 is, IMO, entirely a MANET; you even mention > Mesh networks, which are nothing else than MANETs (only difference is > that routers are usually non-mobile; nevertheless, the topology is > still dynamic because of fluctuating links.). > > [ME]: There might be similarities between a MANET and a Mesh network, > however they are not the same thing. I have to admit we don't conceive > sufficiently the special MANET use cases for frequent movement of > routing devices without infrastructure. If we agree that a Mesh > network covers the essential part of a MANET then I would suggest to > focus on a Mesh network instead of trying to cover everything. > > Is the intention to focus on non-mobile devices? > > [ME]: There is no intention to exclude non-mobile devices. The draft > currently assumes that, from the "network management" pov., both > mobile and non-mobile devices have similar characteristics (I think we > should describe this somewhere). The draft further assumes that the > managing entity is not moving. > > I might be wrong in this. Please describe which mobility aspects you > think should be covered from "network management" pov. Managing the IP > mobility itself, e.g. the IP address etc., is not network management > per se. > > Constrained networks are more difficult to define, as there are > several aspects: bandwidth, loss rates of the channel, MTU, topology, > etc. I think that we need more discussion (but maybe after a BOF has > been initiated?) > > [ME]: We can start such a discussion already today. However, I assume > it is mostly following the capabilities and limitations of the > wireless technology. What would be your proposal for a classification > of constrained networks? > > - Section 1.5: (Network Topology Options): I think there is a mix > between the topology (i.e., the graph that represents routers and > communication links), traffic flows (which devices communicate with > which other devices), and application layer (proxies and NMS). > > - Section 1.6: I like that. > > - Section 1.7: There is mixture of constrained networks (first > bullet); I thought that constrained devices only means that they have > little CPU power and memory. Can't that device still use cable > connectivity (i.e. unconstrained network)? Or is it necessarily linked? > > I am unclear about the purpose of this whole section. What does it > serve for? > > [ME]: Section 1.7 in general tries to list and discuss the issues a > constrained device might have and how these issues influence the > management of such a device. As described in section 1.4 and 2. we > include non-constrained networks with constrained devices. > > - Section 2: I think that the problem statement is not quite clear > yet. It is hard to identify what the problems are; there are so many > useful requirements in section 4, so maybe it could be better matched > to these requirements. It would be nice to read section 4, and then > say "ah, requirement x indeed logically follows from the problem y > that has been described in section 2". > > [ME]: I agree the problem statement in section 2 (which I didn't have > time to update yet) could benefit from a revision aligning it with the > new sections 1.7 and section 4. > > - Section 3: I like the diverse use cases. That can be very useful to > identify different requirements and problems. > > - Section 4: I very much appreciate the enormous effort for gathering > the requirements. There will be detailed discussions about them > (hopefully), but this is a very good list to start from. > > We have to define if the security related requirements also fit in > this discussion, or better some place else (SOLACE?). > > [ME]: We see authentication and access control (to the extend it > matters) as part of network management. This is probably the part > where Coman and Solace can profit from and complement each other. > > Again, I appreciate the effort of the authors, and hope that we can > continue the discussions in Atlanta. I apologize that I only provided > this high-level review, but the last weeks were very busy for me. If > you need help authoring the documents once they are split up, I could > help out. > > Is there a meeting already planned? > > [ME]: Yes, there will be a meeting on Thursday. I wanted to announce > it once the room is known. Stay tuned. > > Best regards > > Ulrich > > On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) > > wrote: > > Hi All, > > we submitted an update for the constrained-mgmt draft on the "Management > of Networks with Constrained Devices: Use Cases and Requirements". The > draft hopefully addresses most of the issues we discussed in the last > meeting. > > I think it is already time to split the draft into three; e.g. problem > statement, use cases and requirements. But this can be done after > getting your feedback before and during IETF 85. > > I would highly appreciate your comments and any kind of discussion on > the draft content especially on the requirements section. Thank you. > > Cheers, > Mehmet > > > -----Original Message----- > From: ext internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org ] > Sent: Monday, October 15, 2012 9:59 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: dromasca@avaya.com ; > j.schoenwaelder@jacobs-university.de > > Subject: New Version Notification for > draft-ersue-constrained-mgmt-02.txt > > > A new version of I-D, draft-ersue-constrained-mgmt-02.txt > has been successfully submitted by Mehmet Ersue and posted to the > IETF repository. > > Filename: draft-ersue-constrained-mgmt > Revision: 02 > Title: Management of Networks with Constrained Devices: Use > Cases and Requirements > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 78 > URL: > http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt > Status: > http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt > Htmlized: > http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ersue-constrained-mgmt-02 > > Abstract: > This document raises the questions on and discusses the use cases and > requirements for the management of networks with constrained devices. > > > > > > The IETF Secretariat > > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------080306030900080702020909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

One point regarding MANET.
I believe that it deserves its own document: "MANET network management considerations". Actually, when looking at draft-ietf-manet-nhdp-mib part of the IESG review, one of the outcome was that such a document was required.
I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT
Note regarding the applicability statement: This is solved, as we
discussed, but I'll keep this little sentence in one 
corner of my head "A fuller discussion of MANET network management use
cases and challenges will be provided elsewhere."
How/If this "MANET network management considerations" draft relates to the draft-ersue-constrained-mgmt, I'm not sure at this point in time.

Regards, Benoit

Hi Ulrich,

 

see my comments below.

 

Cheers,
Mehmet

 

From: ext Ulrich Herberg [mailto:ulrich@herberg.name]
Sent: Saturday, October 20, 2012 1:46 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: coman@ietf.org; opsawg@ietf.org
Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt

 

Hi Mehmet,

 

thank you for updating the draft. There is a huge amount of great work in it, and I think this will provide a great basis for further discussions. Indeed, splitting up the document would be required at some point.

 

Some high-level comments:

  - Section 1.2 (Terminology): The definition of MANET and Intermediate entity (in COAP) come a bit surprising, since there has been no discussion before. Also, it seems inconsistent to define MANET, but not all the other use cases, such as AMI.

 

[ME]: The terminology section is incomplete and should be extended e.g. with AMI.

 

  - Section 1.3 (Constrained Device Classes): I know that this definition is taken from Lwig, but I doubt that it is of much use. The absolute values will change. While now there are still many C0 devices out, in five years, they will not exist (or rather, the number 10KB would need to be replaced by a larger number). I think I would prefer a classification based on the capabilities (e.g. can support full IP stack, or not)

 

[ME]: The definition was actually first introduced by Carsten in the Smart Object workshop before IETF 80 in Prague. This is an important point. See my other mail.

 

  - Section 1.4 (constrained networks): I don't think this is a very consistent classification of networks. First, CN0 seems to be the least constrained network, whereas C0 devices are the most constrained. I would suggest the remain the same ordering (0 the most constrained up to a positive number).

 

[ME]: The “0” in CN0 and C0 don’t relate to each other. The constrainedness of a network is mostly dependent on the wireless technology used. I found it more useful to differentiate the type of the network, where the wireless technology can be manifold.

 

More importantly, there is a mixture with constrained devices in this definition. Since we talk about the network only, we should only talk about topology, lossy links, multi-hop, mobility etc. but not constrained devices. 

 

[ME]: I agree, we should talk here on devices only.

 

I don't understand why MANETs are not supported. Several of the use cases, such as the military use case, community networks and AMI are multi-hop networks with dynamic topology and lossy links. That is what I call a MANET.

 

[ME]: The agreement in our last f2f meeting was that we want to include the MANET use case to highlight what it is but exclude from the requirements discussion. The reason is that MANETs can be based on very distinct scenarios and have specifics which are unique compared to other networks. The essential point is that MANETs are infrastructureless (i.e. without any hierarchy), which seems to be not the case in other network types the draft describes and makes network management essentially different.

 

Even the definition of CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are nothing else than MANETs (only difference is that routers are usually non-mobile; nevertheless, the topology is still dynamic because of fluctuating links.).

 

[ME]: There might be similarities between a MANET and a Mesh network, however they are not the same thing. I have to admit we don’t conceive sufficiently the special MANET use cases for frequent movement of routing devices without infrastructure. If we agree that a Mesh network covers the essential part of a MANET then I would suggest to focus on a Mesh network instead of trying to cover everything.

 

Is the intention to focus on non-mobile devices?

 

[ME]: There is no intention to exclude non-mobile devices. The draft currently assumes that, from the “network management” pov., both mobile and non-mobile devices have similar characteristics (I think we should describe this somewhere). The draft further assumes that the managing entity is not moving.

 

I might be wrong in this. Please describe which mobility aspects you think should be covered from “network management” pov. Managing the IP mobility itself, e.g. the IP address etc., is not network management per se.

 

Constrained networks are more difficult to define, as there are several aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I think that we need more discussion (but maybe after a BOF has been initiated?)

 

[ME]: We can start such a discussion already today. However, I assume it is mostly following the capabilities and limitations of the wireless technology. What would be your proposal for a classification of constrained networks?

 

- Section 1.5: (Network Topology Options): I think there is a mix between the topology (i.e., the graph that represents routers and communication links), traffic flows (which devices communicate with which other devices), and application layer (proxies and NMS).

- Section 1.6: I like that.

 

- Section 1.7: There is mixture of constrained networks (first bullet); I thought that constrained devices only means that they have little CPU power and memory. Can't that device still use cable connectivity (i.e. unconstrained network)? Or is it necessarily linked?

I am unclear about the purpose of this whole section. What does it serve for?

 

[ME]: Section 1.7 in general tries to list and discuss the issues a constrained device might have and how these issues influence the management of such a device. As described in section 1.4 and 2. we include non-constrained networks with constrained devices.

 

- Section 2: I think that the problem statement is not quite clear yet. It is hard to identify what the problems are; there are so many useful requirements in section 4, so maybe it could be better matched to these requirements. It would be nice to read section 4, and then say "ah, requirement x indeed logically follows from the problem y that has been described in section 2".

 

[ME]: I agree the problem statement in section 2 (which I didn’t have time to update yet) could benefit from a revision aligning it with the new sections 1.7 and section 4.

 

- Section 3: I like the diverse use cases. That can be very useful to identify different requirements and problems.

 

- Section 4: I very much appreciate the enormous effort for gathering the requirements. There will be detailed discussions about them (hopefully), but this is a very good list to start from. 

We have to define if the security related requirements also fit in this discussion, or better some place else (SOLACE?). 

 

[ME]: We see authentication and access control (to the extend it matters) as part of network management. This is probably the part where Coman and Solace can profit from and complement each other.

 

Again, I appreciate the effort of the authors, and hope that we can continue the discussions in Atlanta. I apologize that I only provided this high-level review, but the last weeks were very busy for me. If you need help authoring the documents once they are split up, I could help out.

 

Is there a meeting already planned? 

 

[ME]: Yes, there will be a meeting on Thursday. I wanted to announce it once the room is known. Stay tuned.

 

Best regards

Ulrich 

 

On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) <mehmet.ersue@nsn.com> wrote:

Hi All,

we submitted an update for the constrained-mgmt draft on the "Management
of Networks with Constrained Devices: Use Cases and Requirements". The
draft hopefully addresses most of the issues we discussed in the last
meeting.

I think it is already time to split the draft into three; e.g. problem
statement, use cases and requirements. But this can be done after
getting your feedback before and during IETF 85.

I would highly appreciate your comments and any kind of discussion on
the draft content especially on the requirements section. Thank you.

Cheers,
Mehmet


-----Original Message-----
From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: dromasca@avaya.com; j.schoenwaelder@jacobs-university.de
Subject: New Version Notification for
draft-ersue-constrained-mgmt-02.txt


A new version of I-D, draft-ersue-constrained-mgmt-02.txt
has been successfully submitted by Mehmet Ersue and posted to the
IETF repository.

Filename:        draft-ersue-constrained-mgmt
Revision:        02
Title:           Management of Networks with Constrained Devices: Use
Cases and Requirements
Creation date:   2012-10-15
WG ID:           Individual Submission
Number of pages: 78
URL:
http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt
Htmlized:
http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ersue-constrained-mgmt-02

Abstract:
   This document raises the questions on and discusses the use cases and
   requirements for the management of networks with constrained devices.





The IETF Secretariat


_______________________________________________
coman mailing list
coman@ietf.org
https://www.ietf.org/mailman/listinfo/coman

 



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

--------------080306030900080702020909-- From fred@cisco.com Tue Nov 6 06:56:58 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD56421F8935 for ; Tue, 6 Nov 2012 06:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK3skfzeI7Et for ; Tue, 6 Nov 2012 06:56:58 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id EF5DA21F892A for ; Tue, 6 Nov 2012 06:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3894; q=dns/txt; s=iport; t=1352213818; x=1353423418; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=9jZZtEfn1VW/b7nCXZ3zbx4zU86tFtHYSiwxoAyGIyQ=; b=KUBNNbd4NPVaY6AnH9Zi9Pqg/rwN0AZRvSKEv5zK2LmKjZtXNiVxBH0Q u8zLWN444p3z3rkmIa+z84a2txrfTjyNiVMH9oo0KOih77/LSxsPRNq5U 9c7NfXenWcMXyrEWd9/zIMzSyzewaDVXT4l+MZKBulp27Ot1a1iyU+wCS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEMkmVCtJXG//2dsb2JhbABEwy+BCIIgAQQSASc/EgEqFEInBA4NGodoC5t2j2SQTowNCgYGhVRhA5cXjT2Ba4JvgVsBCBce X-IronPort-AV: E=Sophos;i="4.80,722,1344211200"; d="scan'208";a="139321320" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 06 Nov 2012 14:56:57 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA6Euvhq029964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 14:56:57 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 08:56:56 -0600 From: "Fred Baker (fred)" To: Paul Hoffman Thread-Topic: Thoughts on the firewall draft: Policies Thread-Index: AQHNvC72ELD68Yp/fEiGEDEFv1LRJA== Date: Tue, 6 Nov 2012 14:56:55 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B197E0B@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.211.206] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--40.855100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <039A11A33BB080418230AEDE93F91447@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: [OPSAWG] Thoughts on the firewall draft: Policies 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, 06 Nov 2012 14:56:58 -0000 http://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01#section-3 I'm copying the list as much as anything to generate discussion and make su= re we get the right stuff into the draft. Thinking about the section on policies, it seems a little disjoint. I find = the use of the words "newer" and "modern" a little dismaying; to begin with= , I'm not sure that they are newer or even modern; anomaly-based and signat= ure-based intrusion detection has been around for rather a while. The termi= nology also in effect deprecates the zone-based policy that is in fact pret= ty common, and is specified in RFC 6092. The notion that firewalls signific= antly change with the deployment of IPv6 is also, while cherished in some q= uarters, IMHO naive; if one's corporate policy is that firewalls should imp= lement a certain information security policy with IPv4, I almost guarantee = that they will do the same for IPv6 or any other communication service. I t= hink I would prefer to have an actual enumeration and discussion of policie= s, and leave opinions on them to the "recommendation" sections. I suspect that there are four broad classes of policy in the field. Happy t= o hear that there are others. I'm going to state these in Cisco language be= cause I am comfortable with it; if someone else likes other language, I don= 't have a problem with that - send text. One is what we call a context-based or zone-based defense. My enterprise ne= twork includes some set of systems and connectivity, and I draw a physical = or topological perimeter around it. The policy may permit peers outside the= domain to access a defined set of systems for a defined set of services - = web accesses to the web servers, mail to the mail servers, and so on. Apart= from that which is explicitly permitted to be originated from outside the = domain, the only sessions permitted to cross the firewall are those that or= iginate from inside the perimeter. To be honest, I think of this perimeter = as the CIO peeing on the trees around his territory - he understands that t= his is prophylactic, and that it provides limited defenses, and uses it as = much as anything to take control of his perimeter. Another is perhaps best described as an open defense. Ingress filtering (fi= ltering of messages based on routing information) is a classic example of t= his. Even if I have no policy regarding applications crossing my perimeter,= I very likely do not permit traffic from outside of my network to provoke = attacks within my network. An example of such an attack is someone ending p= ings to various systems in my network with a source address within, resulti= ng in a ddos on a particular address within my network. A third, which Warren Kumari commented on, is a policy to interrupt observe= d attacks. One "observes" an attack using an anomaly-based or signature-bas= ed algorithm, perhaps both, and in the event that such an attack is identif= ied, one asks someone upstream to block an identified set of traffic. A fourth is what we call a role-based defense. In a data center, for exampl= e, I may only permit stated sets of tenants to talk with each other. A sing= le administration within the data center may have multiple tenants - storag= e systems in one, computational resources in another, and so on. Within a c= orporate network, one frequently finds what look like perimeters around dep= artments like HR or Finance, with anyone in the department being able to ac= cess a wide set of resources, but folks outside the department only being a= ble to access a limited set of resources. The screwy thing is that "folks i= n the department" are one person or one office in each of a number of locat= ions. So the "perimeter" is a set of persons or their computational proxies= rather than a physical or topological domain.= From liljenstolpe@gmail.com Wed Nov 7 08:37:49 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC3221F8C84 for ; Wed, 7 Nov 2012 08:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXrzDfJ13icY for ; Wed, 7 Nov 2012 08:37:49 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0727021F8C81 for ; Wed, 7 Nov 2012 08:37:49 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1388695pbb.31 for ; Wed, 07 Nov 2012 08:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=BTfdShbLXxHfp+LV/qgntnp6SJrWb8AtnaZ4wtBKHYs=; b=Qo5Jou9YI+OWcRyw5OxDdRDXAhkZcM1tTCkkQM3Qnw0y6LZtmMnp00wO2VEuK/Mo5S Q5JNBMEhliO7/87pHQNo5s3flWRqbV18/BXY49SBTVmFmEugZi7IJ38XBHe/5WSHUCga ljh6rLBbC/qFNiLuGhG96nHPEiKi3UzUrtZ5MS9xK2vmrpcZVveigxmfotHr/hSr13zJ zzIucu2yNA/t3IIamt94mStAMSE/48giNy01Y0E2aTyfnf6oJdBFNB/tR7Raxa1cvFCZ bx9km1GRvLbC/Z8BmFV3HQyFKQuhfqzR0/XpFSAcKvO/mE6jVfam0iF6ymsvrr31SCmX wHcQ== Received: by 10.69.0.40 with SMTP id av8mr15247836pbd.117.1352306268752; Wed, 07 Nov 2012 08:37:48 -0800 (PST) Received: from dhcp-6450.meeting.ietf.org (dhcp-6450.meeting.ietf.org. [130.129.100.80]) by mx.google.com with ESMTPS id j8sm14516907paz.30.2012.11.07.08.37.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 08:37:47 -0800 (PST) From: Christopher LILJENSTOLPE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8D087F35-F982-418A-A545-451FAE8BEBE3@gmail.com> Date: Wed, 7 Nov 2012 08:37:44 -0800 To: "opsawg@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [OPSAWG] Review of draft-ietf-opsawg-lsn-deployment-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, 07 Nov 2012 16:37:49 -0000 Greetings all, I've re-reviewed this version of the draft, and think that, on balance, = it is a useful draft explaining how an operator may utilize IP VRF based = VPN's to ease the deployment o NAT44 based CGN's. There are a few = suggestions for the authors, outlined below. 1) I would indicate that the use of a services VRF is a MAY (in IETF = parlance). I could have the services address space either in a services = VRF, or I could actually have it in my non VRF tables (reducing the = number of VRFs that I have to maintain in the network). =20 2) There is an assumption that appears in the document that the use of = CGN's will increase over-time, leading to a decentralized model. I = would instead phrase it that the model could be centralized or = decentralized based on architectural, operational, or engineering = requirements. As far as CGN use growth, I would phrase it that CGN = deployment will probably follow a bell-like curve. It grows as I am = adding more IPv4 customers when I have exhausted my IPv4 public block, = and then will shrink as IPv6-only or the other transition mechanisms = take hold. Forecasting a continual growth of CGN is probably = (hopefully) incorrect. Christopher= From victor.kuarsingh@gmail.com Wed Nov 7 09:40:44 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372BB21F8C56 for ; Wed, 7 Nov 2012 09:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82juZH0yeMlP for ; Wed, 7 Nov 2012 09:40:43 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87B9821F8C55 for ; Wed, 7 Nov 2012 09:40:30 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so821157dan.31 for ; Wed, 07 Nov 2012 09:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=7ZXzFiIFZvzrOwC/QCFYdww4aAu/3Iv8gaOeUArFNdA=; b=fsjvdfQ888DnDFbBW7zmyH/6UDrVIxqiES9pp2pwTB7CyiWm9jXlgzUcgfHK2h08vZ Fb1zWwBpWkeksAWBw22ehOdjmR45Hgfia+cRSBWRdKf92ox1EwmIvSrKZjOBD4W1O5Za 9D18VCHNfwjK/BtBn/Jb6R9y42+aOhRLgZk4T0yiQU/ehV35hXukg6H9H/MikILiSIZ9 IC/w/iC4S8088VC6VZASTEqj/mU4qCu3ocR27+IBdj9crwdxcCj4dnaPuiObBxMEgu59 keiXuxAlc9RhybV24Hqk4ozJ3Pi6rkNmSwO7JMzIUpnXq4r6cf8W64WKMQbmO0YoASFO MSRg== Received: by 10.66.80.65 with SMTP id p1mr8216522pax.20.1352310030369; Wed, 07 Nov 2012 09:40:30 -0800 (PST) Received: from [130.129.17.203] (dhcp-11cb.meeting.ietf.org. [130.129.17.203]) by mx.google.com with ESMTPS id vs3sm14430592pbc.61.2012.11.07.09.40.27 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 09:40:29 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 07 Nov 2012 12:40:27 -0500 From: Victor Kuarsingh To: Christopher LILJENSTOLPE , "opsawg@ietf.org" Message-ID: Thread-Topic: [OPSAWG] Review of draft-ietf-opsawg-lsn-deployment-01 In-Reply-To: <8D087F35-F982-418A-A545-451FAE8BEBE3@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [OPSAWG] Review of draft-ietf-opsawg-lsn-deployment-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, 07 Nov 2012 17:40:44 -0000 Chris, Thanks for review. I will collect comments from the other two reviews and then make updates accordingly. If discussions are required for particular points, I will pose those to the list. Regards, Victor K On 2012-11-07 11:37 AM, "Christopher LILJENSTOLPE" wrote: >Greetings all, > > > >I've re-reviewed this version of the draft, and think that, on balance, >it is a useful draft explaining how an operator may utilize IP VRF based >VPN's to ease the deployment o NAT44 based CGN's. There are a few >suggestions for the authors, outlined below. > >1) I would indicate that the use of a services VRF is a MAY (in IETF >parlance). I could have the services address space either in a services >VRF, or I could actually have it in my non VRF tables (reducing the >number of VRFs that I have to maintain in the network). > >2) There is an assumption that appears in the document that the use of >CGN's will increase over-time, leading to a decentralized model. I would >instead phrase it that the model could be centralized or decentralized >based on architectural, operational, or engineering requirements. As far >as CGN use growth, I would phrase it that CGN deployment will probably >follow a bell-like curve. It grows as I am adding more IPv4 customers >when I have exhausted my IPv4 public block, and then will shrink as >IPv6-only or the other transition mechanisms take hold. Forecasting a >continual growth of CGN is probably (hopefully) incorrect. > > Christopher >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From liljenstolpe@gmail.com Wed Nov 7 10:17:44 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7B21F8C72 for ; Wed, 7 Nov 2012 10:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zi0LkLsksrK for ; Wed, 7 Nov 2012 10:17:44 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB2221F8C71 for ; Wed, 7 Nov 2012 10:17:44 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so834799dan.31 for ; Wed, 07 Nov 2012 10:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JIuULkXkET6ZF2RTTSBl5xiOSphOaHp/QbOU0EJp6cQ=; b=yMgrfuZeA6IRdsat92OKPf48rZby3+ij8MSeX/PTW7Wg5qpykBBLwvjlS+0JsAYJRh rT4CD3V/IoPEoY05p4IT9vpAAVx7Du5uS1zeObIHia136RiMiKoIp+ADOiSElRt+iGHl HLI6o73PwOfECLLjPvKJkczjJUcuIwDjX4LaGMaOV+1ogCSScZw84d7bNYwtjGpekZQs b1eb4taPDBhh5HgqBUE+EAF8q7mAxikPZbg40534/O+KbHnAnghDEhC3LrkBZl9hb4Vl Wphn9gQQ1OnTafSm9GMYMUiqc18TX9ITq3DzHVyGKnt2Y3aReEFLtWuzSFS3Y/Hzj6RP HdIQ== Received: by 10.68.234.201 with SMTP id ug9mr9505835pbc.63.1352312263883; Wed, 07 Nov 2012 10:17:43 -0800 (PST) Received: from ?IPv6:2001:df8::96:c56a:9740:ff9a:54d? ([2001:df8:0:96:c56a:9740:ff9a:54d]) by mx.google.com with ESMTPS id az8sm14636011pab.24.2012.11.07.10.17.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 10:17:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Christopher LILJENSTOLPE In-Reply-To: Date: Wed, 7 Nov 2012 10:17:40 -0800 Content-Transfer-Encoding: 7bit Message-Id: <03B90D35-4CBA-4968-8219-38FA85D071E8@gmail.com> References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1499) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Review of draft-ietf-opsawg-lsn-deployment-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, 07 Nov 2012 18:17:44 -0000 You are welcome. Chris On 07Nov2012, at 09.40, Victor Kuarsingh wrote: > Chris, > > Thanks for review. I will collect comments from the other two reviews and > then make updates accordingly. > > If discussions are required for particular points, I will pose those to > the list. > > Regards, > > Victor K > > On 2012-11-07 11:37 AM, "Christopher LILJENSTOLPE" > wrote: > >> Greetings all, >> >> >> >> I've re-reviewed this version of the draft, and think that, on balance, >> it is a useful draft explaining how an operator may utilize IP VRF based >> VPN's to ease the deployment o NAT44 based CGN's. There are a few >> suggestions for the authors, outlined below. >> >> 1) I would indicate that the use of a services VRF is a MAY (in IETF >> parlance). I could have the services address space either in a services >> VRF, or I could actually have it in my non VRF tables (reducing the >> number of VRFs that I have to maintain in the network). >> >> 2) There is an assumption that appears in the document that the use of >> CGN's will increase over-time, leading to a decentralized model. I would >> instead phrase it that the model could be centralized or decentralized >> based on architectural, operational, or engineering requirements. As far >> as CGN use growth, I would phrase it that CGN deployment will probably >> follow a bell-like curve. It grows as I am adding more IPv4 customers >> when I have exhausted my IPv4 public block, and then will shrink as >> IPv6-only or the other transition mechanisms take hold. Forecasting a >> continual growth of CGN is probably (hopefully) incorrect. >> >> Christopher >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > From christopher.liljenstolpe@bigswitch.com Wed Nov 7 13:48:02 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFE021F8C36 for ; Wed, 7 Nov 2012 13:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8Bp0doTt56H for ; Wed, 7 Nov 2012 13:48:02 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C26A21F8AF0 for ; Wed, 7 Nov 2012 13:48:02 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so910197dan.31 for ; Wed, 07 Nov 2012 13:48:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer:x-gm-message-state; bh=3V2+fpogGPKSpfxaRiTfsEKpiuVLP2ZHZpsza1LjUUk=; b=h23qkZUX0neyJX4FeLuUYhI8j8Ec5EUvBfHvI1Dw1SIVlDPJqSHge4213spiVD82Mi vA06Z3BhlpQCqf63SEKrGMQfQtC99esjgJx17FwHVdOnF0CWa/58CeeputCJ/P13/VFg cpk+6YhWHLz1bi8SOLeuIVr2Y6q9MOWaf7gPsYF6FvSfjd+k2zzCrDorHVMCaMc80+VI GoPyVORt0v9uwTPSE7uNo5PZbW9bpcudKn4jGGy2TFECbFBjNIspxjyj2NrXTKkHIU/D iodHA50JwcU1xoowlHfe4xFcfNg6XYuZ4M+XXO5ZRriIlIc/dn9zICWaqhSV4PkCKBEu 9GRg== Received: by 10.68.247.196 with SMTP id yg4mr17709396pbc.167.1352324882004; Wed, 07 Nov 2012 13:48:02 -0800 (PST) Received: from ?IPv6:2001:df8::96:98fa:683:1cd7:b72e? ([2001:df8:0:96:98fa:683:1cd7:b72e]) by mx.google.com with ESMTPS id zv10sm14698622pbc.76.2012.11.07.13.47.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 13:48:00 -0800 (PST) From: Christopher Liljenstolpe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Nov 2012 13:47:46 -0800 Message-Id: <29A47EB9-E0BD-4DFC-A1E8-7A33D767D09C@bigswitch.com> To: "opsawg@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmeVUh4Xc6vwugJRnj3V+jy3D/jxMnrZJhe5EEmOUHDPu8VbjRkB37NXkWK0TkKPyomNFbH Cc: draft-ietf-opsawg-oam-overview@tools.ietf.org, "elisa.bellagamba@ericsson.com Bellagamba" , "opsawg-chairs@tools.ietf.org" Subject: [OPSAWG] working group last call draft-ietf-opsawg-oam-overview 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, 07 Nov 2012 21:48:02 -0000 Greetings all, As it has been quite a bit of time since this document was = last-called, we have been asked by the AD's to have a new WG last call = on this document. The sooner we get this done, the better. Therefore, = we are submitting it for a WG last-call, which will terminate Tuesday at = midnight, UTC. Thank you. Christopher =09= From fgont@si6networks.com Fri Nov 9 22:59:14 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C851521F8542 for ; Fri, 9 Nov 2012 22:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaXDck1JzxEE for ; Fri, 9 Nov 2012 22:59:14 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEC921F853D for ; Fri, 9 Nov 2012 22:59:13 -0800 (PST) Received: from nsc69.38.30-74.newsouth.net ([69.38.30.74] helo=[10.59.1.38]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TX51t-0005pl-T9; Sat, 10 Nov 2012 07:58:58 +0100 Message-ID: <509DFB2B.4050204@si6networks.com> Date: Sat, 10 Nov 2012 01:58:51 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Fred Baker , Paul Hoffman X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: [OPSAWG] Some feedbac about draft-ietf-opsawg-firewalls-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: Sat, 10 Nov 2012 06:59:14 -0000 Folks, Thanks for writing the aforementioned I-D. I recall reading previous versions of it, and I'm glad to see it has been adopted as a wg item of the opsawg. Some comments: Section 1, states: > If two or more networks that are connected by > a single device, the perimeter is inside the device. Please remove "that". Section 1: > The ALG blocks some of the flows in the application protocol based > on policies such as "do not all traffic from this network" and "do > not allow the client to send a message of this type". s/do not all traffic from this network/do not all any traffic from this network/ ? Section 3.2 states: > Firewalls that understand IPv6 may have a fourth category: > > IV: Allow nearly all outside-initiated traffic. [[[ MORE HERE > about why this is considered a good idea by some and a bad idea by > others ]]]] You mean that some people do not do any filtering, or something else? Section 4 states: > Allow fragments > Except in specific protocols where layer 7 content filtering is > deemed crucial Is this IP-layer fragmentation any different than having to do TCP reassembly for doing layer-7 inspection? (.. and you cannot prevent the later). Also, please keep the recent v6ops discussion about "frag drop" in mind... Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From liljenstolpe@gmail.com Tue Nov 13 23:31:37 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E1021F8609 for ; Tue, 13 Nov 2012 23:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW2TwjNxaOBL for ; Tue, 13 Nov 2012 23:31:36 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF96121F85ED for ; Tue, 13 Nov 2012 23:31:36 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so75794dan.31 for ; Tue, 13 Nov 2012 23:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=VnthvFoqSvFBncRwHNu2Yh1M0GW+SM1aOxVNX5vKDAM=; b=kwi19GTPE0yHpBFoQ4K30PshwdTToo+LkUlAI+unAiw7/r4Z5LzFZL34E1Ykj4oUmP 9Jx11VddNyxF9Cjkdz+1MjtaNNDkhYJlcIprGNcIEahpeBJ8uos6vdOlsQZCzrKPPSNS PoCsqKFAxTcxx24Niskel6GykE26AUtwl653bJ07f72YpSbfqm2wvFKaffUWQaCzfgtu x7ngD8nNU+uiHiljAdjGj1p1718oEroBo8vbMTSYmFSkDNdr0JW6pMaDdytC6zMAJYsK W58VSiH3mK3aLa/yDs1YkIhSfKrrXIc1oIQ1bv7FMsLOpZokEggKAzQbP47ARzNbHlhv BIIA== Received: by 10.66.75.101 with SMTP id b5mr4702516paw.45.1352878296304; Tue, 13 Nov 2012 23:31:36 -0800 (PST) Received: from [204.29.150.165] (50-76-34-190-ip-static.hfc.comcastbusiness.net. [50.76.34.190]) by mx.google.com with ESMTPS id qp6sm7324647pbc.25.2012.11.13.23.31.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 23:31:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Christopher LILJENSTOLPE In-Reply-To: <29A47EB9-E0BD-4DFC-A1E8-7A33D767D09C@bigswitch.com> Date: Tue, 13 Nov 2012 23:31:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <697BA95E-ABF5-4BDF-A67C-982188B31067@gmail.com> References: <29A47EB9-E0BD-4DFC-A1E8-7A33D767D09C@bigswitch.com> To: "opsawg@ietf.org" X-Mailer: Apple Mail (2.1499) Cc: "ops-ads@tools.ietf.org Area" , Christopher LILJENSTOLPE , draft-ietf-opsawg-oam-overview@tools.ietf.org, "elisa.bellagamba@ericsson.com Bellagamba" , opsawg-chairs@tools.ietf.org Subject: Re: [OPSAWG] working group last call draft-ietf-opsawg-oam-overview 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, 14 Nov 2012 07:31:37 -0000 Greetings, We have received no new comments on this draft. The WGLC is now = closed. Christopher On 07Nov2012, at 13.47, Christopher Liljenstolpe = wrote: > Greetings all, >=20 > As it has been quite a bit of time since this document was = last-called, we have been asked by the AD's to have a new WG last call = on this document. The sooner we get this done, the better. Therefore, = we are submitting it for a WG last-call, which will terminate Tuesday at = midnight, UTC. >=20 > Thank you. > Christopher >=20 >=20 > =09 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From melinda.shore@gmail.com Sat Nov 24 15:03:42 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A2B21F8543 for ; Sat, 24 Nov 2012 15:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCjBwmKH+mCB for ; Sat, 24 Nov 2012 15:03:41 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D98AA21F8538 for ; Sat, 24 Nov 2012 15:03:41 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so5094457pad.31 for ; Sat, 24 Nov 2012 15:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=M5wdkeIIXLgG5CQ98SFzlUdsiA7IU6q5hldwmNjnIsc=; b=BXM4u5eeC52iB7xs/aWFlrymTLAUHzf7YFMH5zxUcfzNn/8ZCZiY83qIns8oX4QGeb yWPvVWl/h+2Tl8ub5ZFdgCt9ty4qTsaVTwcsLm8v0LTDmoSLGOML+7M8NhLv4r2eFkdh U9AUPPgkFJq/DBNk0rN1EhpmxPoHz4BNOiz1kLoTel8ubGAi7UagouqDmULGxDDu5qSH IrUnlJzTBfpM0SIPEBEQzq0FFGiNgWxspkjChRcDSyQLQ5YOShHR8Ff00l0FXMdjgv2d HpY+RpTivR5iGkyS7Qdzv79fQyfxAN5CN4daHhtnIOHO7vE183Y25NMeaJNfaE890RzW 4NOg== Received: by 10.66.77.201 with SMTP id u9mr21713231paw.6.1353798221580; Sat, 24 Nov 2012 15:03:41 -0800 (PST) Received: from spandex.local (66-230-101-174-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.101.174]) by mx.google.com with ESMTPS id sw1sm6073670pbc.75.2012.11.24.15.03.39 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Nov 2012 15:03:40 -0800 (PST) Message-ID: <50B1524A.6030709@gmail.com> Date: Sat, 24 Nov 2012 14:03:38 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Minutes uploaded 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, 24 Nov 2012 23:03:42 -0000 A first poke at minutes from IETF 85 has been uploaded to http://www.ietf.org/proceedings/85/minutes/minutes-85-opsawg - please have a look and correct any errors or omissions. The main decision requested at the meeting was that draft-ietf-opsawg-lsn-deployment be sent into WG last call. We felt it needed more review and Tina Tsou, Chris Donnelly, and Chris Liljenstolpe volunteered. If the reviewers are happy with the document we'll ask for last call. In the meantime, we'd be happy for review and feedback from anybody else with an interest. Thanks, Melinda From tom.taylor.stds@gmail.com Mon Nov 26 16:50:23 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AA821F8641 for ; Mon, 26 Nov 2012 16:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-OK+qFBuVS1 for ; Mon, 26 Nov 2012 16:50:23 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0458F21F8625 for ; Mon, 26 Nov 2012 16:50:22 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so10803771ieb.31 for ; Mon, 26 Nov 2012 16:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=CFKCNp6GYnLkzOvbNgTFw2TRhKUNKxzonf0sKCsFJlM=; b=D/LmT5RxaCZ0lifc7NjxwYT057Q+TmsoaHkZfr8m/SkbRleDEasPui6Vidq35WxF09 vegg8GwjopcaIbRi8xGWda7B5l26qTGrL0nKEU2Xf/OO0RQYopZqZhafg27R+TVTKelP bKoUMfTNLTx4GiBnpJindJbN2DXksv6YChcJXi6jdltjsTYA2eiv51gyrLmmB66PIAGx CL7CoOrLMExxl0pxDxvt8kPsHHw89liXrllgAhm7jqURy9IwXNI1DaJhSqaiFt8oZEnI cP4wxsieuCGnyrznlbV8BkgcJ6qfinKfxFVCniWjDwFu5hPljUp76/xX9B1zchSwESlw eFJg== Received: by 10.42.41.142 with SMTP id p14mr12212457ice.36.1353977422516; Mon, 26 Nov 2012 16:50:22 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-12-215.tor.primus.ca. [173.206.12.215]) by mx.google.com with ESMTPS id pr7sm339042igc.16.2012.11.26.16.50.20 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 16:50:21 -0800 (PST) Message-ID: <50B40E4C.9080407@gmail.com> Date: Mon, 26 Nov 2012 19:50:20 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121126-1, 26/11/2012), Outbound message X-Antivirus-Status: Clean Cc: john.cianfarani@rci.rogers.com Subject: [OPSAWG] Review of draft-ietf-opsawg-lsn-deployment-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, 27 Nov 2012 00:50:23 -0000 This draft is pretty close to ready. I am sending a marked-up copy with editorial nits directly to the authors. I have the following slightly more substantial remarks: 1. At the end of Section 3, just before the Section 3.1 heading, I suggest adding the sentence: "The following subsections expand on some of these points." 2. Sections 3.2 and 3.3 both suggest that flows requiring translation and other flows need separate routing, and Section 3.4 addresses this topic explicitly. Just to reduce the feeling of repetition while tying things together, Section 3.4 might refer to the previous two sections. For example, this sentence could be added to the beginning of Section 2.4: "The two previous sections made the point that for greater efficiency flows requiring translation should be distinguished from other flows. Thus many operators ..." 3. The first paragraph of Section 5.1 reads: "The MPLS/VPN CGN environment has been successfully integrated into real network environments utilizing existing network service delivery mechanisms. It solves many issues related to provider based translation environments, while still being subject to problematic behaviours inherent within NAT." That last phrase, "... while still being subject to problematic behaviours inherent within NAT.", led me to expect mention of unsolved issues but none follows. Could you possibly mention a couple of those issues at the end of Section 5.2 after you list the positive points? Tom Taylor