Re: [Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04
Victor Kuarsingh <victor@jvknet.com> Thu, 16 January 2014 03:40 UTC
Return-Path: <victor@jvknet.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027521AE1C9 for <gen-art@ietfa.amsl.com>; Wed, 15 Jan 2014 19:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkjoonom3cGP for <gen-art@ietfa.amsl.com>; Wed, 15 Jan 2014 19:40:33 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id C528D1AE1B4 for <gen-art@ietf.org>; Wed, 15 Jan 2014 19:40:32 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id d13so4666304wiw.12 for <gen-art@ietf.org>; Wed, 15 Jan 2014 19:40:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9TcYj5lVpjOxmjYngbGhAUFUKxmnkEwpjoZW5jDh4rQ=; b=Hd0IGr8tM6WjEl3+uj/U2kVOHF2S5JoClwUqEcMgq95bwx6DVFVKQkLUVLPa8K5k78 40ps5NRn2e33HYtPQ3IGlnoTmF8ikScZsLzPB0E8mLWeuq/BCfXVWpLjzzyaYrwknESe v4fy2A8hR8DTxe8C0sUIPuPwSrxXC9NQZ3TaelWcA+4+QM/m4PvY+kDCVd3Hv4n9fO86 czqBJWlqYAQzSJJCsHg+MlcZtadTIQ7/3kHG96nVKqqaksC77pFDVeJZoKM32Ek+X7JB g2gnQL1FYIXptuvywgN5wlao4DiKqGYyzKDxl+GYwl1aAvJI9W7nb84LdLq5MFZQDIBc AiGg==
X-Gm-Message-State: ALoCoQkosEmwXxAwHijglNf9MVltUoLkDuyuZ9Jt7cN9H6JJ7d6XStu8x5AqQO2XWPYrGh4xKDh+
MIME-Version: 1.0
X-Received: by 10.194.48.74 with SMTP id j10mr5855426wjn.41.1389843620301; Wed, 15 Jan 2014 19:40:20 -0800 (PST)
Received: by 10.216.89.193 with HTTP; Wed, 15 Jan 2014 19:40:20 -0800 (PST)
In-Reply-To: <CABkgnnXj07R25LQ64-=bha6iFpabgAt=xsRP0+5A20wnF8JUdQ@mail.gmail.com>
References: <CABkgnnXj07R25LQ64-=bha6iFpabgAt=xsRP0+5A20wnF8JUdQ@mail.gmail.com>
Date: Wed, 15 Jan 2014 22:40:20 -0500
Message-ID: <CAJc3aaPKeuPicy_X+MG-T-XyZ+YdONphhkp1Ow666jq9_ubzew@mail.gmail.com>
From: Victor Kuarsingh <victor@jvknet.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="047d7ba975c84826ef04f00e2fb0"
X-Mailman-Approved-At: Wed, 15 Jan 2014 20:02:13 -0800
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, draft-ietf-opsawg-lsn-deployment.all@tools.ietf.org
Subject: Re: [Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 03:40:36 -0000
Martin, My responses in-line On Mon, Jan 6, 2014 at 1:44 PM, Martin Thomson <martin.thomson@gmail.com>wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-opsawg-lsn-deployment-04 > Reviewer: Martin Thomson > Review Date: 2014-01-06 > IETF LC End Date: 2014-01-06 > IESG Telechat date: (if known) > > Summary: This document describes a generic way that MPLS LSPs can be > deployed to support the deployment of CGNs in a way that addresses a > range of common requirements. As a draft, it's still a little rough, > but it is mostly ready for publication as an Informational RFC. > > Major issues: none > > Minor issues: > > The abstract says this: > > This document does not intend to defend the > merits of CGN. > > Which seems wise given their somewhat contentious nature. But then > the entirely of Section 2 does exactly the opposite. I don't know > what the right answer is here, but maybe the right thing to do is > delete Section 2. > [VK] The intention of this section was to explain that CGN may be used by operators and discuss some of the factors that may go (or have gone) into that decision. The point in the abstract was intended to tell the reader that the authors were not suggesting that CGN was "good" or "needed". There are some important points that I think are important within the section (section 2), so perhaps if I/we can remove specific text that seems to given the impression that we are defending CGN, I can do so. > > Figures 1 and 2 should probably use different labels for the two CPE > boxes. The top one is being translated, the bottom one isn't. > [VK] Yes, that makes sense. I can make that update. Thanks for the suggestion > > Section 6 is a little too speculative to be valuable. How about using > the boilerplate: > > This document has no IANA actions. > [VK] I am ok with that. Noted. > > I'm not sure what "security measures" might be employed here: > > If a provider plans to operate the pre-translation realm (CPE towards > translator IPv4 zone) as a non-public like network, then additional > security measures may be needed to secure this environment. > > What might be secured in these scenarios? Confidentiality? Access to > network resources? Perhaps this should talk about what a network > operator wants to secure: access to the network. Then maybe talk > about access control and isolation. > [VK] The point here was that the document/authors have assumed the position that the CGN realm (within the context of this document) is that it's publicly accessible (to the extent that it can be behind a translation function. The point was that if an operator wanted something more secure (which can be a number of thinks include items you listed like access to/from the Internet etc) that those would require mode consideration. We did not itemize those considerations as any list I generate would be somewhat arbitrary (should I select a few examples). If you feel that such a partial listing is material, I can do so. My concern here is that once we put in such a list, we may have to deal with conversations like "why did you not include such and such .. etc" The overall expectation is that the operator should expect the same level of exposure as traditional customers. > > In Section 4, this seems a little vague: > > Various redundancy models > can be used within this architecture to support failover from one > physical CGN hardware instance to another. > > I don't expect an enumeration of the options, but this seems important > enough to at least point to where the redundancy options might exist? > Redundant "VPNs"/LSPs? Redundant paths from the VRF termination? > [VK] Our expectation was that the operator would be able to derive their own answers on how to enable redundancy in their model. The expectation is that the reader already would understand (or would need to verse themselves) CGN and MPLS/VPNs. Therefore they would be able to enumerate the options on their own. We were trying to keep the text simple and show the basic association of how to deploy the CGN using MPLS/VPNs. I would not want to sound prescriptive on how to actually design a specific instance. In disclosure, when I did my design, I did use multiple RD/RTs and imported those routes into a common CPE VPN. But that specific option may not be used by others. I would expect an operator who has already deployed MPLS/VPNs to have a redundancy model already in place, and they would evolve that for this purpose. To exemplify that point, I had discussions with two other Canadian ISPs who tested/integrated CGNs using this method (MPLS/VPNs) and one did not put in network based redundancy (just had to CGN functions at a common endpoint/VRF) and the other did have redundancy but only employed a single RD/RT (and just had multiple defaults). Each of us (three) chose redundancy models which matched our pre-existing MPLS network designs. I would expect the same from others as well (although this may be a poor assumption). > Nits: > > Missing period in Section 9 > > I found the structure of the first part of Section 3.1 difficult: > > Centralized deployments of CGN (longer proximity to end user and/or > higher densities of subscribers/connections to CGN instances) differ > from distributed deployments of CGN (closer proximity to end user and > /or lower densities of subscribers/connections to CGN instances). > > Maybe this could be expanded a little to improve comprehension. > > This statement seems redundant: > > Other requirements may be assessed on a operator-by-operator basis, > but those listed above may be considered for any given deployment > architecture. > > As far as it goes, some of the requirements listed might not apply to > a particular deployment, or part thereof. > [VK] I will make adjustments as specified. I appreciate the text. [VK] I hope my responses are adequate. Once again, I appreciate your review of the draft. regards, Victor K
- [Gen-art] Gen-Art review of draft-ietf-opsawg-lsn… Martin Thomson
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Benoit Claise
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Victor Kuarsingh
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Victor Kuarsingh
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Martin Thomson
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Jari Arkko
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Victor Kuarsingh
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Benoit Claise
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Martin Thomson
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Benoit Claise
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Victor Kuarsingh
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Victor Kuarsingh
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Victor Kuarsingh
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Martin Thomson
- Re: [Gen-art] Gen-Art review of draft-ietf-opsawg… Jari Arkko